Wednesday, 17 March 2004
Outage in the Web: Server Configuration
In an otherwise excellent article, Jon Udell blames the lack of one-click subscribe in syndication formats on lack of vision;
How users will interact with the formats and APIs is left as an exercise for the implementer. But of course that’s where the rubber meets the road. So syndication still lacks a well-known mechanism for one-click subscribe.
In fact, there’s a clear path to one-click subscribe in syndication.
Here’s how: If every syndication format were served with a well-known media type (e.g., application/rss+xml), browsers could be configured to dispatch that format (which would need to contain a link back to the feed) to the user’s preferred aggregator or other client. With a little help, they could even be configured to dispatch to a Web aggregator.
It’s easy and simple, and it’s how the Web is designed. Unfortunately, there’s a catch; the phrase “were served.”
It turns out that most Web servers don’t know anything about application/rss+xml, so they don’t know how to serve it; if you put a .rss file on Apache today, you’ll probably get back text/html, which doesn’t do you any good for dispatching it.
It’s possible to configure Web servers to know about this, of course, but here’s the rub; most users either aren’t allowed to do so by their administrators, or don’t know how to, because the interface is so arcane.
The results of this problem are pretty far-reaching. For RSS, it means that people resort to hacks like the “feed” URI scheme, because it’s self-contained inside the URI, or a laundry list of “subscribe” links. In other situations, it means that people aren’t able to leverage the common facilities that the Web provides, like authentication, caching and redirection.
In fact, I could give an example of almost every facility that the Web provides being held back by this problem. Because of this, I’m saying that flexibility of server configuration a key outage for the Web. Next: a straw-man proposal for how to fix it.