Re: Statistics on reusing request headers in persistent connections

Larry Masinter:
>> I don't believe I ever saw a complete description of how hashing would
>> fit in with the rest of the negotiation stuff.  Is there such a
>> description, or do you plan to write one?
>I'm not sure if content negotiation deserves a separate document from
>the rest of HTTP, or whether all of the issues are independent.

Oh, I was not thinking along the lines of a separate document, more
along the lines of a message on http-wg.  I just searched the http-wg
archives, and the only thing I would find was a message from you
archived as :

|Did you miss the suggestion that clients hash all
|'content-type-determining headers' and send them as a 'accept-hash:'
|instead? I suppose I'm choosing Good and Fast, at the expense of a
|little extra implementation complexity. One way to think of this is
|that hashing is a kind of compression mechanism -- you can compress
|any amount of data into 128 bits, but decompression can be very slow
|and take a large amount of communication.

I don't believe I ever saw the original suggestion referred to above,
and I can't find it in the archive.  Perhaps it was sent in the
timeframe that the http-wg mail server was broken and only delivering
50% of all messages on a good day?

Things I would like to know is:
- how does a server resolve a 'hash miss'?  

- If a server gets
  GET /blah/picture HTTP/1.0
  Accept: image/gif;q=0.5
  Accept-Hash: 4592462137846218

and it has an image/gif and an image/jpg variant, must, may, or must
it not resolve the hash to see if there is an image/jpg;q=1.0 in it?

> I
>don't currently have any plans to write up this idea beyond what's
>been posted, unless there's a call for it.

Could you check if your original accept-hash proposal is in the
http-wg archives?  I could not find it, but that does not mean it is
not there.  If you can't find it either, I suggest you repost the
original article (if you still have it) either now or at the time we
start discussing negotiation again.


Received on Friday, 3 November 1995 02:52:02 UTC