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: Jeffrey Mogul <Jeff.Mogul@hp.com>
Date: Mon, 12 Jul 2004 11:36:02 -0700
Message-Id: <200407121836.i6CIa244014454@wera.hpl.hp.com>
To: Alex Rousskov <rousskov@measurement-factory.com>
Cc: ietf-http-wg@w3.org

    How about:
    13.5.1 End-to-end and Hop-by-hop Headers
       For the purpose of defining the behavior of proxies (including
       caches), we divide HTTP headers of a given message into two
       categories: hop-by-hop and end-to-end.
       Hop-by-hop headers are meaningful only for a single
       transport-level connection. Hop-by-hop headers are:
	      - Connection
	      - Keep-Alive
	      - Proxy-Authenticate
	      - Proxy-Authorization
	      - TE
	      - Trailer
	      - Transfer-Encoding
	      - Upgrade
       and all other headers not defined in this specification
       but listed in a Connection header. All hop-by-hop headers
       (other than Connection) MUST be listed in the Connection header.
       Proxies MUST NOT forward hop-by-hop headers.
       All other headers are end-to-end headers. They are
       intended for the ultimate recipient of a message and
       can be meaningful for intermediaries. Proxies MUST forward
       end-to-end headers.
I'd note that "Keep-Alive" is not actually specified as an
HTTP/1.1 header, but is included in this list to prevent
compatibility problems with older code.

I would also suggest adding something like:

    A proxy MUST NOT forward one of the hop-by-hop headers listed
    above even if it is NOT listed in a Connection header of the
    received message.

lest some implementor believe that it is not necessary to check
for errors in the use of Connection.

Alex suggests

    And then remove per-header MUSTs and a SHOULD mentioned above?

Hmm.  I'm not sure this is wise, given the possibility that
an implementor who sees this change between versions of the
spec will notice that the new version of 13.5.1 still enforces
the rule.  In other words, someone might misunderstand a local
wording change as a global requirements change.  I would not
change language in the spec, at this point, if the actual
requirement hasn't changed.

Received on Monday, 12 July 2004 14:36:05 UTC

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