- From: Roy Fielding <fielding@beach.w3.org>
- Date: Sat, 02 Sep 1995 17:05:53 -0400
- To: Jim Seidman <jim@rafiki.spyglass.com>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
>The more I think about it, the more uncomfortable I get with the semantics
>of the Accept header. Section 8.1 of the 01 draft of HTTP/1.0 (sorry, I
>don't have the 1.1 pre-draft handy) gives the example of:
>
>Accept: text/*, text/html, text/html;version=2.0, */*
>
>and describes the precedence of each item here. However, it's less clear
>what happens in a case like this:
>
>Accept: text/html;version=3.0; q=1.0, text/html;version=1.0; q=0.5,
> text/plain; q=0.7
>
>Now, support the requested entity is available as a text/html;version=2.0
>document or a plaintext document. What q does a text/html;version=2.0
>document have in this case?
Well, following the algorithm given in the spec, the answer is q=0.
There is nothing ambiguous about it, and it is exactly what the
Accept headers say, so what's the problem?
For obvious reasons, any browser that doesn't include all the ranges
that it wants to accept is broken, unless it wants a 406 response instead.
>If the answer is that q=0 since that type isn't specifically
>listed, then in what cases are these semantics useful?
They are useful for any case where the browser does not want an unlisted type.
After all, the semantics do assume that the user agent has not
gone completely bonkers, and thus is asking for exactly what it wants.
....Roy T. Fielding Department of ICS, University of California, Irvine USA
Visiting Scholar, MIT/LCS + World-Wide Web Consortium
(fielding@w3.org) (fielding@ics.uci.edu)
Received on Saturday, 2 September 1995 14:07:21 UTC