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

Re: Is forwarding hop-by-hop headers a MUST-level violation?

From: Alex Rousskov <rousskov@measurement-factory.com>
Date: Thu, 15 Jul 2004 23:54:55 -0600 (MDT)
To: David Morris <dwm@xpasc.com>
Cc: ietf-http-wg@w3.org
Message-ID: <Pine.BSF.4.58.0407152335590.70373@measurement-factory.com>

On Wed, 14 Jul 2004, David Morris wrote:

> Better that the result is a precise definition of what should be
> rather than attempts to fix broken code.

I think the proposed definition is precise. The fact that it may fix
some broken code is a side-effect.

> It will be easier to fix broken code if the specification is correct
> and makes sense rather than including kludges.

I do not think the proposed rules are kludges.

> The fundamental issue is that there are origin server headers (in
> the request) and there are headers which apply to the gray area
> in-between. Proxy authentication can only apply to a single node
> because we weren't wise enough (or motivated) to design an
> extensible architecture. But I have designed software which appears
> at the HTTP protocol level as a proxy but which would forward the
> authentication to the next proxy in line. I can believe that my
> proxy would not remove chunked encoding because of buffering issues
> end-end response time, etc. So to mandate removal of that header
> doesn't really apply.

A proxy is free to add the same header if that does not violate the
protocol. Recall that we only define proxy input and output. If you
want to optimize and keep the header, instead of removing and then
adding it back, it is perfectly fine in this context.

> Hop-hop headers MAY convey information for an intermediate
> recipient. If that recipient understands the header and
> complys with its implications, it MUST remove the header. Hop-hop headers
> are the pre-defined set in the RFC and headers specified in the
> Connection: header.

Agreed, except there is no "If that recipient..." part. The recipient
MUST remove (or, in HTTP/1.1 terminology, MUST NOT forward). Is some
cases, the recipient MAY add. In those cases, it may be impossible to
test whether the recipient is internally compliant or buggy, but that
is not important.

> A proxy which doesn't understand a hop-hop header could reject the
> request and perhaps MUST not cache the response but removal of the
> header could do as much damage as forwarding it.

Not if we are still talking about HTTP. Removal of a hop-by-hop header
should do no damage. If there is damage from doing that, the header
was incorrectly designed (and that problem should be fixed in that
header specification, not in the general case).

The bottom line: do you have any objections to fixing the RFC by
saying "proxies MUST NOT forward hop-by-hop headers" explicitly? If
yes, what are those objections?

Let's leave the second change (i.e., listing hop-by-hop headers in the
Connection header) aside, for now.

Thank you,

Received on Friday, 16 July 2004 01:55:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:38 UTC