Re: Comments/Issues on P1

Willy Tarreau <> Tue, 24 April 2012 05:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 908F421F85FD for <>; Mon, 23 Apr 2012 22:36:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.473
X-Spam-Status: No, score=-10.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id p1MSrhL+P98K for <>; Mon, 23 Apr 2012 22:36:12 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CFF7121F8550 for <>; Mon, 23 Apr 2012 22:36:11 -0700 (PDT)
Received: from lists by with local (Exim 4.69) (envelope-from <>) id 1SMYP9-0005jM-Uh for; Tue, 24 Apr 2012 05:35:11 +0000
Received: from ([]) by with esmtp (Exim 4.69) (envelope-from <>) id 1SMYOz-0005hu-T4 for; Tue, 24 Apr 2012 05:35:01 +0000
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1SMYOw-0006CY-8Q for; Tue, 24 Apr 2012 05:34:59 +0000
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q3O5XIoh027331; Tue, 24 Apr 2012 07:33:18 +0200
Date: Tue, 24 Apr 2012 07:33:18 +0200
From: Willy Tarreau <>
To: Amos Jeffries <>
Message-ID: <>
References: <> <>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-1.9
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01
X-W3C-Scan-Sig: 1SMYOw-0006CY-8Q 99e08861fcfd180bfb7bdafdeb06dac0
Subject: Re: Comments/Issues on P1
Archived-At: <>
X-Mailing-List: <> archive/latest/13467
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>
Resent-Message-Id: <>
Resent-Date: Tue, 24 Apr 2012 05:35:11 +0000

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

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