Re: HTTP 1.1 Server Available for Testing

On Thu, 15 Aug 1996, Roy T. Fielding wrote:

[implementor of experimental 1.1 server:]
> >> CL-HTTP responds to 1.0 clients with 1.0 responses.  1.1 responses are
> >> reserved for clients or proxies that also advertise 1.1 functionality.
> > 
[kw:]
> > This brings up a question - How legitimate is it for the same server
> > (identified ipaddress:port) to change personality between HTTP/1.1
> > and HTTP/1.0?  If a server answers some requests with "HTTP/1.1 200 .."
> > and others with "HTTP/1.0 200 .." (or any other response code), this
> > may confuse HTTP/1.1-aware clients.  
> 
> Well, there's no requirement against it (because that particular confusion
> is harmless -- if it ever understands HTTP/1.1 then it is safe to send
> HTTP/1.1-only features to it).

Ok.  But I assume that it should never be necessary for an HTTP/1.1
server to "masquerade" as HTTP/1.0 on its Status-Line, even whan the
server is talking to a 1.0 client?  In fact it may be better if an
experimental server never does this, if only to discover whether there
are any clients out there which refuse responses starting with 
"HTTP/1.1 " (or treat them as 0.9...).

I note that the sentence "CL-HTTP responds to 1.0 clients with 1.0
responses" is ambiguous (to me).  "...responds ... with 1.0 responses"
could mean

a) returns "HTTP/1.0" Status-Line, or
b) returns "HTTP/1.1" Status-Line, but uses only 1.0 features.

I think b) would be the better choice.  

   Klaus

> The intention of the protocol is that the server should always respond
> with the highest minor version of the protocol it understands within
> the same major version of the client's request message.  The restriction
> is that the server cannot use those optional features of the
> higher-level protocol which are forbidden to be sent to such
> an older-version client.  [BTW, there are no required features of
> a protocol that cannot be used with all other minor versions within
> that major version, since that would be an incompatible change and
> thus require a change in the major version.]
> 
> It sounds confusing, but it works in terms of providing a safe mechanism
> of indicating and deploying future protocol changes.

Received on Thursday, 15 August 1996 18:35:52 UTC