HTTP Working Group L. Harada, AOL,
Internet-Draft H. Hendren, AOL,
Expires: 30 January 1998 P. Leach, Microsoft,
J. Mogul, DECWRL
29 July 1997
HTTP X-Connfrom header
draft-harada-http-xconnfrom-00.txt
STATUS OF THIS MEMO
This document is an Internet-Draft. Internet-Drafts are
working documents of the Internet Engineering Task Force
(IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by
other documents at any time. It is inappropriate to use
Internet-Drafts as reference material or to cite them other
than as "work in progress."
To learn the current status of any Internet-Draft, please
check the "1id-abstracts.txt" listing contained in the
Internet-Drafts Shadow Directories on ftp.is.co.za
(Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific
Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US
West Coast).
Distribution of this document is unlimited. Please send
comments to the HTTP working group at
<http-wg@cuckoo.hpl.hp.com>. Discussions of the working
group are archived at
<URL:http://www.ics.uci.edu/pub/ietf/http/>. General
discussions about HTTP and the applications which use HTTP
should take place on the <www-talk@w3.org> mailing list.
ABSTRACT
HTTP/1.1 defines a Connection header, allowing "the sender
to specify options that are desired for that particular
connection and MUST NOT be communicated by proxies over
further connections." Because HTTP/1.0 proxies would
normally forward the Connection header without obeying its
specification, a Connection header received in an HTTP/1.0
message must normally be treated as if it had been
forwarded in error. This document defines an X-Connfrom
header that identifies the sending host, and so is safe to
use in HTTP/1.0 messages. This might be useful in
experimenting with HTTP/1.0 implementations of applications
of the HTTP/1.1 Connection mechanism.
Harada, Hendren, Leach, Mogul [Page 1]
Internet-Draft HTTP X-Connfrom header 29 July 1997 13:43
TABLE OF CONTENTS
1 Introduction 2
2 Specification 3
3 Security Considerations 4
4 Acknowledgements 4
5 References 4
6 Authors' addresses 4
1 Introduction
Some HTTP message headers and options cannot be safely forwarded by a
naive proxy, but must be treated as hop-by-hop information. Examples
include the HTTP/1.1 ``close'' token, used to indicate that the
sender does not want a connection to be persistent [1], and the
``Meter'' header, used in the Hit-metering mechanism [2].
HTTP/1.1 includes a Connection general-header, which "allows the
sender to specify options that are desired for that particular
connection and MUST NOT be communicated by proxies over further
connections." According to section 14.10 of RFC2068,
HTTP/1.1 proxies MUST parse the Connection header field
before a message is forwarded and, for each connection-token
in this field, remove any header field(s) from the message
with the same name as the connection-token.
The Connection header cannot be sent in HTTP/1.0 messages (i.e., in
messages with a Request-Line or Status-Line including an HTTP-version
of "HTTP/1.0"), and hence cannot be sent by HTTP/1.0 implementations.
More precisely, if an HTTP/1.1 (or later) implementation receives an
HTTP/1.0 message with a Connection header, the recipient is forced to
assume that the Connection header might have been forwarded
improperly, by a naive HTTP/1.0 proxy, and hence the recipient must
behave as if any listed header-fields should have been removed from
the message by a prior recipient.
This prevents an HTTP/1.0 implementation from participating in, for
example, the Hit-metering mechanism [2], since this mechanism
requires that the Meter header be sent hop-by-hop, using the
Connection header.
We observe that a Connection-like header that identifies its sender
could be safely sent in an HTTP message, since the recipient could
verify that it had not been improperly forwarded. This verification
is done by obtaining (from a lower protocol layer) the network-level
address of the current connection, and then comparing that address
against the identification in the Connection-like header.
We propose the use of an X-Connfrom header, similar to the Connection
Harada, Hendren, Leach, Mogul [Page 2]
Internet-Draft HTTP X-Connfrom header 29 July 1997 13:43
header except in its use of an explicit sender identification. The
implementation of this header is entirely optional for both sender
and recipient, and would not be required for compliance with any
version of the HTTP protocol.
2 Specification
The words MUST, SHOULD, and MAY in this specification apply only to
implementations that choose to support the X-Connfrom header field;
they do not apply to other implementations of any version of the HTTP
protocol.
The X-Connfrom general-header field allows the sender to specify
options that are desired for that particular connection and must not
be communicated by proxies over further connections.
The Connection header has the following grammar:
X-Connfrom-header = "X-Connfrom" ":"
1#( x-conn-hostid | connection-token)
x-conn-hostid = "@" host [":" port]
where host, port, and connection-token are defined as in RFC2068 [1].
The port value MUST be included if the value is defined for the
transport protocol in use; in particular, it MUST be given when the
TCP protocol is being used.
An X-Connfrom header field MUST include exactly one x-conn-hostid
value. The x-conn-hostid value SHOULD appear before any
connection-token value.
The recipient of an X-Connfrom header field SHOULD obtain the
network-level address (and port, if available) of the sender of the
message, and compare it to the x-conn-hostid value. If the values
match, then the recipient SHOULD process the remaining
connection-token value(s) as defined for the Connection header in the
HTTP/1.1 specification. If the values do not match, then the
recipient SHOULD act as if any header field(s) listed in the
field-value were improperly forwarded by a prior recipient.
The X-Connfrom header field SHOULD NOT be forwarded.
Implementations of HTTP/1.1 (and higher HTTP-versions) SHOULD NOT
send messages with X-Connfrom header fields (since the normal
Connection header is available for their use). Any implementation
MAY process this field in received messages.
Examples:
Harada, Hendren, Leach, Mogul [Page 3]
Internet-Draft HTTP X-Connfrom header 29 July 1997 13:43
X-Connfrom: @proxy.foo.net, meter
X-Connfrom: @proxy.foo.net, meter, close
3 Security Considerations
This design should have identical security properties as the existing
Connection header in the HTTP/1.1 protocol, except that it might
occasionally expose to a server the name or address of a ``hidden''
proxy, in contexts where this would not normally happen. Proxies
whose name or address must be kept secret probably should not send
the X-Connect header.
4 Acknowledgements
We would like to thank Roy Fielding, for apparently being the first
to suggest (in 1996) the inclusion of a host name in the design of
HTTP's persistent connection mechanism (for the same basic reasons).
5 References
1. Roy T. Fielding, Jim Gettys, Jeffrey C. Mogul, Henrik Frystyk
Nielsen, and Tim Berners-Lee. Hypertext Transfer Protocol --
HTTP/1.1. RFC 2068, HTTP Working Group, January, 1997.
2. J. Mogul and P. Leach. Simple Hit-Metering and Usage-Limiting
for HTTP. Internet Draft draft-ietf-http-hit-metering-03.txt, HTTP
Working Group, July, 1997. This is a work in progress.
6 Authors' addresses
Larry Harada
America Online
690 Fifth Street
San Francisco, CA 94107, U.S.A.
Email: Larry@aol.net
Hudson Hendren
America Online
8619 Westwood Center Drive
Vienna, VA 22182, U.S.A
E-mail: hudson@aol.net
Paul J. Leach
Microsoft
1 Microsoft Way
Redmond, Washington, 98052, U.S.A.
Email: paulle@microsoft.com
Harada, Hendren, Leach, Mogul [Page 4]
Internet-Draft HTTP X-Connfrom header 29 July 1997 13:43
Jeffrey C. Mogul
Western Research Laboratory
Digital Equipment Corporation
250 University Avenue
Palo Alto, California, 94305, USA
Email: mogul@wrl.dec.com
Harada, Hendren, Leach, Mogul [Page 5]