This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
I've been doing a bit of reading about REST, and content negotation has jumped out at me as an issue that would be nice to have in general but is impractical in a lot of real-world situations. I have a suggestion which I think would make at least a small dent in the practicality gap. Say I have a resource at <http://example.com/users/>. I make it available in a variety of formats, such as HTML and CSV. A web browser will generally get the HTML version because it puts "text/html" in its Accept header at a relatively high priority. I then want to offer an easy way for the web user to download the CSV version of that page. The way that the HTML spec seems to suggest I do this is by putting the following in <head>: <link rel="alternate" type="text/csv" href="/users/"> This makes sense, but has a rather large limitation in that no browser (as far as I know) makes it very easy to find this alternate version. Some browsers *do* display the little feed icon if you have a <link rel="alternate"> with an Atom or RSS content type, but those are the only content types that seem to be usable under this method. What I propose is that when you have the following (already valid HTML as far as I can tell): <a rel="alternate" type="text/csv" href="/users/">Download CSV<a> ... then the browser should give "text/csv" an increased priority in the Accept header it sends when requesting that link. The end result is that we can keep content types out of URLs while still allowing people to readily access different content types of the same resource.
*** This bug has been marked as a duplicate of bug 7697 ***