Re: Comments/Issues on P1

Hi Amos,

On Tue, Apr 24, 2012 at 03:56:52PM +1200, Amos Jeffries wrote:
> >A server does not appear to be committed to supporting the same HTTP
> >version from request to request, or from one URL to another on the
> >same server. (As an example at the same address and under the same
> >vhost, some URLs might be served by the "real" http server which 
> >fully
> >supports HTTP/1.1, and some by CGI scripts which might only support
> >HTTP/1.0.)
> 
> 
> section 2.6 paragraph 7
>   "Intermediaries that process HTTP messages (i.e., all intermediaries
>    other than those acting as tunnels) MUST send their own HTTP-version
>    in forwarded messages."
> 
> 
> In the example you put forward, the vhost is a gateway intermediary for 
> the CGI script origin. The CGI has its own Server: header and version. 
> The gateway vhost has its own Server: header and version. Te relaying 
> vhost is responsible for upgrading the CGI responses to its 1.1 version.
> 
> The vhost being a gateway intermediary for the CGI is required to 
> downgrade the request for the CGI capabilities, and upgrade the 
> responses with its 1.1 version.
> 
> There is one exception. And that is where the client request arrives 
> with an older version. The server MAY downgrade its version to that 
> supported by the client.

I didn't think about this point on versions, but now it scares me : if
an intermediary pretends to be 1.1-compatible to a client when it talks
to an 1.0 server, it may incite the client to know this and use some of
the 1.1 extensions (eg: chunked encoding in requests) that the server
will never be able to deal with and that are not always transformable
by the intermediary. Similarly, if the intermediary pretends to the
server that the request is 1.1 while the client was 1.0, it may incite
the server to use such features (eg: chunked encoding again) that is
impossible to transform to the client's version.

I think that we should make the intermediary present the highest supported
version between his and the original message, otherwise we'll cause huge
interoperability issues.

Well in fact I think that the issues comes down again to the boundary
between tunnels and other intermediaries, because some intermediaries
will minimally change the messages (eg: add an X-Forwarded-For or Via
header) but will not affect the contents. In this regard they could be
seen as tunnels though they're slightly more active and closer to
gateways.

Anyway, I think that the rule above requires infinite buffer to be
strictly applied, which is problematic.

Regards,
Willy

Received on Tuesday, 24 April 2012 05:35:02 UTC