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

Re: HTTPbis -10 drafts published : Connection header

From: Roy T. Fielding <fielding@gbiv.com>
Date: Thu, 15 Jul 2010 16:28:04 -0700
Cc: Adrien de Croy <adrien@qbik.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <4764A0D6-B7F4-4AD2-AEB2-8A08EC0C1FDD@gbiv.com>
To: Willy Tarreau <w@1wt.eu>
On Jul 15, 2010, at 12:33 PM, Willy Tarreau wrote:

> On Thu, Jul 15, 2010 at 12:05:12PM -0700, Roy T. Fielding wrote:
>>> And that leaves the question open about what to do if those
>>> headers are found. The worst cases I thought about (Host,
>>> Content-Length) don't work with Apache at least, but they
>>> may cause real trouble on proxies which blindly apply the
>>> spec.
>> 
>> They should not cause any problems, at least no more so than
>> receiving invalid messages.  If the software can't handle weird
>> things then it doesn't belong on the Internet.
> 
> It's not that simple. I have an example of a customer who uses front
> Apache reverse-proxies to perform security controls and to only
> let "clean" requests pass through. Those Apaches also add some
> headers to the requests being forwarded to the servers for logging
> purposes, and it is the only way to reach the servers. Due to that
> implementation mistake, it is possible (and I've tested) for the
> client to make the reverse proxy remove those headers it had just
> added, so that the end point finally does not get the information
> it should have unconditionally got.

Yes, but why is that a problem?  First, the process adding headers
should have already removed the Connection header received -- otherwise
it isn't doing its job.  Second, even without fixing that bug, the
result is fail safe -- the proxy won't be able to forward what it
generated.

> Now, if we want to be fair, there are two points here which are
> causing that issue :
> 
>  - apache's header removal does not happen in the appropriate
>    order.

The order depends on when the module does its stuff, not on
something inherent in Apache.  It is the security-checking module's
responsibility to do the removal earlier (or schedule its additions
later) if that is desired.

>  - apache is used as a reverse-proxy (and is often used that
>    way) but it follows a proxy behaviour instead of a gateway
>    behaviour. But I suspect that when they began, the difference
>    was not clear yet between the two.

It depends on which module is used for that purpose, but yes
the mod_proxy stuff makes for a poor gateway.  The difference
was well known at the time -- I should have vetoed the reverse
proxy features when they were added (they belong in a separate
module).

>> We don't need to protect implementations from their own stupidity.
> 
> I'd not call that stupidity. The spec is huge and very complete,
> and as such it's not easy to get it right first, especially since
> some information are spread all over it (eg: "all other headers
> defined by HTTP/1.1"). It's got *a lot* better since RFC2616, but
> still it's sometimes hard to know whether your implementation is
> compliant or not, depending how a paragraph is read, and I have a
> lot of respect for the persons who spend time trying to follow it
> as closely as possible.
> 
> Well, maybe those could be some points to add to a separate draft to
> try to improve the robustness of new implementations by suggesting
> how to handle a bunch of corner cases.

It wouldn't be confusing at all if it were not for all the
extra requirements that gave types to headers (like hop-by-hop).
They make it sound like there is some header-aware engine going
through and checking the types.  There is no such thing in a well
written intermediary -- every decision should be based on a user
config or the self-descriptive message.

....Roy
Received on Thursday, 15 July 2010 23:28:34 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:23 GMT