[Bug 8797] New: <a type="..."> should influence Accept header sent by browsers

http://www.w3.org/Bugs/Public/show_bug.cgi?id=8797

           Summary: <a type="..."> should influence Accept header sent by
                    browsers
           Product: HTML WG
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: HTML5 spec proposals
        AssignedTo: dave.null@w3.org
        ReportedBy: mackstann@gmail.com
         QAContact: public-html-bugzilla@w3.org
                CC: ian@hixie.ch, mike@w3.org, public-html@w3.org


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.


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Friday, 22 January 2010 00:17:43 UTC