Hey Mike, Good answers. :) > The server is not obliged to respect the Accept header, there is nothing > preventing the server from returning a gif even if the Accept header indicates > solely png. This is actually the case with specifying content type in the URL, > since there is nothing preventing example.com/index.html returning a jpeg for > example.
Agreed. > A URI is a resource identifier - content-type is seperate from that, and > concerned with a specific representation of a resource rather than the > resource itself. This was the intention of the Accept header being included in > the HTTP protocol, as per my understanding from the rfc and Roy Fielding's > thesis. Agreed. > 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> Ok, this is an interesting example. Quite a few sites have a "PDF Version" link which could be better done by linking to the same URL with different accept headers - though you'd obviously have to set the Vary cache control header appropriately. > 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. A browser is a special case in which many different > content-types are dealt with. The same benefit is not achieved if the content > is negotiated via the URL, since the user would have to know the type their > user agent required and modify the URL accordingly: > > example.com/report?type=application/rss+xml This seems like a different use case to me and should be possible without any additional modifications. If the server is configured to return PDF if that's the first thing in the Accept header *and* the user pastes the URL into Acrobat instead of their browser, Acrobat would obviously prefer PDF so list that first and have that returned by the server. Note though, that in this case the user agent is responsible for setting the Accept header so we don't need to change the HTML spec at all. The reason this is basically never used today is two fold: 1. It requires correctly configuring the server, beyond just putting files on the file system. Very few people actually do this. 2. It requires the user to see a URL and decide that they want to paste it into Acrobat instead of their browser, without any indication that it would actually work. > To me, this is a much cleaner and more appropriate use of a URI. Not to > mention more user-friendly. Something, I believe should be encouraged - this > is why I feel it would be an important addition to HTML5. I agree this is pretty cool, but I don't see it every gaining traction, because it requires so much more effort to set up than just having report.html and report.pdf and report.xml which work correctly with the server and caches out of the box. The fact that users are so unlikely to put the URL into anything but a browser just makes it even less likely that this effort would be rewarded. Incidentally, a report.pdf in the URL would dramatically increase the chances of the user trying to load it directly in Acrobat instead of their browser because they can see that it's going to be a PDF. It is a cool idea though... Regards, Adrian Sutton. ______________________ Adrian Sutton, CTO UK: +44 1 753 27 2229 US: +1 (650) 292 9659 x717 Ephox <http://www.ephox.com/> Ephox Blogs <http://planet.ephox.com/>, Personal Blog <http://www.symphonious.net/>