W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1995

Re: Accept headers and media parameters

From: Jim Seidman <jim@rafiki.spyglass.com>
Date: Tue, 5 Sep 1995 09:06:28 -0500
Message-Id: <9509051406.AA22445@rafiki.spyglass.com>
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 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:31:31 EDT