< draft-harada-http-xconnfrom-00.txt		draft-harada-http-xconnfrom-01.txt >
	HTTP Working Group L. Harada, AOL,		HTTP Working Group L. Harada, AOL,
	Internet-Draft H. Hendren, AOL,		Internet-Draft H. Hendren, AOL,
	Expires: 30 January 1998 P. Leach, Microsoft,		Expires: 28 March 1998 P. Leach, Microsoft,
	J. Mogul, DECWRL		J. Mogul, DECWRL
	29 July 1997		12 September 1997
	HTTP X-Connfrom header		HTTP X-Connfrom header
	draft-harada-http-xconnfrom-00.txt		draft-harada-http-xconnfrom-01.txt
	STATUS OF THIS MEMO		STATUS OF THIS MEMO
	This document is an Internet-Draft. Internet-Drafts are		This document is an Internet-Draft. Internet-Drafts are
	working documents of the Internet Engineering Task Force		working documents of the Internet Engineering Task Force
	(IETF), its areas, and its working groups. Note that other		(IETF), its areas, and its working groups. Note that other
	groups may also distribute working documents as		groups may also distribute working documents as
	Internet-Drafts.		Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of		Internet-Drafts are draft documents valid for a maximum of
	skipping to change at page 1, line 43 ¶		skipping to change at page 1, line 43 ¶
	Distribution of this document is unlimited. Please send		Distribution of this document is unlimited. Please send
	comments to the HTTP working group at		comments to the HTTP working group at
	<http-wg@cuckoo.hpl.hp.com>. Discussions of the working		<http-wg@cuckoo.hpl.hp.com>. Discussions of the working
	group are archived at		group are archived at
	<URL:http://www.ics.uci.edu/pub/ietf/http/>. General		<URL:http://www.ics.uci.edu/pub/ietf/http/>. General
	discussions about HTTP and the applications which use HTTP		discussions about HTTP and the applications which use HTTP
	should take place on the <www-talk@w3.org> mailing list.		should take place on the <www-talk@w3.org> mailing list.
	ABSTRACT		ABSTRACT
	HTTP/1.1 defines a Connection header, allowing "the sender		HTTP/1.1 defines a Connection header, allowing 'the sender
	to specify options that are desired for that particular		to specify options that are desired for that particular
	connection and MUST NOT be communicated by proxies over		connection and MUST NOT be communicated by proxies over
	further connections." Because HTTP/1.0 proxies would		further connections.' Because HTTP/1.0 proxies would
	normally forward the Connection header without obeying its		normally forward the Connection header without obeying its
	specification, a Connection header received in an HTTP/1.0		specification, a Connection header received in an HTTP/1.0
	message must normally be treated as if it had been		message must normally be treated as if it had been
	forwarded in error. This document defines an X-Connfrom		forwarded in error. This document defines an X-Connfrom
	header that identifies the sending host, and so is safe to		header that identifies the sending host, and so is safe to
	use in HTTP/1.0 messages. This might be useful in		use in HTTP/1.0 messages. This might be useful in
	experimenting with HTTP/1.0 implementations of applications		experimenting with HTTP/1.0 implementations of applications
	of the HTTP/1.1 Connection mechanism.		of the HTTP/1.1 Connection mechanism.
	Internet-Draft HTTP X-Connfrom header 29 July 1997 13:43		Internet-Draft HTTP X-Connfrom header 12 September 1997 17:30
	TABLE OF CONTENTS		TABLE OF CONTENTS
	1 Introduction 2		1 Introduction 2
	2 Specification 3		2 Specification 3
	3 Security Considerations 4		3 Security Considerations 4
	4 Acknowledgements 4		4 Acknowledgments 4
	5 References 4		5 References 4
	6 Authors' addresses 4		6 Authors' addresses 4
	1 Introduction		1 Introduction
	Some HTTP message headers and options cannot be safely forwarded by a		Some HTTP message headers and options cannot be safely forwarded by a
	naive proxy, but must be treated as hop-by-hop information. Examples		naive proxy, but must be treated as hop-by-hop information. Examples
	include the HTTP/1.1 ``close'' token, used to indicate that the		include the HTTP/1.1 ``close'' token, used to indicate that the
	sender does not want a connection to be persistent [1], and the		sender does not want a connection to be persistent [1], and the
	``Meter'' header, used in the Hit-metering mechanism [2].		``Meter'' header, used in the Hit-metering mechanism [2].
	skipping to change at page 2, line 56 ¶		skipping to change at page 3, line 5 ¶
	requires that the Meter header be sent hop-by-hop, using the		requires that the Meter header be sent hop-by-hop, using the
	Connection header.		Connection header.
	We observe that a Connection-like header that identifies its sender		We observe that a Connection-like header that identifies its sender
	could be safely sent in an HTTP message, since the recipient could		could be safely sent in an HTTP message, since the recipient could
	verify that it had not been improperly forwarded. This verification		verify that it had not been improperly forwarded. This verification
	is done by obtaining (from a lower protocol layer) the network-level		is done by obtaining (from a lower protocol layer) the network-level
	address of the current connection, and then comparing that address		address of the current connection, and then comparing that address
	against the identification in the Connection-like header.		against the identification in the Connection-like header.
	We propose the use of an X-Connfrom header, similar to the Connection		Internet-Draft HTTP X-Connfrom header 12 September 1997 17:30
	Internet-Draft HTTP X-Connfrom header 29 July 1997 13:43
			We propose the use of an X-Connfrom header, similar to the Connection
	header except in its use of an explicit sender identification. The		header except in its use of an explicit sender identification. The
	implementation of this header is entirely optional for both sender		implementation of this header is entirely optional for both sender
	and recipient, and would not be required for compliance with any		and recipient, and would not be required for compliance with any
	version of the HTTP protocol.		version of the HTTP protocol.
	2 Specification		2 Specification
	The words MUST, SHOULD, and MAY in this specification apply only to		The words MUST, SHOULD, and MAY in this specification apply only to
	implementations that choose to support the X-Connfrom header field;		implementations that choose to support the X-Connfrom header field;
	they do not apply to other implementations of any version of the HTTP		they do not apply to other implementations of any version of the HTTP
	skipping to change at page 3, line 56 ¶		skipping to change at page 4, line 5 ¶
	recipient SHOULD act as if any header field(s) listed in the		recipient SHOULD act as if any header field(s) listed in the
	field-value were improperly forwarded by a prior recipient.		field-value were improperly forwarded by a prior recipient.
	The X-Connfrom header field SHOULD NOT be forwarded.		The X-Connfrom header field SHOULD NOT be forwarded.
	Implementations of HTTP/1.1 (and higher HTTP-versions) SHOULD NOT		Implementations of HTTP/1.1 (and higher HTTP-versions) SHOULD NOT
	send messages with X-Connfrom header fields (since the normal		send messages with X-Connfrom header fields (since the normal
	Connection header is available for their use). Any implementation		Connection header is available for their use). Any implementation
	MAY process this field in received messages.		MAY process this field in received messages.
	Examples:		Internet-Draft HTTP X-Connfrom header 12 September 1997 17:30
	Internet-Draft HTTP X-Connfrom header 29 July 1997 13:43		Examples:
	X-Connfrom: @proxy.foo.net, meter		X-Connfrom: @proxy.foo.net:9273, meter
	X-Connfrom: @proxy.foo.net, meter, close		X-Connfrom: @proxy.foo.net:7321, meter, close
	3 Security Considerations		3 Security Considerations
	This design should have identical security properties as the existing		This design should have identical security properties as the existing
	Connection header in the HTTP/1.1 protocol, except that it might		Connection header in the HTTP/1.1 protocol, except that it might
	occasionally expose to a server the name or address of a ``hidden''		occasionally expose to a server the name or address of a ``hidden''
	proxy, in contexts where this would not normally happen. Proxies		proxy, in contexts where this would not normally happen. Proxies
	whose name or address must be kept secret probably should not send		whose name or address must be kept secret probably should not send
	the X-Connect header.		the X-Connect header.
	4 Acknowledgements		4 Acknowledgments
	We would like to thank Roy Fielding, for apparently being the first		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		to suggest (in 1996) the inclusion of a host name in the design of
	HTTP's persistent connection mechanism (for the same basic reasons).		HTTP's persistent connection mechanism (for the same basic reasons).
	5 References		5 References
	1. Roy T. Fielding, Jim Gettys, Jeffrey C. Mogul, Henrik Frystyk		1. Roy T. Fielding, Jim Gettys, Jeffrey C. Mogul, Henrik Frystyk
	Nielsen, and Tim Berners-Lee. Hypertext Transfer Protocol --		Nielsen, and Tim Berners-Lee. Hypertext Transfer Protocol --
	HTTP/1.1. RFC 2068, HTTP Working Group, January, 1997.		HTTP/1.1. RFC 2068, HTTP Working Group, January, 1997.
	skipping to change at page 4, line 52 ¶		skipping to change at page 5, line 4 ¶
	Hudson Hendren		Hudson Hendren
	America Online		America Online
	8619 Westwood Center Drive		8619 Westwood Center Drive
	Vienna, VA 22182, U.S.A		Vienna, VA 22182, U.S.A
	E-mail: hudson@aol.net		E-mail: hudson@aol.net
	Paul J. Leach		Paul J. Leach
	Microsoft		Microsoft
	1 Microsoft Way		1 Microsoft Way
			Internet-Draft HTTP X-Connfrom header 12 September 1997 17:30
	Redmond, Washington, 98052, U.S.A.		Redmond, Washington, 98052, U.S.A.
	Email: paulle@microsoft.com		Email: paulle@microsoft.com
	Internet-Draft HTTP X-Connfrom header 29 July 1997 13:43
	Jeffrey C. Mogul		Jeffrey C. Mogul
	Western Research Laboratory		Western Research Laboratory
	Digital Equipment Corporation		Digital Equipment Corporation
	250 University Avenue		250 University Avenue
	Palo Alto, California, 94305, USA		Palo Alto, California, 94305, USA
	Email: mogul@wrl.dec.com		Email: mogul@wrl.dec.com
End of changes. 15 change blocks.
	17 lines changed or deleted		17 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/