W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2010

Re: I-D Action:draft-nottingham-http-pipeline-00.txt

From: Mark Nottingham <mnot@mnot.net>
Date: Wed, 11 Aug 2010 15:19:15 +1000
Cc: Adrien de Croy <adrien@qbik.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <A32C8E66-15D0-44D3-A48C-7522BE9803E0@mnot.net>
To: Willy Tarreau <w@1wt.eu>
Right. So generate Assoc-Req at the outermost reverse proxy; it's the device that's acting as the origin server in that interchange, after all.

On 11/08/2010, at 3:17 PM, Willy Tarreau wrote:

> On Wed, Aug 11, 2010 at 02:16:20PM +1000, Mark Nottingham wrote:
>>> There are also some legitimate cases where content back needs to be generated by an intermediary, or diverted / requests re-written.  E.g. reverse proxies, payment gateways (e.g. hotels), corporate use policy challenge pages etc.  The server generating the response may never have seen the actual request made by the client.
>> Not sure where you're going here.
> I think Adrien was talking about the same example I gave, where the server
> which generates the header in the response gets a request that has been
> transformed by multiple intermediaries, to the point that the generated
> header won't have any relation with the client's request and that
> intermediaries that have changed it won't be able to correctly rewrite it
> with a single regex. It's basically the same problem as with the Location
> header which is often wrong when emitted by a server behind several reverse
> proxies which rewrite the Host or the URI. Most often, the responses end up
> being forced into the server or forced by intermediaries because doing the
> transformation back is not always simple. The Assoc-Req header here will
> have to experience similarly bad transformations to try to match the request
> URI.
> Regards,
> Willy

Mark Nottingham     http://www.mnot.net/
Received on Wednesday, 11 August 2010 05:19:26 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:22 UTC