Re: Comments/Issues on P1

On Tue, Apr 24, 2012 at 06:20:03PM +1200, Amos Jeffries wrote:
> 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.

Except that it degrades the connection on two points :
  - loss of persistent connections
  - loss of termination indication

Also it is not possible to do that for the client. If a client wishes to
upload a payload using chunked encoding because it believes the server
supports it, the intermediary will have to upload then close the connection
to mark the end of data, which will generally not work.

Without advertising 1.1 when not necessary, each side would have done the
right thing to accomodate for the other side's version.

> 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'm not discussing "pretending" to support one version while not being
able to do it, it's precisely what causes interop issues with intercepting
intermediaries. I'm really using the word "pretends" in that it tells one
side the other is able to reliably and efficiently consume a message while
in order to make this possible, the message will have to be significantly
degraded, well below what would have been possible without advertising a
version the other side does not support.

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

Well this is a typical example of what can happen if an intermediary
announces itself as 1.1 when the client is only 1.0.

> And server ignoring explicit 
> 1.0 version requests and sending chunked responses regardless.

I've already seen this one too :-)
Another common issue is servers which don't advertise a content-length
nor chunked encoding when they get a connection: close in requests
because internally the fake an 1.0 connection !

Regards,
Willy

Received on Tuesday, 24 April 2012 07:12:43 UTC