< draft-ietf-http-options-01.txt		draft-ietf-http-options-02.txt >
	HTTP Working Group J. Mogul, DECWRL,		HTTP Working Group J. Mogul, DECWRL,
	Internet-Draft J. Cohen, Netscape,		Internet-Draft J. Cohen, Netscape,
	Expires: 30 January 1998 S. Lawrence, Agranat Systems		Expires: 28 February 1998 S. Lawrence, Agranat Systems
	30 July 1997		26 August 1997
	Specification of HTTP/1.1 OPTIONS messages		Specification of HTTP/1.1 OPTIONS messages
	draft-ietf-http-options-01.txt		draft-ietf-http-options-02.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 2, line 5 ¶		skipping to change at page 2, line 5 ¶
	options and/or requirements associated with a resource, or		options and/or requirements associated with a resource, or
	the capabilities of a server, without implying a resource		the capabilities of a server, without implying a resource
	action or initiating a resource retrieval.' However,		action or initiating a resource retrieval.' However,
	RFC2068 did not defined a specific syntax for using OPTIONS		RFC2068 did not defined a specific syntax for using OPTIONS
	to make such a determination. This proposal clarifies the		to make such a determination. This proposal clarifies the
	original specification of OPTIONS, adds several new HTTP		original specification of OPTIONS, adds several new HTTP
	message headers to provide syntactic support for OPTIONS,		message headers to provide syntactic support for OPTIONS,
	and establishes new IANA registries to avoid namespace		and establishes new IANA registries to avoid namespace
	conflicts.		conflicts.
	Internet-Draft HTTP OPTIONS messages 30 July 1997 12:34		Internet-Draft HTTP OPTIONS messages 26 August 1997 17:58
	TABLE OF CONTENTS		TABLE OF CONTENTS
	1 Introduction 2		1 Introduction 2
	2 Outline of proposed solution 2		2 Outline of proposed solution 2
	3 Proposed solution 3		3 Proposed solution 3
	3.1 Changes to section 5.1.2, Request-URI 3		3.1 Changes to section 5.1.2, Request-URI 3
	3.2 Changes to section 9.2, OPTIONS 4		3.2 Changes to section 9.2, OPTIONS 4
	3.3 Changes to section 14.31, Max-Forwards 5		3.3 Changes to section 14.31, Max-Forwards 6
	3.4 The Compliance header 6		3.4 The Compliance header 6
	3.5 The Non-Compliance header 7		3.5 The Non-Compliance header 9
	3.6 Changes to sections 14.7 and 14.35, Allow and Public 8		3.6 Changes to sections 14.7 and 14.35, Allow and Public 10
	3.6.1 Alternative A: proxies MUST NOT modify Allow/Public 9		3.6.1 Alternative A: proxies MUST NOT modify Allow/Public 11
	3.6.2 Alternative B: proxies MUST modify Allow/Public 10		3.6.2 Alternative B: proxies MUST modify Allow/Public 12
	3.7 Examples 10		3.7 Examples 12
	4 Security Considerations 11		4 Security Considerations 13
	5 Acknowledgements 12		5 Acknowledgements 13
	6 References 12		6 References 13
	7 Authors' addresses 12		7 Authors' addresses 14
	1 Introduction		1 Introduction
	Section 9.2 of RFC2068 [2] defines an OPTIONS method, to allow a		Section 9.2 of RFC2068 [2] defines an OPTIONS method, to allow a
	"client to determine the options and/or requirements associated with		"client to determine the options and/or requirements associated with
	a resource, or the capabilities of a server, without implying a		a resource, or the capabilities of a server, without implying a
	resource action or initiating a resource retrieval." For example, a		resource action or initiating a resource retrieval." For example, a
	client may wish to determine if a particular HTTP method is supported		client may wish to determine if a particular HTTP method is supported
	by a server, or for a specific resource. Or, a client may wish to		by a server, or for a specific resource. Or, a client may wish to
	determine if a server supports the use of a particular HTTP		determine if a server supports the use of a particular HTTP
	skipping to change at page 3, line 5 ¶		skipping to change at page 3, line 5 ¶
	supported this by requiring a transformation of the		supported this by requiring a transformation of the
	request-URI for a set of methods (actually, only for		request-URI for a set of methods (actually, only for
	OPTIONS); in the current proposal, one can either use the		OPTIONS); in the current proposal, one can either use the
	Host header to address a specific server or proxy, or the		Host header to address a specific server or proxy, or the
	Max-Forwards header to address the Nth server on a path.		Max-Forwards header to address the Nth server on a path.
	- As in RFC2068, the URI '*' refers to the server,		- As in RFC2068, the URI '*' refers to the server,
	independent of any specific resource. Any other URI refers		independent of any specific resource. Any other URI refers
	to the resource normally identified by that URI.		to the resource normally identified by that URI.
	Internet-Draft HTTP OPTIONS messages 30 July 1997 12:34		Internet-Draft HTTP OPTIONS messages 26 August 1997 17:58
	- The descriptions of the Allow and Public headers, and of		- The descriptions of the Allow and Public headers, and of
	the OPTIONS method, are made consistent in their		the OPTIONS method, are made consistent in their
	requirements for proxy editing of OPTIONS responses. (In		requirements for proxy editing of OPTIONS responses. (In
	RFC2068, these sections were contradictory).		RFC2068, these sections were contradictory).
	- A (new) Compliance header is proposed, which allows a		- A (new) Compliance header is proposed, which allows a
	client to specify exactly what options it is asking about,		client to specify exactly what options it is asking about,
	and which allows a server to specify exactly what subset of		and which allows a server to specify exactly what subset of
	those options are supported.		those options are supported.
			Discussion question: it might make more sense to use two
			different header names, one for requests and one for
			responses, to clarify that in a request, the client
			is asking the server about its supported options, and
			in a response, the server is stating its supported
			options.
	- The Compliance header allows several namespaces for		- The Compliance header allows several namespaces for
	options; the set of namespaces is under IANA control. One		options; the set of namespaces is under IANA control. One
	namespace is that of IETF-issued RFCs; this allows a more		namespace is that of IETF-issued RFCs; this allows a more
	specific definition of compliance than is available using		specific definition of compliance than is available using
	protocol version numbers. While various interpretations		protocol version numbers. While various interpretations
	can and do exist about the specific meaning of a protocol		can and do exist about the specific meaning of a protocol
	version number (such as "HTTP/1.1"), the meaning of an RFC		version number (such as "HTTP/1.1"), the meaning of an RFC
	is both well-defined and (more important) immutable.		is both well-defined and (more important) immutable.
	- A (new) Non-Compliance header is proposed, allowing a proxy		- A (new) Non-Compliance header is proposed, allowing a proxy
	skipping to change at page 3, line 39 ¶		skipping to change at page 4, line 5 ¶
	requiring the proxy to edit the rest of the response (which		requiring the proxy to edit the rest of the response (which
	would result in loss of information).		would result in loss of information).
	3 Proposed solution		3 Proposed solution
	Here we propose specific changes to RFC2068.		Here we propose specific changes to RFC2068.
	3.1 Changes to section 5.1.2, Request-URI		3.1 Changes to section 5.1.2, Request-URI
	Remove this:		Remove this:
			Internet-Draft HTTP OPTIONS messages 26 August 1997 17:58
	If a proxy receives a request without any path in the Request-URI		If a proxy receives a request without any path in the Request-URI
	and the method specified is capable of supporting the asterisk form		and the method specified is capable of supporting the asterisk form
	of request, then the last proxy on the request chain MUST forward		of request, then the last proxy on the request chain MUST forward
	the request with "*" as the final Request-URI. For example, the		the request with "*" as the final Request-URI. For example, the
	request		request
	OPTIONS http://www.ics.uci.edu:8001 HTTP/1.1		OPTIONS http://www.ics.uci.edu:8001 HTTP/1.1
	would be forwarded by the proxy as		would be forwarded by the proxy as
	OPTIONS * HTTP/1.1		OPTIONS * HTTP/1.1
	Host: www.ics.uci.edu:8001		Host: www.ics.uci.edu:8001
	after connecting to port 8001 of host "www.ics.uci.edu".		after connecting to port 8001 of host "www.ics.uci.edu".
	Internet-Draft HTTP OPTIONS messages 30 July 1997 12:34
	3.2 Changes to section 9.2, OPTIONS		3.2 Changes to section 9.2, OPTIONS
	Replace:		Replace:
	Unless the server's response is an error, the response MUST NOT		Unless the server's response is an error, the response MUST NOT
	include entity information other than what can be considered as		include entity information other than what can be considered as
	communication options (e.g., Allow is appropriate, but Content-Type		communication options (e.g., Allow is appropriate, but Content-Type
	is not). Responses to this method are not cachable.		is not). Responses to this method are not cachable.
	with:		with:
	An OPTIONS request MAY include Compliance headers (see section		An OPTIONS request MAY include Compliance headers (see section
	14.ZZZ) that indicate the set of options the sender wants		14.ZZZ) that indicate the set of options the sender wants
	information about.		information about.
	Responses to OPTIONS are not cachable, unless caching is explicitly		Responses to OPTIONS are not cachable, unless caching is explicitly
	allowed by the originating sender (see section 13.4).		allowed by the server that first sent the OPTIONS reply (see section
			13.4).
	Replace:		Replace:
	If the Request-URI is an asterisk ("*"), the OPTIONS request is		If the Request-URI is an asterisk ("*"), the OPTIONS request is
	intended to apply to the server as a whole. A 200 response SHOULD		intended to apply to the server as a whole. A 200 response SHOULD
	include any header fields which indicate optional features		include any header fields which indicate optional features
	implemented by the server (e.g., Public), including any extensions		implemented by the server (e.g., Public), including any extensions
	not defined by this specification, in addition to any applicable		not defined by this specification, in addition to any applicable
	general or response-header fields. As described in section 5.1.2, an		general or response-header fields. As described in section 5.1.2, an
	"OPTIONS *" request can be applied through a proxy by specifying the		"OPTIONS *" request can be applied through a proxy by specifying the
	destination server in the Request-URI without any path information.		destination server in the Request-URI without any path information.
	with:		with:
			Internet-Draft HTTP OPTIONS messages 26 August 1997 17:58
	If the Request-URI is an asterisk ("*"), the OPTIONS request is		If the Request-URI is an asterisk ("*"), the OPTIONS request is
	intended to apply to the server as a whole. A 200 response SHOULD		intended to apply to the server as a whole. A 200 response SHOULD
	include a Public header field (see section 14.35). If the request		include a Public header field (see section 14.35). If the request
	includes a Compliance header field, a 200 response SHOULD include a		includes a Compliance header field, a 200 response SHOULD include a
	Compliance header field, indicating the subset of the requested		Compliance header field, indicating the subset of the requested
	Compliance options supported by the server as a whole. The response		Compliance options supported by the server as a whole. The response
	SHOULD include any other applicable general or response-header		SHOULD include any other applicable general or response-header
	fields.		fields.
	If an OPTIONS request includes a Host header (see section 14.23),		If an OPTIONS request includes a Host header (see section 14.23),
	this is the intended destination of the OPTIONS method.		this is the intended destination of the OPTIONS method.
	Proxy servers MUST forward such a message until it reaches		Proxy servers MUST forward such a message until it reaches
	the specified host. If the specified host has more than		the specified host. If the specified host has more than
	one `virtual server', the OPTIONS request applies to the		one `virtual server', the OPTIONS request applies to the
	specified virtual server.		specified virtual server.
	Note: An OPTIONS request may also include a Max-Forwards header,		Note: An OPTIONS request may also include a Max-Forwards header,
	as described in section 14.31. This allows the sender to select		as described in section 14.31. This allows the sender to select
	the Nth proxy on a path, without knowing its hostname.		the Nth proxy on a path, without knowing its hostname.
	Internet-Draft HTTP OPTIONS messages 30 July 1997 12:34
	Replace:		Replace:
	If the Request-URI is not an asterisk, the OPTIONS request applies		If the Request-URI is not an asterisk, the OPTIONS request applies
	only to the options that are available when communicating with that		only to the options that are available when communicating with that
	resource. A 200 response SHOULD include any header fields which		resource. A 200 response SHOULD include any header fields which
	indicate optional features implemented by the server and applicable		indicate optional features implemented by the server and applicable
	to that resource (e.g., Allow), including any extensions not defined		to that resource (e.g., Allow), including any extensions not defined
	by this specification, in addition to any applicable general or		by this specification, in addition to any applicable general or
	response-header fields. If the OPTIONS request passes through a		response-header fields. If the OPTIONS request passes through a
	proxy, the proxy MUST edit the response to exclude those options		proxy, the proxy MUST edit the response to exclude those options
	which apply to a proxy's capabilities and which are known to be		which apply to a proxy's capabilities and which are known to be
	unavailable through that proxy.		unavailable through that proxy.
	with:		with:
			Internet-Draft HTTP OPTIONS messages 26 August 1997 17:58
	If the Request-URI is not an asterisk, the OPTIONS request applies		If the Request-URI is not an asterisk, the OPTIONS request applies
	only to the options that are available when communicating with that		only to the options that are available when communicating with that
	resource. A 200 response SHOULD include an Allow header field (see		resource. A 200 response SHOULD include an Allow header field (see
	section 14.7). If the request includes a Compliance header field, a		section 14.7). If the request includes a Compliance header field, a
	200 response SHOULD include a Compliance header field, indicating		200 response SHOULD include a Compliance header field, indicating
	the subset of the requested Compliance options supported by the		the subset of the requested Compliance options supported by the
	server as a whole. If the subset is empty, the response SHOULD		server as a whole. If the subset is empty, the response SHOULD
	include a Compliance header with an empty field-value. The response		include a Compliance header with an empty field-value. The response
	SHOULD include any other applicable general or response-header		SHOULD include any other applicable general or response-header
	fields.		fields.
	skipping to change at page 6, line 5 ¶		skipping to change at page 6, line 44 ¶
	Each proxy or gateway recipient of a TRACE request containing a Max-		Each proxy or gateway recipient of a TRACE request containing a Max-
	Forwards header field SHOULD check and update its value prior to		Forwards header field SHOULD check and update its value prior to
	forwarding the request.		forwarding the request.
	with:		with:
	Each proxy or gateway recipient of a TRACE or OPTIONS request		Each proxy or gateway recipient of a TRACE or OPTIONS request
	containing a Max-Forwards header field SHOULD check and update its		containing a Max-Forwards header field SHOULD check and update its
	value prior to forwarding the request.		value prior to forwarding the request.
	Internet-Draft HTTP OPTIONS messages 30 July 1997 12:34
	3.4 The Compliance header		3.4 The Compliance header
	Insert in section 14, as a new subsection titled ``14.ZZZ		Insert in section 14, as a new subsection titled ``14.ZZZ
	Compliance''		Compliance''
			Internet-Draft HTTP OPTIONS messages 26 August 1997 17:58
	The Compliance general header field lists a set of options		The Compliance general header field lists a set of options
	that may or may not be supported by a server. In a request		that may or may not be supported by a server. In a request
	message, this header lists the set of options that a client		message, this header lists the set of options that a client
	wishes to know about. In a response message, this header		wishes to know about. In a response message, this header
	lists the set of options that the server complies with.		lists the subset of the requested options that the server
			complies with.
	A compliance header MAY appear on any message, but is		A compliance header MAY appear on any message, but is
	normally used with the OPTIONS request (see section 9.2).		normally used with the OPTIONS request (see section 9.2).
	Compliance = "Compliance" ":" ("*" | *(compliance-option))		Compliance = "Compliance" ":" ("*" | #(compliance-option))
	compliance-option = compliance-namespace "="		compliance-option = compliance-namespace "="
	option-item [ option-params ]		option-item [ option-params ]
	compliance-namespace = token		compliance-namespace = token
	option-item = token | quoted-string		option-item = token | quoted-string
	| rfc-option-item | hdr-option-item		| rfc-option-item | hdr-option-item
	option-params = 1#( ";" option-param)		option-params = 1*( ";" option-param)
	option-param = "cond" | "uncond" | token | quoted-string		option-param = "cond" | "uncond" | token | quoted-string
	A Compliance header field with the field-value of "*" MAY		A Compliance header field with the field-value of "*" MAY
	be used in a request, to ask about all options complied		be used in a request, to ask about all options complied
	with by the recipient. This field-value MUST NOT be used		with by the recipient. This field-value MUST NOT be used
	in a response.		in a response.
			When the Compliance header is present in a response, it takes
			priority over an Allow header or a Public header in the same
			response.
	Tokens used for compliance-namespace, option-item, and		Tokens used for compliance-namespace, option-item, and
	option-param values are case-insensitive.		option-param values are case-insensitive.
	The compliance-namespace is used to select from one of several		The compliance-namespace is used to select from one of several
	namespaces for compliance options. The option-item is used		namespaces for compliance options. The option-item is used
	to specify one or more options within a namespace.		to specify one or more options within a namespace.
	Internet-Draft HTTP OPTIONS messages 30 July 1997 12:34		Internet-Draft HTTP OPTIONS messages 26 August 1997 17:58
	The Internet Assigned Numbers Authority (IANA) acts as a registry		The Internet Assigned Numbers Authority (IANA) acts as a registry
	for compliance-namespace tokens. Initially, the registry contains		for compliance-namespace tokens. Initially, the registry contains
	the following tokens:		the following tokens:
	"RFC" Compliance is with an RFC, specified by an RFC number.		"RFC" Compliance is with an RFC, specified by an RFC number.
	For example, "rfc=1945".		For example, "rfc=1945".
	rfc-option-item = "RFC" "=" RFC-number		rfc-option-item = "RFC" "=" RFC-number
	RFC-number = 1*DIGIT		RFC-number = 1*DIGIT
	skipping to change at page 7, line 40 ¶		skipping to change at page 8, line 40 ¶
	than "cond" or "uncond" with an rfc-option-item or a		than "cond" or "uncond" with an rfc-option-item or a
	hdr-option-item.		hdr-option-item.
	The option-param is used to provide additional parameters.		The option-param is used to provide additional parameters.
	Unconditional compliance with a compliance-option is indicated		Unconditional compliance with a compliance-option is indicated
	using the "uncond" option-param; for example, "rfc=1945;uncond".		using the "uncond" option-param; for example, "rfc=1945;uncond".
	Conditional compliance is indicated using the "cond" option-param;		Conditional compliance is indicated using the "cond" option-param;
	for example, "HDR=Authorization;uncond". Additional option-param		for example, "HDR=Authorization;uncond". Additional option-param
	values might be defined as part of another specification.		values might be defined as part of another specification.
			For the purposes of this header field, an implementation that
			satisfies all the MUST and all the SHOULD requirements for its
			protocols is defined as "unconditionally compliant"; one that
			satisfies all the MUST requirements but not all the SHOULD
			requirements for its protocols is defined as "conditionally
			compliant." See also RFC2119 for a discussion of the terms MUST
			and SHOULD.
	Examples:		Examples:
	Compliance: rfc=2068;uncond		Compliance: rfc=2068;uncond
	Compliance: rfc=1945;uncond, rfc=2068;cond		Compliance: rfc=1945;uncond, rfc=2068;cond
	Compliance: rfc=2068, hdr=SetCookie2		Compliance: rfc=2068, hdr=SetCookie2
			Internet-Draft HTTP OPTIONS messages 26 August 1997 17:58
			Note: when a resource is implemented using a subprogram
			outside the control of the server itself (such as a CGI
			application), and the server cannot ensure that this
			implementation of the resource will comply with a requested
			option, the server's Compliance response-header for the
			resource ought not to assert compliance with the option.
			That is, in case of uncertainty, it is better to imply
			non-compliance when the implementation might comply, than
			to claim compliance when the implementation might not comply.
	3.5 The Non-Compliance header		3.5 The Non-Compliance header
	Insert in section 14, as a new subsection titled ``14.QQQ		Insert in section 14, as a new subsection titled ``14.QQQ
	Non-Compliance''		Non-Compliance''
	Internet-Draft HTTP OPTIONS messages 30 July 1997 12:34
	A proxy server SHOULD add this response-header to a response		A proxy server SHOULD add this response-header to a response
	containing a Compliance header if the proxy does not implement one		containing a Compliance header if the proxy does not implement one
	or more of the options described in the Compliance header.		or more of the options described in the Compliance header.
	Non-Compliance = "Non-Compliance" ":" 1#non-compliance-option		Non-Compliance = "Non-Compliance" ":" 1#non-compliance-option
	proxy-host = host [ ":" port ]		proxy-host = host [ ":" port ]
	non-compliance-option = compliance-option "@" proxy-host		non-compliance-option = compliance-option "@" proxy-host
			Internet-Draft HTTP OPTIONS messages 26 August 1997 17:58
	A non-compliance-option listed in a Non-Compliance response-header		A non-compliance-option listed in a Non-Compliance response-header
	field indicates that the proxy server named by the proxy-host value		field indicates that the proxy server named by the proxy-host value
	does not support the listed compliance-option. The set of		does not support the listed compliance-option. The set of
	non-compliance options SHOULD be a subset of the compliance-options		non-compliance options SHOULD be a subset of the compliance-options
	listed in a Compliance header field of the forwarded message.		listed in a Compliance header field of the forwarded message.
	Note: because the proxy-host value is not authenticated,		Note: because the proxy-host value is not authenticated,
	this is only for advisory purposes (e.g., for debugging).		this is only for advisory purposes (e.g., for debugging).
	If the compliance-option in a non-compliance-option includes one or		If the compliance-option in a non-compliance-option includes one or
	skipping to change at page 9, line 5 ¶		skipping to change at page 10, line 47 ¶
	A proxy MUST NOT delete a Non-Compliance header that it has		A proxy MUST NOT delete a Non-Compliance header that it has
	received from another server.		received from another server.
	3.6 Changes to sections 14.7 and 14.35, Allow and Public		3.6 Changes to sections 14.7 and 14.35, Allow and Public
	The problem we address here is that RFC2068's specifications for the		The problem we address here is that RFC2068's specifications for the
	Allow and Public headers are inconsistent as to whether a proxy		Allow and Public headers are inconsistent as to whether a proxy
	"MUST" or "MUST NOT" edit them. We believe that they should be		"MUST" or "MUST NOT" edit them. We believe that they should be
	consistent. Given that, there are arguments for either alternative:		consistent. Given that, there are arguments for either alternative:
	Internet-Draft HTTP OPTIONS messages 30 July 1997 12:34
	- Requiring proxies to edit these headers provides the		- Requiring proxies to edit these headers provides the
	ultimate client with a simple way to determine if a method		ultimate client with a simple way to determine if a method
	is allowed along the entire path to the origin server.		is allowed along the entire path to the origin server.
	- However, requiring proxies not to edit these headers allows		- However, requiring proxies not to edit these headers allows
	a client to find out about the capabilities of the origin		a client to find out about the capabilities of the origin
	server, since (as RFC2068 says about the Allow header) "the		server, since (as RFC2068 says about the Allow header) "the
	user agent may have other means of communicating with the		user agent may have other means of communicating with the
	origin server."		origin server."
	The second alternative seems more robust. Although we do not		The second alternative seems more robust. Although we do not
			Internet-Draft HTTP OPTIONS messages 26 August 1997 17:58
	currently have an efficient mechanism for finding out if a method is		currently have an efficient mechanism for finding out if a method is
	supported along the entire path, presumbly any request using an		supported along the entire path, presumbly any request using an
	unsupported method would immediately be rejected. However, we list		unsupported method would immediately be rejected. However, we list
	both alternatives in the hope that further discussion will lead to a		both alternatives in the hope that further discussion will lead to a
	more satisfying solution.		more satisfying solution.
	Note: one possibility, not yet explored in detail, is that the		Note: one possibility, not yet explored in detail, is that the
	compliance-namespace could be extended to include a "METH"		compliance-namespace could be extended to include a "METH"
	token, allowing the Compliance header (and hence the		token, allowing the Compliance header (and hence the
	Non-Compliance header) to completely replace the Allow and		Non-Compliance header) to completely replace the Allow and
	skipping to change at page 10, line 5 ¶		skipping to change at page 11, line 46 ¶
	If the response passes through a proxy, the proxy MUST either remove		If the response passes through a proxy, the proxy MUST either remove
	the Public header field or replace it with one applicable to its own		the Public header field or replace it with one applicable to its own
	capabilities.		capabilities.
	with:		with:
	A proxy MUST NOT modify the Public header field even if it does not		A proxy MUST NOT modify the Public header field even if it does not
	understand all the methods specified, since the user agent might		understand all the methods specified, since the user agent might
	have other means of communicating with the origin server.		have other means of communicating with the origin server.
	Internet-Draft HTTP OPTIONS messages 30 July 1997 12:34
	Also, in section 14.7 (Allow), replace		Also, in section 14.7 (Allow), replace
	A proxy MUST NOT modify the Allow header field even if it does not		A proxy MUST NOT modify the Allow header field even if it does not
	understand all the methods specified, since the user agent MAY have		understand all the methods specified, since the user agent MAY have
	other means of communicating with the origin server.		other means of communicating with the origin server.
	with:		with:
	A proxy MUST NOT modify the Allow header field even if it does not		A proxy MUST NOT modify the Allow header field even if it does not
	understand all the methods specified, since the user agent might		understand all the methods specified, since the user agent might
	have other means of communicating with the origin server.		have other means of communicating with the origin server.
	(removes an incorrect use of the term "MAY").		(removes an incorrect use of the term "MAY").
			Internet-Draft HTTP OPTIONS messages 26 August 1997 17:58
	3.6.2 Alternative B: proxies MUST modify Allow/Public		3.6.2 Alternative B: proxies MUST modify Allow/Public
	In section 14.7 (Allow), replace		In section 14.7 (Allow), replace
	A proxy MUST NOT modify the Allow header field even if it does not		A proxy MUST NOT modify the Allow header field even if it does not
	understand all the methods specified, since the user agent MAY have		understand all the methods specified, since the user agent MAY have
	other means of communicating with the origin server.		other means of communicating with the origin server.
	with:		with:
	A proxy MUST remove methods from an Allow header field if it		A proxy MUST remove methods from an Allow header field if it
	skipping to change at page 11, line 4 ¶		skipping to change at page 12, line 34 ¶
	If the response passes through a proxy, the proxy MUST either remove		If the response passes through a proxy, the proxy MUST either remove
	the Public header field or replace it with one applicable to its own		the Public header field or replace it with one applicable to its own
	capabilities.		capabilities.
	with:		with:
	A proxy MUST remove methods from a Public header field if it		A proxy MUST remove methods from a Public header field if it
	does not support the use of those methods.		does not support the use of those methods.
	3.7 Examples		3.7 Examples
	Internet-Draft HTTP OPTIONS messages 30 July 1997 12:34
	To list all extensions supported by proxy "proxy4.microscape.com"		To list all extensions supported by proxy "proxy4.example.com"
	Client sends:		Client sends:
	OPTIONS * HTTP/1.1		OPTIONS * HTTP/1.1
	Host: proxy4.microscape.com		Host: proxy4.example.com
	Compliance: *		Compliance: *
	proxy4.microscape.com responds:		proxy4.example.com responds:
	HTTP/1.1 200 OK		HTTP/1.1 200 OK
	Date: Tue, 22 Jul 1997 20:21:51 GMT		Date: Tue, 22 Jul 1997 20:21:51 GMT
	Server: SuperProxy/1.0		Server: SuperProxy/1.0
	Public: OPTIONS, GET, HEAD, PUT, POST, TRACE		Public: OPTIONS, GET, HEAD, PUT, POST, TRACE
	Compliance: rfc=1543, rfc=2068, hdr=set-proxy		Compliance: rfc=1543, rfc=2068, hdr=set-proxy
	Compliance: hdr=wonder-bar-http-widget-set		Compliance: hdr=wonder-bar-http-widget-set
	Content-Length: 0		Content-Length: 0
			Internet-Draft HTTP OPTIONS messages 26 August 1997 17:58
	Probing for a feature which is not supported by		Probing for a feature which is not supported by
	"proxy4.microscape.com"		"proxy4.example.com"
	Client sends:		Client sends:
	OPTIONS * HTTP/1.1		OPTIONS * HTTP/1.1
	Host: proxy4.microscape.com		Host: proxy4.example.com
	Compliance: HDR=TimeTravel		Compliance: HDR=TimeTravel
	proxy4.microscape.com responds:		proxy4.example.com responds:
	HTTP/1.1 200 OK		HTTP/1.1 200 OK
	Date: Tue, 22 Jul 1997 20:21:52 GMT		Date: Tue, 22 Jul 1997 20:21:52 GMT
	Server: SuperProxy/1.0		Server: SuperProxy/1.0
	Public: OPTIONS, GET, HEAD, PUT, POST, TRACE		Public: OPTIONS, GET, HEAD, PUT, POST, TRACE
	Compliance:		Compliance:
	Content-Length: 0		Content-Length: 0
	4 Security Considerations		4 Security Considerations
	Because the proxy-host value in a Non-Compliance header is not		Because the proxy-host value in a Non-Compliance header is not
	skipping to change at page 12, line 5 ¶		skipping to change at page 13, line 38 ¶
	perhaps one not even involved in the response. However, because the		perhaps one not even involved in the response. However, because the
	proxy-host value is used only for advisory purposes (e.g., for		proxy-host value is used only for advisory purposes (e.g., for
	debugging), there does not appear to be a serious security problem		debugging), there does not appear to be a serious security problem
	with this lack of authentication.		with this lack of authentication.
	Besides, any proxy along the request/response path for an HTTP		Besides, any proxy along the request/response path for an HTTP
	interaction is able to perform far more disruptive (and far less		interaction is able to perform far more disruptive (and far less
	easily detected) modifications of the messages it forwards; this		easily detected) modifications of the messages it forwards; this
	proposal does not change that.		proposal does not change that.
	Internet-Draft HTTP OPTIONS messages 30 July 1997 12:34
	5 Acknowledgements		5 Acknowledgements
	We would like to thank Roy Fielding, Jim Gettys, Paul Leach, Larry		We would like to thank Roy Fielding, Jim Gettys, Paul Leach, Larry
	Masinter, Henrik Frystyk Nielsen, and Ross Patterson for help in		Masinter, Henrik Frystyk Nielsen, Ross Patterson, and Jim Whitehead
	constructing this proposal.		for help in constructing this proposal.
	6 References		6 References
	1. D. Connolly, R. Khare, H. Frystyk Nielsen. PEP - an Extension		1. D. Connolly, R. Khare, H. Frystyk Nielsen. PEP - an Extension
	Mechanism for HTTP. Internet Draft draft-ietf-http-pep-04, HTTP		Mechanism for HTTP. Internet Draft draft-ietf-http-pep-04, HTTP
	Working Group, July, 1997. This is a work in progress.		Working Group, July, 1997. This is a work in progress.
	2. Roy T. Fielding, Jim Gettys, Jeffrey C. Mogul, Henrik Frystyk		2. 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.
			Internet-Draft HTTP OPTIONS messages 26 August 1997 17:58
	7 Authors' addresses		7 Authors' addresses
	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
	Josh Cohen		Josh Cohen
End of changes. 39 change blocks.
	43 lines changed or deleted		80 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/