Re: RE-VERSION

I don't see why we need to re-hash this issue every six months.
These arguments are not new, already have responses in the archive,
and do not justify such a major change to the protocol design.

>To summarize, the draft now indicates that the response version
>should be the highest version supported by the server, NOT
>the version of the actual HTTP response.

To reiterate, it has been that way since 1993.

>My problem with this is based on the assumption in the draft
>which dictates that the response version is hop-by-hop.

It is not an assumption -- it is a requirement of HTTP.

>Overall, I beleive that the response version should indicate
>the version of the response message.

It does.  The major number defines the version of the response message.
The only reason we have two numbers is so that one can indicate capability.

>The problems encountered so far, in addition to any confusion
>because the 'response version', isnt the response version,
>are as follows:
>
>A client sends a 1.0 request, a 1.1 server responds with 
>a 1.1 response. ( minus certain http/1.1 features/headers).
>
>GET http://foo/foo.html HTTP/1.0
>blah: blahvalue
>
>HTTP/1.1 200 Ok
>blah: blahvalue
>
>content...
>
>When going through a proxy, how is the proxy supposed to maintain
>the hop-by-hop nature of the responses?

A proxy forwards the response, and thus by definition is capable
of maintaining the hop-by-hop nature.  It is not a difficult task.

>Worse, if a 1.0 proxy is in the stream, it will blindly pass
>the 1.1 response code back to the client, and clearly fails
>to honor the hop-by-hop nature of the response.
>(this is the case with squid, netscape proxy, and presumable others)
>Previously, the 1.0 didnt clearly define what the behaviour
>should be in this case.

That simply isn't true unless you have changed the proxy recently.
1.0 required that the proxy send it's own version in any forwarded
request or response.  The CERN, Netscape, and Apache proxies all obeyed
that restriction last time they were checked.  If Squid managed to scew
that up even after three RFCs have been published on the subject, then
they can't be trusted to have implemented anything right.

We simply cannot get around this requirement. ANY proxy which fails
to indicate its own HTTP-version is incapable of supporting ANY
future enhancements to the protocol, period.  HTTP will be dead.
Think about it: the only thing that does not get forwarded by a
valid proxy is the Request-Line/Status-Line.  ANY other indication
of a version number, e.g. some version number in a header, WILL be
forwarded by an old proxy.  If we can't rely on HTTP-version, what
makes you think we can rely on anything else?

>On deciding what to send in a 1.1 response to a 1.0 client,
>there is no canonical list of things which a 
>server must not send when sending a 1.1 labeled response
>to a 1.0 server.

Sure there is -- RFC 2068.  Everywhere it says that you can't send
something to an HTTP/1.0 client.  They are very easy to find using a
text search.

>There will surely be more than just
>chunked encoding.. This seems like a nightmare for
>proxy/server implementors dictating constant maintenance
>releases to block new server reponse features/headers
>from being sent to 1.0 clients.
>( how can it be prepared to block something which hasn't
>  been invented yet?)

That is FUD.  It is the responsibility of the protocol to make sure
that things which are new are not sent to implementation that do not
understand them.  As proof:

   3.6 Transfer Codings
      A server MUST NOT send transfer-codings to an HTTP/1.0 client.

   4.4 Message Length
      For compatibility with HTTP/1.0 applications, HTTP/1.1 requests
      containing a message-body MUST include a valid Content-Length header
      field unless the server is known to be HTTP/1.1 compliant.

   8.1.3 Proxy Servers
      A proxy server MUST NOT establish a persistent connection with an
      HTTP/1.0 client.

   8.2 Message Transmission Requirements
      An HTTP/1.1 (or later) server that receives a request from a
      HTTP/1.0 (or earlier) client MUST NOT transmit the 100 (continue)
      response;

   10.1 Informational 1xx
      Since HTTP/1.0 did not define any 1xx
      status codes, servers MUST NOT send a 1xx response to an HTTP/1.0
      client except under experimental conditions.

That's all there is to it.  Which one of those requirements is difficult
for an HTTP/1.1 proxy to implement?

>Finally, with things the way they are, does the response
>version actually mean anything useful?  How useful is knowing
>what the highest version supported by the server?

Unlike the server, a user agent cannot easily know in advance that a
given server supports a given capability.  If a future incarnation of
this WG, or some fool programmer who believes that adding incompatible
enhancements to the protocol can be done on their own outside the WG,
manages to screw up the protocol such that it is unsafe for a client
to send its own highest version on the first request, the fact that the
server will respond with its highest minor version allows the client
to start with a lower-version request and improve its later requests
in safety.

Moreover, it allows us to eliminate client implementations that are
currently standing in the way of more evolutionary improvements to HTTP.

>Wouldnt knowing the version of the actual response message
>be more useful and less ambiguous?

No.  The version of the message is indicated by the first number.

....Roy

Received on Saturday, 9 August 1997 04:31:04 UTC