Re: Call for Closure - HTTP response version

Simon Spero: 
> On Mon, 30 Dec 1996, sameer wrote:
> 
> > > HTTP/1.7, etc responses. That of course means no HTTP/1.x header can
> > > ever contain something which causes problems with HTTP/1.0 clients.
> > 	That's correct. That *is* why it's called HTTP/1.x, and not
> > HTTP/2.x
> 
> This is indeed the design goal; if there are any situations which 
> violate this constraint in such a way as to return incorrect results 
> without signalling an error,  the specification is in error, and must be 
> corrected before being advanced.
> 
> If there are such cases, then there needs to be some emergency repairs; 
> if there are no such cases, the following is always safe, and will always 
> use 1.1 when available:
> 
> 1) clients which support HTTP/1.1 SHOULD  send 1.1 requests
> 
> 2) servers should echo the lesser of the request version and the 
>    supported protocol version.
> 
> Otherwise, I call for a coin flip. 
If the client doesn't unterstands some parts of the response, that doesn't
mean, that others (proxies) doesn't understand them.
(Think of expires/max-age interference in the spec. 1.0 proxies shouldn't
cache pre-expired responses while 1.1 proxies can cache them according to the
max-age.)
I my interpretation
1) true
2) completely wrong. Response headers not understood by older (currently 1.0)
clients/proxies will be treated as entity headers and ignored/passed untouched.
The spec is right, we can add some additional clarifications, if the WG thinks
AOL proxy implementors misinterpreted the spec properly - I mean it isn't
enough clear. (For me it is enough clean. Maybe because I read proxy related
parts with more attention and neglected some other parts.)

I think the advertising function of the native server version in resposes will be
liked by the browser implementors: another possible cause to say 'please upgrade
to the latest version' (I mean when the AVERAGE difference between the server and
client version is  higher than some threshold.) and will somewhat promote technical
progress (replacing historycal software versions).

Andrew. (Endre "Balint" Nagy) <bne@CareNet.hu>

Received on Tuesday, 31 December 1996 10:56:20 UTC