2004/id/draft-harada-http-xconnfrom-01.txt



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
        <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  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]
1	wakaba	1.1
2
3			HTTP Working Group L. Harada, AOL,
4			Internet-Draft H. Hendren, AOL,
5			Expires: 28 March 1998 P. Leach, Microsoft,
6			J. Mogul, DECWRL
7			12 September 1997
8			HTTP X-Connfrom header
9
10			draft-harada-http-xconnfrom-01.txt
11
12
13			STATUS OF THIS MEMO
14
15			This document is an Internet-Draft. Internet-Drafts are
16			working documents of the Internet Engineering Task Force
17			(IETF), its areas, and its working groups. Note that other
18			groups may also distribute working documents as
19			Internet-Drafts.
20
21			Internet-Drafts are draft documents valid for a maximum of
22			six months and may be updated, replaced, or obsoleted by
23			other documents at any time. It is inappropriate to use
24			Internet-Drafts as reference material or to cite them other
25			than as "work in progress."
26
27			To learn the current status of any Internet-Draft, please
28			check the "1id-abstracts.txt" listing contained in the
29			Internet-Drafts Shadow Directories on ftp.is.co.za
30			(Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific
31			Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US
32			West Coast).
33
34			Distribution of this document is unlimited. Please send
35			comments to the HTTP working group at
36			<http-wg@cuckoo.hpl.hp.com>. Discussions of the working
37			group are archived at
38			<URL:http://www.ics.uci.edu/pub/ietf/http/>. General
39			discussions about HTTP and the applications which use HTTP
40			should take place on the <www-talk@w3.org> mailing list.
41
42
43			ABSTRACT
44
45			HTTP/1.1 defines a Connection header, allowing 'the sender
46			to specify options that are desired for that particular
47			connection and MUST NOT be communicated by proxies over
48			further connections.' Because HTTP/1.0 proxies would
49			normally forward the Connection header without obeying its
50			specification, a Connection header received in an HTTP/1.0
51			message must normally be treated as if it had been
52			forwarded in error. This document defines an X-Connfrom
53			header that identifies the sending host, and so is safe to
54			use in HTTP/1.0 messages. This might be useful in
55			experimenting with HTTP/1.0 implementations of applications
56			of the HTTP/1.1 Connection mechanism.
57
58			Harada, Hendren, Leach, Mogul [Page 1]
59
60			Internet-Draft HTTP X-Connfrom header 12 September 1997 17:30
61
62
63			TABLE OF CONTENTS
64
65			1 Introduction 2
66			2 Specification 3
67			3 Security Considerations 4
68			4 Acknowledgments 4
69			5 References 4
70			6 Authors' addresses 4
71
72
73			1 Introduction
74
75			Some HTTP message headers and options cannot be safely forwarded by a
76			naive proxy, but must be treated as hop-by-hop information. Examples
77			include the HTTP/1.1 ``close'' token, used to indicate that the
78			sender does not want a connection to be persistent [1], and the
79			``Meter'' header, used in the Hit-metering mechanism [2].
80
81			HTTP/1.1 includes a Connection general-header, which "allows the
82			sender to specify options that are desired for that particular
83			connection and MUST NOT be communicated by proxies over further
84			connections." According to section 14.10 of RFC2068,
85
86			HTTP/1.1 proxies MUST parse the Connection header field
87			before a message is forwarded and, for each connection-token
88			in this field, remove any header field(s) from the message
89			with the same name as the connection-token.
90
91			The Connection header cannot be sent in HTTP/1.0 messages (i.e., in
92			messages with a Request-Line or Status-Line including an HTTP-version
93			of "HTTP/1.0"), and hence cannot be sent by HTTP/1.0 implementations.
94			More precisely, if an HTTP/1.1 (or later) implementation receives an
95			HTTP/1.0 message with a Connection header, the recipient is forced to
96			assume that the Connection header might have been forwarded
97			improperly, by a naive HTTP/1.0 proxy, and hence the recipient must
98			behave as if any listed header-fields should have been removed from
99			the message by a prior recipient.
100
101			This prevents an HTTP/1.0 implementation from participating in, for
102			example, the Hit-metering mechanism [2], since this mechanism
103			requires that the Meter header be sent hop-by-hop, using the
104			Connection header.
105
106			We observe that a Connection-like header that identifies its sender
107			could be safely sent in an HTTP message, since the recipient could
108			verify that it had not been improperly forwarded. This verification
109			is done by obtaining (from a lower protocol layer) the network-level
110			address of the current connection, and then comparing that address
111			against the identification in the Connection-like header.
112
113
114
115			Harada, Hendren, Leach, Mogul [Page 2]
116
117			Internet-Draft HTTP X-Connfrom header 12 September 1997 17:30
118
119
120			We propose the use of an X-Connfrom header, similar to the Connection
121			header except in its use of an explicit sender identification. The
122			implementation of this header is entirely optional for both sender
123			and recipient, and would not be required for compliance with any
124			version of the HTTP protocol.
125
126
127			2 Specification
128
129			The words MUST, SHOULD, and MAY in this specification apply only to
130			implementations that choose to support the X-Connfrom header field;
131			they do not apply to other implementations of any version of the HTTP
132			protocol.
133
134			The X-Connfrom general-header field allows the sender to specify
135			options that are desired for that particular connection and must not
136			be communicated by proxies over further connections.
137
138			The Connection header has the following grammar:
139
140			X-Connfrom-header = "X-Connfrom" ":"
141			1#( x-conn-hostid \| connection-token)
142
143			x-conn-hostid = "@" host [":" port]
144
145			where host, port, and connection-token are defined as in RFC2068 [1].
146
147			The port value MUST be included if the value is defined for the
148			transport protocol in use; in particular, it MUST be given when the
149			TCP protocol is being used.
150
151			An X-Connfrom header field MUST include exactly one x-conn-hostid
152			value. The x-conn-hostid value SHOULD appear before any
153			connection-token value.
154
155			The recipient of an X-Connfrom header field SHOULD obtain the
156			network-level address (and port, if available) of the sender of the
157			message, and compare it to the x-conn-hostid value. If the values
158			match, then the recipient SHOULD process the remaining
159			connection-token value(s) as defined for the Connection header in the
160			HTTP/1.1 specification. If the values do not match, then the
161			recipient SHOULD act as if any header field(s) listed in the
162			field-value were improperly forwarded by a prior recipient.
163
164			The X-Connfrom header field SHOULD NOT be forwarded.
165
166			Implementations of HTTP/1.1 (and higher HTTP-versions) SHOULD NOT
167			send messages with X-Connfrom header fields (since the normal
168			Connection header is available for their use). Any implementation
169			MAY process this field in received messages.
170
171
172			Harada, Hendren, Leach, Mogul [Page 3]
173
174			Internet-Draft HTTP X-Connfrom header 12 September 1997 17:30
175
176
177			Examples:
178
179			X-Connfrom: @proxy.foo.net:9273, meter
180			X-Connfrom: @proxy.foo.net:7321, meter, close
181
182
183			3 Security Considerations
184
185			This design should have identical security properties as the existing
186			Connection header in the HTTP/1.1 protocol, except that it might
187			occasionally expose to a server the name or address of a ``hidden''
188			proxy, in contexts where this would not normally happen. Proxies
189			whose name or address must be kept secret probably should not send
190			the X-Connect header.
191
192
193			4 Acknowledgments
194
195			We would like to thank Roy Fielding, for apparently being the first
196			to suggest (in 1996) the inclusion of a host name in the design of
197			HTTP's persistent connection mechanism (for the same basic reasons).
198
199
200			5 References
201
202			1. Roy T. Fielding, Jim Gettys, Jeffrey C. Mogul, Henrik Frystyk
203			Nielsen, and Tim Berners-Lee. Hypertext Transfer Protocol --
204			HTTP/1.1. RFC 2068, HTTP Working Group, January, 1997.
205
206			2. J. Mogul and P. Leach. Simple Hit-Metering and Usage-Limiting
207			for HTTP. Internet Draft draft-ietf-http-hit-metering-03.txt, HTTP
208			Working Group, July, 1997. This is a work in progress.
209
210
211			6 Authors' addresses
212
213			Larry Harada
214			America Online
215			690 Fifth Street
216			San Francisco, CA 94107, U.S.A.
217			Email: Larry@aol.net
218
219			Hudson Hendren
220			America Online
221			8619 Westwood Center Drive
222			Vienna, VA 22182, U.S.A
223			E-mail: hudson@aol.net
224
225			Paul J. Leach
226			Microsoft
227			1 Microsoft Way
228
229			Harada, Hendren, Leach, Mogul [Page 4]
230
231			Internet-Draft HTTP X-Connfrom header 12 September 1997 17:30
232
233
234			Redmond, Washington, 98052, U.S.A.
235			Email: paulle@microsoft.com
236
237			Jeffrey C. Mogul
238			Western Research Laboratory
239			Digital Equipment Corporation
240			250 University Avenue
241			Palo Alto, California, 94305, USA
242			Email: mogul@wrl.dec.com
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286			Harada, Hendren, Leach, Mogul [Page 5]