p2-semantics-orig.txt		draft-fielding-http-p2-semantics-00.txt
	Network Working Group R. Fielding		Network Working Group R. Fielding, Ed.
	Internet-Draft UC Irvine		Internet-Draft Day Software
	Obsoletes: 2068, 2616, 2617 J. Gettys		Obsoletes: 2068, 2616, 2617 J. Gettys
	(if approved) Compaq/W3C		(if approved) J. Mogul
	Intended status: Standards Track J. Mogul		Intended status: Standards Track HP
	Expires: March 4, 2008 Compaq		Expires: May 14, 2008 H. Frystyk
	H. Frystyk		Microsoft
	W3C/MIT
	L. Masinter		L. Masinter
	Xerox		Adobe Systems
	P. Leach		P. Leach
	Microsoft		Microsoft
	T. Berners-Lee		T. Berners-Lee
	W3C/MIT		W3C/MIT
	September 2007		November 11, 2007
	HTTP/1.1, part 2: Semantics		HTTP/1.1, part 2: Message Semantics
	draft-fielding-http-p2-semantics-00		draft-fielding-http-p2-semantics-00
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	skipping to change at page 1, line 45		skipping to change at page 1, line 44
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on March 4, 2008.		This Internet-Draft will expire on May 14, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	The Hypertext Transfer Protocol (HTTP) is an application-level		The Hypertext Transfer Protocol (HTTP) is an application-level
	protocol for distributed, collaborative, hypermedia information		protocol for distributed, collaborative, hypermedia information
	systems. HTTP has been in use by the World Wide Web global		systems. HTTP has been in use by the World Wide Web global
	skipping to change at page 3, line 47		skipping to change at page 3, line 47
	10. Header Field Definitions . . . . . . . . . . . . . . . . . . . 29		10. Header Field Definitions . . . . . . . . . . . . . . . . . . . 29
	10.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . . . 29		10.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . . . 29
	10.2. Expect . . . . . . . . . . . . . . . . . . . . . . . . . . 29		10.2. Expect . . . . . . . . . . . . . . . . . . . . . . . . . . 29
	10.3. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 30		10.3. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
	10.4. Location . . . . . . . . . . . . . . . . . . . . . . . . . 31		10.4. Location . . . . . . . . . . . . . . . . . . . . . . . . . 31
	10.5. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . . 31		10.5. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . . 31
	10.6. Referer . . . . . . . . . . . . . . . . . . . . . . . . . 32		10.6. Referer . . . . . . . . . . . . . . . . . . . . . . . . . 32
	10.7. Retry-After . . . . . . . . . . . . . . . . . . . . . . . 32		10.7. Retry-After . . . . . . . . . . . . . . . . . . . . . . . 32
	10.8. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 33		10.8. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 33
	10.9. User-Agent . . . . . . . . . . . . . . . . . . . . . . . . 33		10.9. User-Agent . . . . . . . . . . . . . . . . . . . . . . . . 33
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 34		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
	11.1. Transfer of Sensitive Information . . . . . . . . . . . . 34		12. Security Considerations . . . . . . . . . . . . . . . . . . . 34
	11.2. Encoding Sensitive Information in URI's . . . . . . . . . 35		12.1. Transfer of Sensitive Information . . . . . . . . . . . . 34
	11.3. Location Headers and Spoofing . . . . . . . . . . . . . . 35		12.2. Encoding Sensitive Information in URI's . . . . . . . . . 35
	12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35		12.3. Location Headers and Spoofing . . . . . . . . . . . . . . 35
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35		13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35
			14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
	Appendix A. Changes from RFC 2068 . . . . . . . . . . . . . . . . 36		Appendix A. Changes from RFC 2068 . . . . . . . . . . . . . . . . 36
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37		Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41
	Intellectual Property and Copyright Statements . . . . . . . . . . 43		Intellectual Property and Copyright Statements . . . . . . . . . . 43
	1. Introduction		1. Introduction
	This document will define aspects of HTTP related to request and		This document will define aspects of HTTP related to request and
	response semantics. Right now it only includes the extracted		response semantics. Right now it only includes the extracted
	relevant sections of RFC 2616 with only minor edits.		relevant sections of RFC 2616 with only minor edits.
	skipping to change at page 12, line 44		skipping to change at page 12, line 44
	The semantics of the GET method change to a "partial GET" if the		The semantics of the GET method change to a "partial GET" if the
	request message includes a Range header field. A partial GET		request message includes a Range header field. A partial GET
	requests that only part of the entity be transferred, as described in		requests that only part of the entity be transferred, as described in
	[Part 5]. The partial GET method is intended to reduce unnecessary		[Part 5]. The partial GET method is intended to reduce unnecessary
	network usage by allowing partially-retrieved entities to be		network usage by allowing partially-retrieved entities to be
	completed without transferring data already held by the client.		completed without transferring data already held by the client.
	The response to a GET request is cacheable if and only if it meets		The response to a GET request is cacheable if and only if it meets
	the requirements for HTTP caching described in [Part 6].		the requirements for HTTP caching described in [Part 6].
	See Section 11.2 for security considerations when used for forms.		See Section 12.2 for security considerations when used for forms.
	8.4. HEAD		8.4. HEAD
	The HEAD method is identical to GET except that the server MUST NOT		The HEAD method is identical to GET except that the server MUST NOT
	return a message-body in the response. The metainformation contained		return a message-body in the response. The metainformation contained
	in the HTTP headers in response to a HEAD request SHOULD be identical		in the HTTP headers in response to a HEAD request SHOULD be identical
	to the information sent in response to a GET request. This method		to the information sent in response to a GET request. This method
	can be used for obtaining metainformation about the entity implied by		can be used for obtaining metainformation about the entity implied by
	the request without transferring the entity-body itself. This method		the request without transferring the entity-body itself. This method
	is often used for testing hypertext links for validity,		is often used for testing hypertext links for validity,
	skipping to change at page 13, line 19		skipping to change at page 13, line 19
	information contained in the response MAY be used to update a		information contained in the response MAY be used to update a
	previously cached entity from that resource. If the new field values		previously cached entity from that resource. If the new field values
	indicate that the cached entity differs from the current entity (as		indicate that the cached entity differs from the current entity (as
	would be indicated by a change in Content-Length, Content-MD5, ETag		would be indicated by a change in Content-Length, Content-MD5, ETag
	or Last-Modified), then the cache MUST treat the cache entry as		or Last-Modified), then the cache MUST treat the cache entry as
	stale.		stale.
	8.5. POST		8.5. POST
	The POST method is used to request that the origin server accept the		The POST method is used to request that the origin server accept the
	entity enclosed in the request as a new subordinate of the resource		entity enclosed in the request as data to be processed by the
	identified by the Request-URI in the Request-Line. POST is designed		resource identified by the Request-URI in the Request-Line. POST is
	to allow a uniform method to cover the following functions:		designed to allow a uniform method to cover the following functions:
	o Annotation of existing resources;		o Annotation of existing resources;
	o Posting a message to a bulletin board, newsgroup, mailing list, or		o Posting a message to a bulletin board, newsgroup, mailing list, or
	similar group of articles;		similar group of articles;
	o Providing a block of data, such as the result of submitting a		o Providing a block of data, such as the result of submitting a
	form, to a data-handling process;		form, to a data-handling process;
	o Extending a database through an append operation.		o Extending a database through an append operation.
	The actual function performed by the POST method is determined by the		The actual function performed by the POST method is determined by the
	server and is usually dependent on the Request-URI. The posted		server and is usually dependent on the Request-URI.
	entity is subordinate to that URI in the same way that a file is
	subordinate to a directory containing it, a news article is
	subordinate to a newsgroup to which it is posted, or a record is
	subordinate to a database.
	The action performed by the POST method might not result in a		The action performed by the POST method might not result in a
	resource that can be identified by a URI. In this case, either 200		resource that can be identified by a URI. In this case, either 200
	(OK) or 204 (No Content) is the appropriate response status,		(OK) or 204 (No Content) is the appropriate response status,
	depending on whether or not the response includes an entity that		depending on whether or not the response includes an entity that
	describes the result.		describes the result.
	If a resource has been created on the origin server, the response		If a resource has been created on the origin server, the response
	SHOULD be 201 (Created) and contain an entity which describes the		SHOULD be 201 (Created) and contain an entity which describes the
	status of the request and refers to the new resource, and a Location		status of the request and refers to the new resource, and a Location
	header (see Section 10.4).		header (see Section 10.4).
	Responses to this method are not cacheable, unless the response		Responses to this method are not cacheable, unless the response
	includes appropriate Cache-Control or Expires header fields.		includes appropriate Cache-Control or Expires header fields.
	However, the 303 (See Other) response can be used to direct the user		However, the 303 (See Other) response can be used to direct the user
	agent to retrieve a cacheable resource.		agent to retrieve a cacheable resource.
	POST requests MUST obey the message transmission requirements set out		POST requests MUST obey the message transmission requirements set out
	in [message.transmission.requirements].		in [message.transmission.requirements].
	See Section 11.2 for security considerations.		See Section 12.2 for security considerations.
	8.6. PUT		8.6. PUT
	The PUT method requests that the enclosed entity be stored under the		The PUT method requests that the enclosed entity be stored under the
	supplied Request-URI. If the Request-URI refers to an already		supplied Request-URI. If the Request-URI refers to an already
	existing resource, the enclosed entity SHOULD be considered as a		existing resource, the enclosed entity SHOULD be considered as a
	modified version of the one residing on the origin server. If the		modified version of the one residing on the origin server. If the
	Request-URI does not point to an existing resource, and that URI is		Request-URI does not point to an existing resource, and that URI is
	capable of being defined as a new resource by the requesting user		capable of being defined as a new resource by the requesting user
	agent, the origin server can create the resource with that URI. If a		agent, the origin server can create the resource with that URI. If a
	skipping to change at page 20, line 31		skipping to change at page 20, line 24
	URIs. Clients with link editing capabilities ought to automatically		URIs. Clients with link editing capabilities ought to automatically
	re-link references to the Request-URI to one or more of the new		re-link references to the Request-URI to one or more of the new
	references returned by the server, where possible. This response is		references returned by the server, where possible. This response is
	cacheable unless indicated otherwise.		cacheable unless indicated otherwise.
	The new permanent URI SHOULD be given by the Location field in the		The new permanent URI SHOULD be given by the Location field in the
	response. Unless the request method was HEAD, the entity of the		response. Unless the request method was HEAD, the entity of the
	response SHOULD contain a short hypertext note with a hyperlink to		response SHOULD contain a short hypertext note with a hyperlink to
	the new URI(s).		the new URI(s).
	If the 301 status code is received in response to a request other		If the 301 status code is received in response to a request method
	than GET or HEAD, the user agent MUST NOT automatically redirect the		that is known to be "safe", as defined in Section 8.1.1, then the
	request unless it can be confirmed by the user, since this might		request MAY be automatically redirected by the user agent without
	change the conditions under which the request was issued.		confirmation. Otherwise, the user agent MUST NOT automatically
			redirect the request unless it can be confirmed by the user, since
			this might change the conditions under which the request was issued.
	Note: When automatically redirecting a POST request after		Note: When automatically redirecting a POST request after
	receiving a 301 status code, some existing HTTP/1.0 user agents		receiving a 301 status code, some existing HTTP/1.0 user agents
	will erroneously change it into a GET request.		will erroneously change it into a GET request.
	9.3.3. 302 Found		9.3.3. 302 Found
	The requested resource resides temporarily under a different URI.		The requested resource resides temporarily under a different URI.
	Since the redirection might be altered on occasion, the client SHOULD		Since the redirection might be altered on occasion, the client SHOULD
	continue to use the Request-URI for future requests. This response		continue to use the Request-URI for future requests. This response
	is only cacheable if indicated by a Cache-Control or Expires header		is only cacheable if indicated by a Cache-Control or Expires header
	field.		field.
	The temporary URI SHOULD be given by the Location field in the		The temporary URI SHOULD be given by the Location field in the
	response. Unless the request method was HEAD, the entity of the		response. Unless the request method was HEAD, the entity of the
	response SHOULD contain a short hypertext note with a hyperlink to		response SHOULD contain a short hypertext note with a hyperlink to
	the new URI(s).		the new URI(s).
	If the 302 status code is received in response to a request other		If the 302 status code is received in response to a request method
	than GET or HEAD, the user agent MUST NOT automatically redirect the		that is known to be "safe", as defined in Section 8.1.1, then the
	request unless it can be confirmed by the user, since this might		request MAY be automatically redirected by the user agent without
	change the conditions under which the request was issued.		confirmation. Otherwise, the user agent MUST NOT automatically
			redirect the request unless it can be confirmed by the user, since
			this might change the conditions under which the request was issued.
	Note: RFC 1945 and RFC 2068 specify that the client is not allowed		Note: RFC 1945 and RFC 2068 specify that the client is not allowed
	to change the method on the redirected request. However, most		to change the method on the redirected request. However, most
	existing user agent implementations treat 302 as if it were a 303		existing user agent implementations treat 302 as if it were a 303
	response, performing a GET on the Location field-value regardless		response, performing a GET on the Location field-value regardless
	of the original request method. The status codes 303 and 307 have		of the original request method. The status codes 303 and 307 have
	been added for servers that wish to make unambiguously clear which		been added for servers that wish to make unambiguously clear which
	kind of reaction is expected of the client.		kind of reaction is expected of the client.
	9.3.4. 303 See Other		9.3.4. 303 See Other
	skipping to change at page 23, line 13		skipping to change at page 23, line 9
	field.		field.
	The temporary URI SHOULD be given by the Location field in the		The temporary URI SHOULD be given by the Location field in the
	response. Unless the request method was HEAD, the entity of the		response. Unless the request method was HEAD, the entity of the
	response SHOULD contain a short hypertext note with a hyperlink to		response SHOULD contain a short hypertext note with a hyperlink to
	the new URI(s) , since many pre-HTTP/1.1 user agents do not		the new URI(s) , since many pre-HTTP/1.1 user agents do not
	understand the 307 status. Therefore, the note SHOULD contain the		understand the 307 status. Therefore, the note SHOULD contain the
	information necessary for a user to repeat the original request on		information necessary for a user to repeat the original request on
	the new URI.		the new URI.
	If the 307 status code is received in response to a request other		If the 307 status code is received in response to a request method
	than GET or HEAD, the user agent MUST NOT automatically redirect the		that is known to be "safe", as defined in Section 8.1.1, then the
	request unless it can be confirmed by the user, since this might		request MAY be automatically redirected by the user agent without
	change the conditions under which the request was issued.		confirmation. Otherwise, the user agent MUST NOT automatically
			redirect the request unless it can be confirmed by the user, since
			this might change the conditions under which the request was issued.
	9.4. Client Error 4xx		9.4. Client Error 4xx
	The 4xx class of status code is intended for cases in which the		The 4xx class of status code is intended for cases in which the
	client seems to have erred. Except when responding to a HEAD		client seems to have erred. Except when responding to a HEAD
	request, the server SHOULD include an entity containing an		request, the server SHOULD include an entity containing an
	explanation of the error situation, and whether it is a temporary or		explanation of the error situation, and whether it is a temporary or
	permanent condition. These status codes are applicable to any		permanent condition. These status codes are applicable to any
	request method. User agents SHOULD display any included entity to		request method. User agents SHOULD display any included entity to
	the user.		the user.
	skipping to change at page 31, line 26		skipping to change at page 31, line 26
	10.4. Location		10.4. Location
	The Location response-header field is used to redirect the recipient		The Location response-header field is used to redirect the recipient
	to a location other than the Request-URI for completion of the		to a location other than the Request-URI for completion of the
	request or identification of a new resource. For 201 (Created)		request or identification of a new resource. For 201 (Created)
	responses, the Location is that of the new resource which was created		responses, the Location is that of the new resource which was created
	by the request. For 3xx responses, the location SHOULD indicate the		by the request. For 3xx responses, the location SHOULD indicate the
	server's preferred URI for automatic redirection to the resource.		server's preferred URI for automatic redirection to the resource.
	The field value consists of a single absolute URI.		The field value consists of a single absolute URI.
	Location = "Location" ":" absoluteURI		Location = "Location" ":" absoluteURI [ "#" fragment ]
	An example is:		An example is:
	Location: http://www.w3.org/pub/WWW/People.html		Location: http://www.w3.org/pub/WWW/People.html
	Note: The Content-Location header field ([Part 3]) differs from		Note: The Content-Location header field ([Part 3]) differs from
	Location in that the Content-Location identifies the original		Location in that the Content-Location identifies the original
	location of the entity enclosed in the request. It is therefore		location of the entity enclosed in the request. It is therefore
	possible for a response to contain header fields for both Location		possible for a response to contain header fields for both Location
	and Content-Location.		and Content-Location.
	skipping to change at page 32, line 35		skipping to change at page 32, line 35
	its own URI, such as input from the user keyboard.		its own URI, such as input from the user keyboard.
	Referer = "Referer" ":" ( absoluteURI | relativeURI )		Referer = "Referer" ":" ( absoluteURI | relativeURI )
	Example:		Example:
	Referer: http://www.w3.org/hypertext/DataSources/Overview.html		Referer: http://www.w3.org/hypertext/DataSources/Overview.html
	If the field value is a relative URI, it SHOULD be interpreted		If the field value is a relative URI, it SHOULD be interpreted
	relative to the Request-URI. The URI MUST NOT include a fragment.		relative to the Request-URI. The URI MUST NOT include a fragment.
	See Section 11.2 for security considerations.		See Section 12.2 for security considerations.
	10.7. Retry-After		10.7. Retry-After
	The Retry-After response-header field can be used with a 503 (Service		The Retry-After response-header field can be used with a 503 (Service
	Unavailable) response to indicate how long the service is expected to		Unavailable) response to indicate how long the service is expected to
	be unavailable to the requesting client. This field MAY also be used		be unavailable to the requesting client. This field MAY also be used
	with any 3xx (Redirection) response to indicate the minimum time the		with any 3xx (Redirection) response to indicate the minimum time the
	user-agent is asked wait before issuing the redirected request. The		user-agent is asked wait before issuing the redirected request. The
	value of this field can be either an HTTP-date or an integer number		value of this field can be either an HTTP-date or an integer number
	of seconds (in decimal) after the time of the response.		of seconds (in decimal) after the time of the response.
	skipping to change at page 33, line 25		skipping to change at page 33, line 25
	application.		application.
	Server = "Server" ":" 1*( product | comment )		Server = "Server" ":" 1*( product | comment )
	Example:		Example:
	Server: CERN/3.0 libwww/2.17		Server: CERN/3.0 libwww/2.17
	If the response is being forwarded through a proxy, the proxy		If the response is being forwarded through a proxy, the proxy
	application MUST NOT modify the Server response-header. Instead, it		application MUST NOT modify the Server response-header. Instead, it
	SHOULD include a Via field (as described in [Part 1]).		MUST include a Via field (as described in [Part 1]).
	Note: Revealing the specific software version of the server might		Note: Revealing the specific software version of the server might
	allow the server machine to become more vulnerable to attacks		allow the server machine to become more vulnerable to attacks
	against software that is known to contain security holes. Server		against software that is known to contain security holes. Server
	implementors are encouraged to make this field a configurable		implementors are encouraged to make this field a configurable
	option.		option.
	10.9. User-Agent		10.9. User-Agent
	The User-Agent request-header field contains information about the		The User-Agent request-header field contains information about the
	skipping to change at page 34, line 5		skipping to change at page 34, line 5
	subproducts which form a significant part of the user agent. By		subproducts which form a significant part of the user agent. By
	convention, the product tokens are listed in order of their		convention, the product tokens are listed in order of their
	significance for identifying the application.		significance for identifying the application.
	User-Agent = "User-Agent" ":" 1*( product | comment )		User-Agent = "User-Agent" ":" 1*( product | comment )
	Example:		Example:
	User-Agent: CERN-LineMode/2.15 libwww/2.17b3		User-Agent: CERN-LineMode/2.15 libwww/2.17b3
	11. Security Considerations		11. IANA Considerations
			TBD.
			12. Security Considerations
	This section is meant to inform application developers, information		This section is meant to inform application developers, information
	providers, and users of the security limitations in HTTP/1.1 as		providers, and users of the security limitations in HTTP/1.1 as
	described by this document. The discussion does not include		described by this document. The discussion does not include
	definitive solutions to the problems revealed, though it does make		definitive solutions to the problems revealed, though it does make
	some suggestions for reducing security risks.		some suggestions for reducing security risks.
	11.1. Transfer of Sensitive Information		12.1. Transfer of Sensitive Information
	Like any generic data transfer protocol, HTTP cannot regulate the		Like any generic data transfer protocol, HTTP cannot regulate the
	content of the data that is transferred, nor is there any a priori		content of the data that is transferred, nor is there any a priori
	method of determining the sensitivity of any particular piece of		method of determining the sensitivity of any particular piece of
	information within the context of any given request. Therefore,		information within the context of any given request. Therefore,
	applications SHOULD supply as much control over this information as		applications SHOULD supply as much control over this information as
	possible to the provider of that information. Four header fields are		possible to the provider of that information. Four header fields are
	worth special mention in this context: Server, Via, Referer and From.		worth special mention in this context: Server, Via, Referer and From.
	Revealing the specific software version of the server might allow the		Revealing the specific software version of the server might allow the
	skipping to change at page 35, line 9		skipping to change at page 35, line 15
	We suggest, though do not require, that a convenient toggle interface		We suggest, though do not require, that a convenient toggle interface
	be provided for the user to enable or disable the sending of From and		be provided for the user to enable or disable the sending of From and
	Referer information.		Referer information.
	The User-Agent (Section 10.9) or Server (Section 10.8) header fields		The User-Agent (Section 10.9) or Server (Section 10.8) header fields
	can sometimes be used to determine that a specific client or server		can sometimes be used to determine that a specific client or server
	have a particular security hole which might be exploited.		have a particular security hole which might be exploited.
	Unfortunately, this same information is often used for other valuable		Unfortunately, this same information is often used for other valuable
	purposes for which HTTP currently has no better mechanism.		purposes for which HTTP currently has no better mechanism.
	11.2. Encoding Sensitive Information in URI's		12.2. Encoding Sensitive Information in URI's
	Because the source of a link might be private information or might		Because the source of a link might be private information or might
	reveal an otherwise private information source, it is strongly		reveal an otherwise private information source, it is strongly
	recommended that the user be able to select whether or not the		recommended that the user be able to select whether or not the
	Referer field is sent. For example, a browser client could have a		Referer field is sent. For example, a browser client could have a
	toggle switch for browsing openly/anonymously, which would		toggle switch for browsing openly/anonymously, which would
	respectively enable/disable the sending of Referer and From		respectively enable/disable the sending of Referer and From
	information.		information.
	Clients SHOULD NOT include a Referer header field in a (non-secure)		Clients SHOULD NOT include a Referer header field in a (non-secure)
	HTTP request if the referring page was transferred with a secure		HTTP request if the referring page was transferred with a secure
	protocol.		protocol.
	Authors of services which use the HTTP protocol SHOULD NOT use GET		Authors of services which use the HTTP protocol SHOULD NOT use GET
	based forms for the submission of sensitive data, because this will		based forms for the submission of sensitive data, because this will
	cause this data to be encoded in the Request-URI. Many existing		cause this data to be encoded in the Request-URI. Many existing
	servers, proxies, and user agents will log the request URI in some		servers, proxies, and user agents will log the request URI in some
	place where it might be visible to third parties. Servers can use		place where it might be visible to third parties. Servers can use
	POST-based form submission instead		POST-based form submission instead
	11.3. Location Headers and Spoofing		12.3. Location Headers and Spoofing
	If a single server supports multiple organizations that do not trust		If a single server supports multiple organizations that do not trust
	one another, then it MUST check the values of Location and Content-		one another, then it MUST check the values of Location and Content-
	Location headers in responses that are generated under control of		Location headers in responses that are generated under control of
	said organizations to make sure that they do not attempt to		said organizations to make sure that they do not attempt to
	invalidate resources over which they have no authority.		invalidate resources over which they have no authority.
	12. Acknowledgments		13. Acknowledgments
	Based on an XML translation of RFC 2616 by Julian Reschke.		Based on an XML translation of RFC 2616 by Julian Reschke.
	13. References		14. References
	[Luo1998] Luotonen, A., "Tunneling TCP based protocols through Web		[Luo1998] Luotonen, A., "Tunneling TCP based protocols through Web
	proxy servers", Work in Progress.		proxy servers", Work in Progress.
	[RFC1123] Braden, R., "Requirements for Internet Hosts - Application		[RFC1123] Braden, R., "Requirements for Internet Hosts - Application
	and Support", STD 3, RFC 1123, October 1989.		and Support", STD 3, RFC 1123, October 1989.
	[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.		[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.
	Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",		Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
	RFC 2068, January 1997.		RFC 2068, January 1997.
	skipping to change at page 41, line 4		skipping to change at page 41, line 9
	414 Request-URI Too Long 27		414 Request-URI Too Long 27
	415 Unsupported Media Type 27		415 Unsupported Media Type 27
	416 Requested Range Not Satisfiable 27		416 Requested Range Not Satisfiable 27
	417 Expectation Failed 27		417 Expectation Failed 27
	500 Internal Server Error 27		500 Internal Server Error 27
	501 Not Implemented 28		501 Not Implemented 28
	502 Bad Gateway 28		502 Bad Gateway 28
	503 Service Unavailable 28		503 Service Unavailable 28
	504 Gateway Timeout 28		504 Gateway Timeout 28
	505 HTTP Version Not Supported 28		505 HTTP Version Not Supported 28
	T		T
	TRACE method 15		TRACE method 15
	U		U
	UNLINK method 37		UNLINK method 37
	User-Agent header 33		User-Agent header 33
	Authors' Addresses		Authors' Addresses
	Roy T. Fielding		Roy T. Fielding (editor)
	Department of Information and Computer Science		Day Software
	University of California, Irvine		23 Corporate Plaza DR, Suite 280
	Irvine, CA 92697-3425		Newport Beach, CA 92660
			USA
	Fax: +1(949)824-1715		Phone: +1-949-706-5300
	Email: fielding@ics.uci.edu		Fax: +1-949-706-5305
			Email: fielding@gbiv.com
			URI: http://roy.gbiv.com/
	James Gettys		James Gettys
	World Wide Web Consortium		Hewlett-Packard Company
	MIT Laboratory for Computer Science, NE43-356		HP Labs, Cambridge Research Laboratory
	545 Technology Square		One Cambridge Center
	Cambridge, MA 02139		Cambridge, MA 02138
			USA
	Fax: +1(617)258-8682		Email: Jim.Gettys@hp.com
	Email: jg@w3.org
	Jeffrey C. Mogul		Jeffrey C. Mogul
	Compaq Computer Corporation		Hewlett-Packard Company
	Western Research Laboratory		HP Labs, Large Scale Systems Group
	250 University Avenue		1501 Page Mill Road, MS 1177
	Palo Alto, CA 94305		Palo Alto, CA 94304
			USA
	Email: mogul@wrl.dec.com
			Email: JeffMogul@acm.org
	Henrik Frystyk Nielsen		Henrik Frystyk Nielsen
	World Wide Web Consortium		Microsoft Corporation
	MIT Laboratory for Computer Science, NE43-356		1 Microsoft Way
	545 Technology Square		Redmond, WA 98052
	Cambridge, MA 02139		USA
			Email: henrikn@microsoft.com
	Fax: +1(617)258-8682
	Email: frystyk@w3.org
	Larry Masinter		Larry Masinter
	Xerox Corporation		Adobe Systems, Incorporated
	MIT Laboratory for Computer Science, NE43-356		345 Park Ave
	3333 Coyote Hill Road		San Jose, CA 95110
	Palo Alto, CA 94034		USA
	Email: masinter@parc.xerox.com		Email: LMM@acm.org
			URI: http://larry.masinter.net/
	Paul J. Leach		Paul J. Leach
	Microsoft Corporation		Microsoft Corporation
	1 Microsoft Way		1 Microsoft Way
	Redmond, WA 98052		Redmond, WA 98052
	Email: paulle@microsoft.com		Email: paulle@microsoft.com
	Tim Berners-Lee		Tim Berners-Lee
	World Wide Web Consortium		World Wide Web Consortium
	MIT Laboratory for Computer Science, NE43-356		MIT Laboratory for Computer Science
	545 Technology Square		545 Technology Square
	Cambridge, MA 02139		Cambridge, MA 02139
			USA
	Fax: +1(617)258-8682		Fax: +1 (617) 258 8682
	Email: timbl@w3.org		Email: timbl@w3.org
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
End of changes. 37 change blocks.
	79 lines changed or deleted		91 lines changed or added
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/