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
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]