HTTP Working Group L. Harada, AOL, Internet-Draft H. Hendren, AOL, Expires: 28 March 1998 P. Leach, Microsoft, J. Mogul, DECWRL 12 September 1997 HTTP X-Connfrom header draft-harada-http-xconnfrom-01.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 . Discussions of the working group are archived at . General discussions about HTTP and the applications which use HTTP should take place on the 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 12 September 1997 17:30 TABLE OF CONTENTS 1 Introduction 2 2 Specification 3 3 Security Considerations 4 4 Acknowledgments 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. Harada, Hendren, Leach, Mogul [Page 2] Internet-Draft HTTP X-Connfrom header 12 September 1997 17:30 We propose the use of an X-Connfrom header, similar to the Connection 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. Harada, Hendren, Leach, Mogul [Page 3] Internet-Draft HTTP X-Connfrom header 12 September 1997 17:30 Examples: X-Connfrom: @proxy.foo.net:9273, meter X-Connfrom: @proxy.foo.net:7321, 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 Acknowledgments 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 Harada, Hendren, Leach, Mogul [Page 4] Internet-Draft HTTP X-Connfrom header 12 September 1997 17:30 Redmond, Washington, 98052, U.S.A. Email: paulle@microsoft.com 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]