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: David Morris <dwm@xpasc.com>
Date: Wed, 14 Jul 2004 11:32:33 -0700 (PDT)
Cc: <ietf-http-wg@w3.org>
Message-ID: <Pine.LNX.4.33.0407141056550.9241-100000@egate.xpasc.com>

On Mon, 12 Jul 2004, Alex Rousskov wrote:

> On Tue, 2004-07-13 at 07:32, David Morris wrote:
> > There should be an exception for ALL headers declared in the
> > specification. It is absurd to bloat the size of HTTP headers to
> > declare information contained in the RFC.
> I would agree 100% if we were talking about changing an Internet Draft.
> Unfortunately, we are working in a context of an existing IETF
> Standard that needs to be fixed. As developer questions and actual
> implementations indicate the "information contained in the RFC [2616]"
> is imprecise, inconsistent, or missing, depending on the hop-by-hop
> header. Existing implementations may honestly forward some hop-by-hop
> headers (while also honoring the Connection header logic). Thus, we
> cannot simply reply on [hop-by-hop header] information contained in
> the RFC".
> If we add explicit hop-by-hop headers to Connection, the above
> mentioned implementations will be automatically "fixed" when they
> receive messages from newer HTTP agents. I suspect that chances of
> breaking an old implementation by listing explicit hop-by-hop headers
> are non-zero, but hope that they are negligible.
> The proposed new wording does two things:
> 	1) documents the intent of the original wording in a normative
> 	and consistent way (proxies MUST NOT forward)
> 	2) attempts to increase the probability that old and new
> 	implementations will do the right thing (by listing all
> 	hop-by-hop headers in the Connection header)
> I do not have strong feelings about (2). Adding a few bytes to a few
> messages does not bother me much, but I am worried that, in some
> corner cases, listing more headers in Connection might expose
> currently undetected vulnerabilities in old products.

The issue of a few bytes is when the additional constant payload results
in an extra MTU on the network for a significant percentage of requests.
Worse when the window size is exceeded. About 50 bytes would be a 10%
probability that a dial-up user required an additional packet (if my
memory of MTUs is correct).

Since we know there are many broken implementations, no matter what we
specify, that will continue. Better that the result is a precise
definition of what should be rather than attempts to fix broken code.

It will be easier to fix broken code if the specification is correct and
makes sense rather than including 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. 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.

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.

In the end, either forwarding a hop-hop header will be relatively benign
OR it will break the transfer. Broken transfers will result in the
potential for repair. Not a bad thing.

Dave Morris
Received on Wednesday, 14 July 2004 14:43:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:25 UTC