Re: HTTP response version, again

At 11:27 AM 12/30/96 -0500, Abigail wrote:
>You, Steve Wingard, wrote:
>++ 
>++ At 10:14 AM 12/30/96 -0500, Abigail wrote:
>++ >
>++ >I think the problem is more fundamental. If we force HTTP/1.0 clients
>++ >to accept HTTP/1.1 reponses, they also have to accept HTTP/1.2,
>++ >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.
>++ 
>++ Your conclusion doesn't follow.  An HTTP/1.x server should be aware of the
>++ version number of the client that it is speaking to, and refrain from
using
>++ header information or mechanisms that are not "understood" by that client.
>++ A response from an HTTP/1.1 server can be constructed to be acceptable
>++ to an HTTP/1.0 client, and still be a "legal" HTTP/1.1 response.
>
>
>In that case, it would be easy to put "HTTP/1.0" in the response as
>well, wouldn't it? After all, if you 'downgrade' it to be HTTP/1.0, you
>might as well label it as HTTP/1.0.

That's the whole crux of the argument:   In my opinion, it's NOT an
"HTTP/1.0" response.  It is a legal HTTP/1.1 response that happens
to be sent to an HTTP/1.0 client.   

There seems to be a notion behind the arguments to "label it as 1.0"
that all HTTP/1.1 responses MUST contain header fields that are new
and specific to HTTP/1.1 and will cause problems to an HTTP/1.0 client;
otherwise it's not "really" HTTP/1.1.  I think that notion is incorrect.
The spec is very careful to note things that should be done only when
communicating with HTTP/1.1 clients (Persistent connections,
Pipelining, Transfer codings, etc.), but the absence of those
features in a response to an HTTP/1.0 client does NOT reduce the
"1.1-ness" of the response, IMO.   If there are specific cases where
the capabilities of a 1.0 client would require the creation of a
response that is in violation of the 1.1 specification, I would agree
with the "label it as 1.0" argument.  So far, I have not found any
of those cases on my own.  If others have found them, I welcome
learning about them.

>The problem is that if the server takes out headers that cannot be
>understood by the client, but keeps HTTP/1.1 headers which can safely
>be ignored by the client, but still labels it as HTTP/1.1, the client
>doesn't know it can ignore those unknown headers.

I don't agree.   The 1.0 spec has the same language as 1.1 draft 7 when
it comes to unrecognized response headers:  "Unrecognized response
header fields are treated as Entity-Header fields" and "Unrecognized
Entity-Header fields should be ignored by the recipient".    I think
you're presuming a level of sophistication on the part of existing 1.0
clients that does not exist.  And if a client developer IS putting time
and effort today into making an HTTP/1.0 client aware of responses
labeled "HTTP/1.1" and assuming things based upon that, I'd suggest
that the developer's time would be better served by implementing
HTTP/1.1...

>In my opinion, the server should not include HTTP/1.1 headers which are
>not part of HTTP/1.0 when responding to a HTTP/1.0 request, and label
>the response as being HTTP/1.0.

I agree with the first part of the statement, and disagree with the second.
(But you knew that already.)

Received on Monday, 30 December 1996 09:28:46 UTC