Since posting yesterday about the subscribe button hell that's overrunning some weblogs, I've been thinking a little more about the problems universal feed subscription method would need to address and how it might work. A quick refresher: we need a way to enable users of any feed reader to subscribe to a feed (or at least load it) with a click of the same button.

One issue: if you use a web based feed reader, you don't need to download the feed to your computer--you just need to tell your feed reader to subscribe to it. So if clicking the subscribe link results in your browser downloading the feed and then realizing that it doesn't need the data, but just needs to send the URL to your feed reader, you're wasting time and bandwidth.

A possible solution is for the browser to check for "type" attribute on the link, and if it's a type that's configured for "URL forwarding", skip the download step and just forward the URL. This would solve the extra download problem, and at the same time help publishers who for whatever reason can't get the right Content-Type header returned with their feeds (as long as the feed reader was willing to accept it with the wrong Content-Type). The type attributes on link tags is only advisory, so technically, in the best of all possible worlds, the Content-Type returned with the data should override it, but this might be a good example of a case where it's wise to fudge things a little.

Of course, most people don't include type attributes on their <a> tags, so what do you do in that case? When a user clicks a hyperlink that doesn't have a type attribute, the browser could check the <link> tags in the web page's head section for any links pointing to the same URL. If the webpage is using autodiscovery links to point to its feeds, the link will probably be duplicated there. If it finds one, it could check for a type attribute there and act accordingly. Type attributes on <link> tags are much more common. If all else fails, the browser would download the content, see the Content-Type header, and dispatch the URL to the subscription service.

Another question needing to be addressed is whether the URL should be sent using a GET or a POST. There are valid arguments either way, and I suppose that could be user configurable. But it might be more user friendly to establish a single method to use. GET would result in the URL showing up in the subscription server's logs, which under some circumstances might not be desirable. But other than that, I think GET would be preferable for it's simplicity. For example, if the service requires additional arugments along with the URL, they could be statically coded into the subscription URL. For example, the subscription URL might be:

http://example.org/subscribe.cgi?language=english&url=

...to which the URL (properly escaped) would be appended. If the user isn't logged in when they click the feed link, the subscription server could request their login credentials before acting on the subscription request, so those wouldn't (and really shouldn't, for security) be included in the subscription URL.