- From: <mike@mykanjo.co.uk>
- Date: Mon, 17 Nov 2008 16:12:12 +0100
"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." I've adressed this subsequently: 'here's the URL: example.com/report you can open this with adobe, excel, powerpoint, word' "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?" Hypertext. "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." I've also already addressed this in the original post; I was quite clear that if browsers don't store the application state when you make a bookmark (headers, URI, HTTP method), then this is an argument for continuing to use URI conneg *aswell* as HTTP conneg; rather than instead. Until the browsers fix this. ;) Browsers should really be bookmarking the whole request/state; the only reason they don't do this is because that's not the way it's done now. The reason for that is lack of incentive due to inadequate tooling, it's not a fair justification to say 'no one does it at the moment because its not necessary', that's disingenuous. The real reason is that HTTP is not adequately supported in HTML, and so browser requests never contain appropriately descriptive headers - hence why conneg was forced into the URI. Alot of people, including the guys in the IRC channel, seem to be blaming the "insufficiencies" of HTTP conneg on HTTP itself. Please feel free to describe these inherent problems with HTTP conneg without implying "browsers and HTML don't do it properly". I know they don't..! I don't consider that a criticism of HTTP, for obvious reasons. "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." Here you go: wget example.com/report --header="Accept: application/pdf" Regards, Mike
Received on Monday, 17 November 2008 07:12:12 UTC