View: Browse HTML     Browse Raw Text
From: Jeffrey Mogul <mogul@pa.dec.com>
Date: Tue, 18 Mar 97 17:06:09 PST
To: jg@w3.org
Cc: mogul@pa.dec.com, masinter@parc.xerox.com
Subject: New issues-list item: CONNECTION2
Another item (separate from the existing CONNECTION item!)
Probably an "editorial" item.

Problem:

    It appears that for the Connection header mechanism to function
    correctly, a system receiving an HTTP/1.0 (or lower-version) message
    that includes a Connection header must act as if this header, and all
    of the headers it protects, ought to have been removed from the message
    by an intermediate proxy.

    Although RFC2068 does not specifically require this behavior, it
    appears to be implied.  Otherwise, one could not depend on the stated
    property (section 14.10) that the protected options ``MUST NOT be
    communicated by proxies over further connections.''  This should
    probably be clarified in a subsequent draft of the HTTP/1.1
    specification.

Proposed solution: add this paragraph to the end of 14.10 (Connection):

	A system receiving an HTTP/1.0 (or lower-version) message
	that includes a Connection header MUST, for each connection-token
	in this field, remove and ignore any header field(s) from the
	message with the same name as the connection-token.  This
	protects against mistaken forwarding of such header fields by
	pre-HTTP/1.1 proxies.

-Jeff