Re: HTTP response version, again

On Mon, 30 Dec 1996, Blake Winton wrote:

> >I'm not sure I agree with your intepretation. My take on the above is that
> >a) The message (request or response) complies with HTTP/1.1
> >AND
> >b) An application is not allowed to claim a version number for a message it
> >sends unless it is at least conditionally compliant with that version of
> >the protocol.
> 
> It most definately says that, but I feel that it says something more...
> 
> >It seems to me tht you are interpreting the above paragraph as if though it
> >said:
> >
> >Applications MUST send the highest version number with which they are at
> >least conditionally compliant in each message.
> 
> Which would seem to be bourne out in a later paragraph of section 3.1
> 
>   The HTTP version of an application is the highest HTTP version for which
>   the application is at least conditionally compliant.
>

But what is being defined here is the protocol version of an application.
Applications and messages are different things.
 
> >The difference is tht I see this paragraph as a protective measure to
> >prevent applications from claiming to support a version number with which
> >they are not at least conditionally compliant, not a requirement that
> >applications advertise the highest version number with which they are
> >compliant.
> 
> I see your point, and I agree that there is a measure of protectiveness
> about it, but I believe that it can and should serve both purposes.  Why
> should we throw away a bit of information which may become useful?
>  
> >> Of course 3.1 also says
> >>   Since the
> >>   protocol version indicates the protocol capability of the sender, a
> >>   proxy/gateway MUST never send a message with a version indicator which
> >>   is greater than its actual version; if a higher version request is
> >>   received, the proxy/gateway MUST either downgrade the request version,
> >>   respond with an error, or switch to tunnel behavior.
> >Good example.
> 
> Thanks.  I'd just like to point out a sentence I missed.
> 
>   Since the
>   protocol version indicates the protocol capability of the sender, ...
> 
> This indicates to me that the only proper response a 1.1 compilant server
> should send back is HTTP/1.1
> 
> Blake.
> 

Yes, but this is a bit ambiguous. I interpret it to mean that a sender
using a protocl version of 1.x claims conditional compliance with HTTP/1.x.
In other words, the version number indicates the capability of the sencder
in the sense that it guarantees a minimum capability on the part of the
sender. You seem to interpret it as meaning tht the sender is asserting tht
1.x is its maximum capability. Both are valid accorcing to the rules of
English grammar. 


For the record, my understanding is that applications should use the
highest version number they understand unless there is some reason they
have to downgrade (e.g., in a proxy situation), so much of this must sound
rather academic. 

My point is simply that the version number in the response indicates the
version number of the response (not the server). As someone else has
pointed out, it is irrelevant whether a 1.1 response would be legal as a
1.0 response, it is still a 1.1 responsed and properly labeled as such.
Servers should not have to try to determine the minimum protocol level for
which their responses are valid. 

> P.S.  I'm reading the mailing list, and it seems to get here before e-mail
>       which is sent directly to me, so I would be as happy not to get two
>       copies of any given message, if the rest of you don't mind.  :)
> 
> 

Sorry, I was being lazy. When I reply, your address shows up on the To: 
line and the list on the Cc: line. To reply to just the list I need to
either cut and paste the address to the To: line or enter it by hand. I'll
do this is in the future. 

Sorry about the multiple typos. I'm using a telnet proxy that can introduce
delays of multiple seconds at unpredictable times.

---
gjw@wnetc.com    /    http://www.wnetc.com/home.html
If you're going to reinvent the wheel, at least try to come
to come up with a better one.

Received on Monday, 30 December 1996 11:21:14 UTC