Re: Header bytes (was Variant IDs)

I certainly won't argue against reducing header bytes.  However,
I think this is making some incorrect assumptions.

> Any scheme that uses lots of bytes will fail in the general market, 
> as a result, and this is the experience already observed by Netscape,
> which has had demonstrably better performance than Mosaic did (partially
> because of Mosaic's incredibly stupid accept header behavior) by observing
> the latency problems caused by long headers, and working to fix this.

Yes, but that is a problem with sending 1k of header fields on every
single request, regardless of the negotiability of the resource.  Since
far less than %0.01 of all URLs are negotiable in content, this is a
bum deal.

However, the notion of including variant information in the URI
(or any) header field applies only to *responses* that *are negotiable*.
In those rare cases, it is worthwhile for the server to send that data.
I too would prefer a compact form, but it isn't going to invent itself.
We may be better off just defining a form that works, and then work
on tokenizing it for the next generation.

Something we have to keep in mind is that there are only three ways
to do negotiation in HTTP:

    1. Never [not really an option]

    2. Preemptive

       The user agent tells the server about what it is capable of
       accepting.  The server selects the variant that best matches
       what the user agent claims to be its capabilities.
       [I claim that this is a non-tractable problem because
       it requires information on both what the UA will accept and
       how well it accepts it in order for the server to make the
       correct decision].

    3. Reactive

       The user agent makes the request for the resource and the
       server responds with the available variant information;
       the user agent can then choose which one is "best" according
       to its own capabilities.  The variant information may be
       supplied via a separate entity (e.g., a 300 response) requiring
       a request delay, inside the response data (e.g., conditional HTML),
       or as a supplement to the "most likely" response (requiring an
       extra request only if the user agent decides one of the other
       variants would be better).

Whether or not there exists something like a Variant-ID is irrelevant
to the above categories, and thus will not save bytes regardless of
how compact it might be.  What it may provide is a more efficient
mechanism for cache updates when preemptive negotiation is used,
but the cost of preemptive negotiation *on every request* will far
outweigh any benefits of Variant-ID, which is the whole point for
using a variant list in the response.

In any case, both preemptive and reactive negotiation suffer from
our inability to communicate the actual characteristics of the
variant dimensions (i.e., how to say it supports HTML tables
but not the INSERT element) and so somebody is going to have to
come up with a solution to that problem before we can say anything
about which method uses fewer bytes.


 ...Roy T. Fielding
    Department of Information & Computer Science    (fielding@ics.uci.edu)
    University of California, Irvine, CA 92717-3425    fax:+1(714)824-4056
    http://www.ics.uci.edu/~fielding/

Received on Saturday, 10 February 1996 02:08:56 UTC