- From: Jim Seidman <jim@rafiki.spyglass.com>
- Date: Tue, 5 Sep 1995 09:06:28 -0500
- To: Roy Fielding <fielding@beach.w3.org>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
At 05:05 PM 9/2/95 -0400, Roy Fielding wrote:
>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.
I think the term "range" is used incorrectly here. The only options are
either, "this very specific type" or "any specific type I haven't mentioned."
The current semantics of Accept are going to lead to some awfully long
requests. Suppose that a browser can accept application/foobar version 1.0,
1.1, 1.2, 2.0, 2.1, 2.2, 2.3, 2.4, and 2.5, but not any later versions, and
prefers 2.x to 1.x. Your accept header now looks like this:
Accept: application/foobar;version=1.0;q=0.5,
application/foobar;version=1.1;q=0.5,
application/foobar;version=2.0;q=1.0,
application/foobar;version=2.1;q=1.0,
application/foobar;version=2.2;q=1.0,
application/foobar;version=2.3;q=1.0,
application/foobar;version=2.4;q=1.0,
application/foobar;version=2.5;q=1.0
I could see this happening with a number of media types - HTML, PNG, Java,
etc. I agree that the semantics are very simple, but as time goes on the
Accept headers could easily start forcing the request into multiple TCP packets.
--
Jim Seidman, Senior Software Engineer
Spyglass Inc., 1230 E. Diehl Road, Naperville IL 60563
Received on Tuesday, 5 September 1995 07:11:50 UTC