Tag web

Meta-Social Code

I had an idea the other day, and I’m not sure why no one’s implemented. I suspect that either a) someone has and I don’t know about it, or b) there’s some fundamentally-unsolvable problem. If so, please point this out in the comments.

At any rate, the idea is this: as a site owner, I want to make it easy for people to link to my site. I want a wall of social-site buttons on every page, with every site from AOL to Zynga.

But as a reader, I only have a few sites that I use to link to places. I don’t want to wade through row after row of useless icons just to find the one that I want to use to share the URL.

So it seems the obvious thing to do would be for some entrepreneur (not me) to offer “social site button bar as a service”. The site owner adds some markup to the page to say “this is something that can be recommended/liked/shared”, and include a JavaScript script that takes care of the magic behind the scenes. Something like:

<html>
<head>
http://social.com/siteid12345/api.js
</head>
<body>
<h1>This is my page</h1>
<p>Hello world</p>
<social:button-bar/>
</body>
</html>

The script can take care of adding additional <script>s to load additional APIs from whichever social sites are being loaded, and add a DOMContentLoaded listener that’ll replace <social:button-bar> with a series of other elements, like <g:plusone> and <fb:like>.

The end-user, meanwhile, can visit a configuration page and decide which social sites will appear in the button bar. This can be saved in a cookie.

I’ve consed up a quick and dirty prototype, and was surprised that it worked. I haven’t tested it extensively, though.

The obvious objection (aside from “but how does one make money off of this thing?” But they said that about Kozmo.com too. So there) is that this seems like an engraved invitation to cross-site scripting (CSS) holes. And privacy leaking, and who knows what all else.

A related question, which I haven’t answered, is who can see the cookie? If the JavaScript code comes from social.com, then social.com needs to be able to see the user configuration cookie to know which buttons’ code to serve up. But if the reader is looking at content.com, there’s no good way to get a social.com cookie and pass it along. It might be possible to set a content.com cookie, but of course that won’t help when the user surfs over to othersite.org, where we want the end-user to see the same button bar.

I confess that I’m not entirely clear on the policies that govern which sites/scripts can see what data. So it’s quite possible that I’m missing something glaringly obvious.

Pre-Compressing Web Content

This was definitely a “D’oh!” type of problem.

One thing I’d been meaning to figure out for a while was how to send gzip-compressed files to a browser. That is, if I have a large HTML file, it’d be nice if the server could compress it to save bandwith and transmission time. Yes, Apache has mod_deflate which takes foo.html and gzips it on the fly, setting all the appropriate HTTP headers. But for static content, I should just be able to compress the file in advance. If the browser asked for foo.html, I wanted Apache to see that there’s a foo.html.gz and send that instead, with headers saying that it’s a text/html file that happens to be compressed.

mod_mime seemed like just the thing: just add

AddEncoding x-gzip .gz

to .htaccess. But every time I did that, Apache sent back “Content-Type: application/x-gzip“, so my browser treated it as a random file of unknown type that happened to be compressed.

Then I noticed that my vanilla-ish site-wide Apache config had

AddType application/x-gzip .gz .tgz

so that when Apache saw foo.html.gz, it ignored the .html extension, and saw only the .gz one.

The fix was to add RemoveType to my .htaccess:

RemoveType .gz
AddEncoding x-gzip .gz

And voilà! .gz stops being a file type and becomes an encoding, allowing .html to shine through.

I’ll add that this plays nice with AddLanguage as well. In my test setup, I have foo.html.en.gz, for which Apache returns the headers

Content-Type: text/html
Content-Encoding: x-gzip
Content-Language: en

I.e., it’s an HTML file, it’s gzip-encoded, and it’s in English.

Just as importantly, this works with other file types (e.g., CSS files and JavaScript scripts), and XMLHttpRequest does the Right Thing with them on all of the browsers I care about.