Re: Server response version number

rlgray@raleigh.ibm.com
Mon, 21 Oct 1996 14:30:30 EST 

** Reply to note from "David W. Morris" <dwm@xpasc.com> Mon, 21 Oct 1996 00:10:06 -0700 (PDT) 
> I don't think this makes sense .... my implemented conclusion has been: 
>    
> 1.  The protocol level returned in the response should declare the level  
>     of the response. 
> 2.  The response protocol level from a server should never be higher 
>     than the request's protocol. 
> 3.  The client must interpret the response based on the response protocol 
>     level, not the request protocol level. 
>    
> I believe there is potential breakage otherwise. 
>    
> Dave Morris 
>    
 
I agree with Larry that the server should always delcare its 
implementation level.  For an orgin server, this version is nothing 
more than a declaration of capabilities, just as the protocol level in 
the request is a statement of the client's capabilites.  At that point, 
server-driven negotiation takes over. 
 
Draft 7, section 3.1 (HTTP Version) says: 
"The protocol versioning policy is intended to allow the sender to 
indicate the format of a message and its capacity for understanding 
further HTTP communication, rather than the features obtained via that 
communication." 
.. 
"The HTTP version of an application is the highest HTTP version for 
which the application is at least coditionally compliant". 
 
We all already know that the protocol negotiation capabilities of HTTP 
need work (which is the reason for PEP, right?), and overloading the 
meaning of the protocol version is sure to cause confusion and cause 
bugs in implementations. 
 
For your first case, there is nothing gained, because there is nothing 
to stop, 1.0 clients from using 1.1 features without declaring 
themselves to be 1.1 compliant. 
 
For your second case, this is a statement of the server's backward 
compatibility.  Since the spec does not require backward compatiblity, 
there is no reason to enforce this.  As a practical matter, 
implementers will, in general, provide the level of compatibility 
required for their market. 
 
For your third case, the client, if downlevel from the server, will 
only interpret the things it understands (which could still be more 
than what is defined in the protocol level it claims compliance with). 
If the client is uplevel of the server, there is nothing to do. 
 
Perhaps you could give an example of a potential breakage? 
 
This thread of discussion, however, does raise the question of why 
backward compatibility is not required by the spec (since it is an 
issue sure to be addressed by implementers). 
 
This leads me to another question: I have seen some discussion 
in the archives of what version an implementation should claim, but 
nothing definitive (maybe I missed it).  When is it safe for an 
implementation to claim "HTTP/1.1" compliance (in terms of standards 
milestones)? 
 
 
 

Thank You, 
Richard L. Gray

cc: "David W. Morris" <dwm@xpasc.com>