- From: Smylers <Smylers@stripey.com>
- Date: Mon, 17 Nov 2008 14:12:23 +0000
mike at mykanjo.co.uk writes: > as an example: > > <a href="http://example.com/report">html report</a> > <a href="http://example.com/report" Accept="application/pdf">pdf report</a> > <a href="http://example.com/report" Accept="application/rss+xml">xml report</a> > > So I can send a colleague a message; 'you can get the report at > http://example.com/report', and they can use that URL in any user > agent that is appropriate. Except that in practice on receiving a URL like the above, nearly all users will try it in a web browser; they are unlikely to put it into their PDF viewer, in the hope that a PDF version of the report will happen to be available. > A browser is a special case in which many different content-types are > dealt with. It's also the most common case. Supposing I opened the above URL in a browser, and it gave me the HTML version; how would I even know that the PDF version exists? Suppose my browser has a PDF plug-in so can render either the HTML or PDF versions, it's harder to bookmark a particular version because the URL is no longer sufficient to identify precisely what I was viewing. Browsers could update the way bookmarks work to deal with this, but any exterrnal (such as web-based) bookmarking tools would also need to change. Or suppose the HTML version links to the PDF version. I wish to download the PDF on a remote server, and happen to have an SSH session open to it. So I right-click on the link in the HTML version I'm looking at, choose 'Copy Link Location' from the menu, and in the remote shell type wget then paste in the copied link. If the link explicitly has ?type=PDF in the URL, I get what I want; if the format is specified out of the URL then I've just downloaded the wrong thing. Smylers
Received on Monday, 17 November 2008 06:12:23 UTC