Re: Statistics on reusing request headers in persistent connections

Balint Nagy Endre:
>Koen's modelling does not contain Accept-Language, which will be important
>in future, adding some bytes to headers.
>Accept-Language: hu; q=1, en; q=0.75, ru; q=0.5, de;q=0.25
>(60 bytes, including CRLF)

Well, 200 bytes plus 60 bytes for Accept-Language is still a lot lower than
the 500 byte request messages at which header reuse would get moderately

And of course, there is no need to ever send Accept-Language headers at all
is we have a good(*) specification and implementation of reactive content

(*) By my defition of good, that is: I feel that good reactive negotiation
will always give me a `multiple options' or `none acceptable' with the
alternatives if my accept headers are missing or ambiguous.

A browser should only send Accept-language headers if it suspects that doing
so will prevent a reactive content negotiation cycle.  Thus, you start
sending Accept-language if you got a `multiple options' response to an
earlier request on that server, and it turned out that language was relevant
in the options.

Also, in a hash-based content negotiation scheme, the Accept-language header
could be hashed along with the Accept header.

Basically, everything I said about Accept: im my report also holds for
Accept-language: .

>[Jeffrey Mogul writes:]
>> I think Larry Masinter's hash-based approach still seems like the
>> right one here.

Balint Nagy Endre:

I do not like the hash-based approach very much.  It seems to me that it is
a special case of reactive negotiation.

One of the problems I have with hash-based content selection is that it is
that it places a high penalty (one round trip time) on the first content
selection by the server.  That means that putting up a home page with inline
links that serve .gifs in the normal case, but .jpgs if the browser can
display them is less attractive.

Uner normal reactive negotiation, you could send either
 Accept: image/gif image/jpg
 Accept: image/gif
and no extra round trip would be required.


Received on Wednesday, 1 November 1995 12:59:24 UTC