Re: Problems with content negotiation (was: Re: Preemptive and

Larry Masinter writes:
> ...
> 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.
Great, but current servers don't understand accept-hash
(or accept-signature), while use accept*. Adding accept-hash introduces
a HTTP/1.1 - HTTP/1.0 interoperatibility problem. (I demonstrated one
earlier.) The interop problem itsef is:
some 1.0 servers (incuding cern-httpd) will return 200 Ok and one of 
variants when the correct response is 300. We have no way to know,
wether there is no variants or we shall resend more detailed accept*.
(After seeing "HTTP/1.0 200 Ok" we know, that there may be some problems,
when we sent accept*. If we sent accept-hash, we may consider this as
a truncated 300.)
In similar situations I see 3 options:
1. ignore those interoperatibility problems
2. document every discovered problem
3. reject proposals, having interoperability problems
I consider
1. as bad
2. as better, than 1
3. as even worse.
This decision can be made:
a) individually (by each WG member),
b) on a per proposal basis,
c) as a general WG decision.
I like most c and 2.

Comments, alternatives, ideas?

Andrew. (Endre Balint Nagy) <bne@bne.ind.eunet.hu>

Received on Wednesday, 13 September 1995 14:22:32 UTC