Re: Comments/Issues on P1

[Amos Jeffries <[e-mail]>]

On 24/04/2012 5:33 p.m., Willy Tarreau wrote:
> 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.

What features exactly do you see as non-translatable?

Chunked is not a good example there. It is trivially de-chunked into a 
unknown-lenth 1.0 entity.

The key word in yoru description is "pretends". Intermediaries that fake 
support without actually doing it will get themselves into trouble in 
some cases. The spec clauses are talking about actually compliant 
intermediaries.

>
> 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.

It has not caused major issues to date with the 1.0->1.1 transition. The 
bigger issue has been supposedly 1.1-compatible clients not re-trying 
when presented with 417 and 412 responses. And server ignoring explicit 
1.0 version requests and sending chunked responses regardless.

>
> 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
>