Re: Hyperlinks and content negotiation

Mike Kelly writes:

> HTML does not currently provision for hyperlinks to indicate a
> specific content-type preference for the Accept header of a given
> request.

That's true, but URLs are distributed in many ways other than as
hyperlinks in HTML documents, most of which don't have any way of
indicating that.

> This is an important feature for developers who wish to leverage HTTP
> content-negotiation,

Surely even if HTML provided for this such developers would still be
hampered by URLs being passed around without content types (and users
not being used to them).  For example URLs are commonly communicated
via:

* plain-text e-mail messages
* instant messaging and Twitter messages
* URL-shortening services
* adverts on the side of buses
* T-shirts

All of the above involve either a browser being passed a URL (sans
content type) from an external application, or the URL being entered by
a user.

Any site which requires a certain content type to be supplied to serve
the desired content will be serving the wrong content.  

This feature would also break bookmarks: a user could bookmark a page's
URL, believing that the URL identifies that page, yet on later visiting
that bookmark being served different content.

> ... and require HTML hyperlinks that specify requests to URIs with a
> specific Accept header preference. There are use cases in which the
> distinction between a resource's representations are relevant to the
> flow of an html driven application, e.g. the difference to a browser
> between an atom and an html representation of a blog resource.
>
> <a href="/blog" type="text/html">My blog (HTML)</a>
> <a href="/blog" type="application/atom+xml">My blog (Atom Feed)</a>

Many blogs seem to manage with different URLs for their HTML content and
their feeds, so this requirement can't apply to all blogs in general.
Please could you clarify precisely the situation which leads to this
requirement, where two separate URLs wouldn't work?

> Without a formal mechanism in HTML which can specify to UAs the
> contextual content-type preference for a given hyperlink, HTML is not
> a viable hypermedia format for systems which must rigorously leverage
> HTTP conneg - this /could/ be achieved with representation specific
> URIs (i.e. format 'suffixes', URI parameters etc.) but there are
> situations in which conneg is a superior solution, particularly in
> terms of the system as a whole, taking into account intermediaries
> such as caches.

In what way does it help for a cache to cache a blog's homepage and feed
labelled with the same URL compared with caching them with separate
URLs?  A client retrieving one of them doesn't care whether the other
one happens to be cached; surely from the cache's point of view they are
entirely independent?

> It seems a shame that this, perfectly valid, use of HTTP is not
> allowed to system developers that must implement HTML driven
> applications.

If HTML were to provide for this, it still wouldn't be usable because of
the uses of URLs outside of HTML.  As such, implementing this feature
would be a disservice to HTML developers, misleading them into thinking
it's viable, whereas actually using separate URLs works better.

Whether that's a shame isn't really relevant; it's how things are, and
HTML5 doesn't include features out of pitty or a wish that things be
different.

> Furthermore - it does not seem that potential enabling solutions would
> cause incompatibility with existing HTML applications currently not
> concerned with conneg.

Existing deployed browsers don't have this feature.  If a developer were
to use HTML like you suggested above it may then work for him in his
browser, while making his blog's feed URL completely unavailable to
anybody with an older browser.

> Please could I ask that I am cc'd in any responses since I am not
> subscribed to the list.

Noted.

Smylers
-- 
http://twitter.com/Smylers2

Received on Friday, 16 October 2009 18:00:32 UTC