draft-ietf-httpbis-p2-semantics-09.txt		draft-ietf-httpbis-p2-semantics-latest.txt
	HTTPbis Working Group R. Fielding, Ed.		HTTPbis Working Group R. Fielding, Ed.
	Internet-Draft Day Software		Internet-Draft Day Software
	Obsoletes: 2616 (if approved) J. Gettys		Obsoletes: 2616 (if approved) J. Gettys
	Updates: 2817 (if approved) One Laptop per Child		Updates: 2817 (if approved) One Laptop per Child
	Intended status: Standards Track J. Mogul		Intended status: Standards Track J. Mogul
	Expires: September 9, 2010 HP		Expires: September 12, 2010 HP
	H. Frystyk		H. Frystyk
	Microsoft		Microsoft
	L. Masinter		L. Masinter
	Adobe Systems		Adobe Systems
	P. Leach		P. Leach
	Microsoft		Microsoft
	T. Berners-Lee		T. Berners-Lee
	W3C/MIT		W3C/MIT
	Y. Lafon, Ed.		Y. Lafon, Ed.
	W3C		W3C
	J. Reschke, Ed.		J. Reschke, Ed.
	greenbytes		greenbytes
	March 8, 2010		March 11, 2010
	HTTP/1.1, part 2: Message Semantics		HTTP/1.1, part 2: Message Semantics
	draft-ietf-httpbis-p2-semantics-09		draft-ietf-httpbis-p2-semantics-latest
	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
	information initiative since 1990. This document is Part 2 of the		information initiative since 1990. This document is Part 2 of the
	seven-part specification that defines the protocol referred to as		seven-part specification that defines the protocol referred to as
	"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines		"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines
	the semantics of HTTP messages as expressed by request methods,		the semantics of HTTP messages as expressed by request methods,
	skipping to change at page 1, line 46		skipping to change at page 1, line 46
	fields.		fields.
	Editorial Note (To be removed by RFC Editor)		Editorial Note (To be removed by RFC Editor)
	Discussion of this draft should take place on the HTTPBIS working		Discussion of this draft should take place on the HTTPBIS working
	group mailing list (ietf-http-wg@w3.org). The current issues list is		group mailing list (ietf-http-wg@w3.org). The current issues list is
	at <http://tools.ietf.org/wg/httpbis/trac/report/11> and related		at <http://tools.ietf.org/wg/httpbis/trac/report/11> and related
	documents (including fancy diffs) can be found at		documents (including fancy diffs) can be found at
	<http://tools.ietf.org/wg/httpbis/>.		<http://tools.ietf.org/wg/httpbis/>.
	The changes in this draft are summarized in Appendix C.10.		The changes in this draft are summarized in Appendix C.11.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 2, line 23		skipping to change at page 2, line 23
	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 September 9, 2010.		This Internet-Draft will expire on September 12, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2010 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 4, line 40		skipping to change at page 4, line 40
	8.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 31		8.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 31
	8.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 31		8.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 31
	9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 32		9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 32
	9.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . . . 32		9.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . . . 32
	9.2. Expect . . . . . . . . . . . . . . . . . . . . . . . . . . 32		9.2. Expect . . . . . . . . . . . . . . . . . . . . . . . . . . 32
	9.3. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 33		9.3. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
	9.4. Location . . . . . . . . . . . . . . . . . . . . . . . . . 34		9.4. Location . . . . . . . . . . . . . . . . . . . . . . . . . 34
	9.5. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . . 35		9.5. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . . 35
	9.6. Referer . . . . . . . . . . . . . . . . . . . . . . . . . 35		9.6. Referer . . . . . . . . . . . . . . . . . . . . . . . . . 35
	9.7. Retry-After . . . . . . . . . . . . . . . . . . . . . . . 36		9.7. Retry-After . . . . . . . . . . . . . . . . . . . . . . . 36
	9.8. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 36		9.8. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 37
	9.9. User-Agent . . . . . . . . . . . . . . . . . . . . . . . . 37		9.9. User-Agent . . . . . . . . . . . . . . . . . . . . . . . . 37
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
	10.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 37		10.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 38
	10.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 38		10.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 38
	10.3. Message Header Registration . . . . . . . . . . . . . . . 39		10.3. Message Header Registration . . . . . . . . . . . . . . . 39
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 40		11. Security Considerations . . . . . . . . . . . . . . . . . . . 40
	11.1. Transfer of Sensitive Information . . . . . . . . . . . . 40		11.1. Transfer of Sensitive Information . . . . . . . . . . . . 40
	11.2. Encoding Sensitive Information in URIs . . . . . . . . . . 41		11.2. Encoding Sensitive Information in URIs . . . . . . . . . . 41
	11.3. Location Headers and Spoofing . . . . . . . . . . . . . . 42		11.3. Location Headers and Spoofing . . . . . . . . . . . . . . 42
	12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 42		12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 42
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42		13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42
	13.1. Normative References . . . . . . . . . . . . . . . . . . . 42		13.1. Normative References . . . . . . . . . . . . . . . . . . . 42
	13.2. Informative References . . . . . . . . . . . . . . . . . . 43		13.2. Informative References . . . . . . . . . . . . . . . . . . 43
	Appendix A. Compatibility with Previous Versions . . . . . . . . 43		Appendix A. Compatibility with Previous Versions . . . . . . . . 43
	A.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 43		A.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 44
	A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 44		A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 45
	Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 45		Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 45
	Appendix C. Change Log (to be removed by RFC Editor before		Appendix C. Change Log (to be removed by RFC Editor before
	publication) . . . . . . . . . . . . . . . . . . . . 48		publication) . . . . . . . . . . . . . . . . . . . . 48
	C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 48		C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 48
	C.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 48		C.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 48
	C.3. Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . . 49		C.3. Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . . 49
	C.4. Since draft-ietf-httpbis-p2-semantics-02 . . . . . . . . . 49		C.4. Since draft-ietf-httpbis-p2-semantics-02 . . . . . . . . . 49
	C.5. Since draft-ietf-httpbis-p2-semantics-03 . . . . . . . . . 50		C.5. Since draft-ietf-httpbis-p2-semantics-03 . . . . . . . . . 50
	C.6. Since draft-ietf-httpbis-p2-semantics-04 . . . . . . . . . 50		C.6. Since draft-ietf-httpbis-p2-semantics-04 . . . . . . . . . 50
	C.7. Since draft-ietf-httpbis-p2-semantics-05 . . . . . . . . . 51		C.7. Since draft-ietf-httpbis-p2-semantics-05 . . . . . . . . . 51
	C.8. Since draft-ietf-httpbis-p2-semantics-06 . . . . . . . . . 51		C.8. Since draft-ietf-httpbis-p2-semantics-06 . . . . . . . . . 51
	C.9. Since draft-ietf-httpbis-p2-semantics-07 . . . . . . . . . 51		C.9. Since draft-ietf-httpbis-p2-semantics-07 . . . . . . . . . 51
	C.10. Since draft-ietf-httpbis-p2-semantics-08 . . . . . . . . . 52		C.10. Since draft-ietf-httpbis-p2-semantics-08 . . . . . . . . . 52
			C.11. Since draft-ietf-httpbis-p2-semantics-09 . . . . . . . . . 52
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52		Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 57
	1. Introduction		1. Introduction
	This document defines HTTP/1.1 request and response semantics. Each		This document defines HTTP/1.1 request and response semantics. Each
	HTTP message, as defined in [Part1], is in the form of either a		HTTP message, as defined in [Part1], is in the form of either a
	request or a response. An HTTP server listens on a connection for		request or a response. An HTTP server listens on a connection for
	HTTP requests and responds to each request, in the order received on		HTTP requests and responds to each request, in the order received on
	that connection, with one or more HTTP response messages. This		that connection, with one or more HTTP response messages. This
	document defines the commonly agreed upon semantics of the HTTP		document defines the commonly agreed upon semantics of the HTTP
	uniform interface, the intentions defined by each request method, and		uniform interface, the intentions defined by each request method, and
	skipping to change at page 7, line 28		skipping to change at page 7, line 28
	The ABNF rules below are defined in other parts:		The ABNF rules below are defined in other parts:
	absolute-URI = <absolute-URI, defined in [Part1], Section 2.6>		absolute-URI = <absolute-URI, defined in [Part1], Section 2.6>
	comment = <comment, defined in [Part1], Section 3.2>		comment = <comment, defined in [Part1], Section 3.2>
	Host = <Host, defined in [Part1], Section 2.6>		Host = <Host, defined in [Part1], Section 2.6>
	HTTP-date = <HTTP-date, defined in [Part1], Section 6.1>		HTTP-date = <HTTP-date, defined in [Part1], Section 6.1>
	partial-URI = <partial-URI, defined in [Part1], Section 2.6>		partial-URI = <partial-URI, defined in [Part1], Section 2.6>
	product = <product, defined in [Part1], Section 6.3>		product = <product, defined in [Part1], Section 6.3>
	TE = <TE, defined in [Part1], Section 9.8>		TE = <TE, defined in [Part1], Section 9.8>
	URI = <URI, defined in [Part1], Section 2.6>		URI-reference = <URI-reference, defined in [Part1], Section 2.6>
	Accept = <Accept, defined in [Part3], Section 5.1>		Accept = <Accept, defined in [Part3], Section 5.1>
	Accept-Charset =		Accept-Charset =
	<Accept-Charset, defined in [Part3], Section 5.2>		<Accept-Charset, defined in [Part3], Section 5.2>
	Accept-Encoding =		Accept-Encoding =
	<Accept-Encoding, defined in [Part3], Section 5.3>		<Accept-Encoding, defined in [Part3], Section 5.3>
	Accept-Language =		Accept-Language =
	<Accept-Language, defined in [Part3], Section 5.4>		<Accept-Language, defined in [Part3], Section 5.4>
	ETag = <ETag, defined in [Part4], Section 6.1>		ETag = <ETag, defined in [Part4], Section 6.1>
	skipping to change at page 34, line 30		skipping to change at page 34, line 30
	The "Location" response-header field is used to identify a newly		The "Location" response-header field is used to identify a newly
	created resource, or to redirect the recipient to a different		created resource, or to redirect the recipient to a different
	location for completion of the request.		location for completion of the request.
	For 201 (Created) responses, the Location is the URI of the new		For 201 (Created) responses, the Location is the URI of the new
	resource which was created by the request. For 3xx responses, the		resource which was created by the request. For 3xx responses, the
	location SHOULD indicate the server's preferred URI for automatic		location SHOULD indicate the server's preferred URI for automatic
	redirection to the resource.		redirection to the resource.
	The field value consists of a single URI.		The field value consists of a single URI-reference. When it has the
			form of a relative reference ([RFC3986], Section 4.2), the final
			value is computed by resolving it against the effective request URI
			([RFC3986], Section 5).
	Location = "Location" ":" OWS Location-v		Location = "Location" ":" OWS Location-v
	Location-v = URI		Location-v = URI-reference
	An example is:		Examples are:
	Location: http://www.example.org/pub/WWW/People.html		Location: http://www.example.org/pub/WWW/People.html#tim
			Location: /index.html
	There are circumstances in which a fragment identifier in a Location		There are circumstances in which a fragment identifier in a Location
	URI would not be appropriate:		URI would not be appropriate:
	o With a 201 Created response, because in this usage the Location		o With a 201 Created response, because in this usage the Location
	header specifies the URI for the entire created resource.		header specifies the URI for the entire created resource.
	o With 305 Use Proxy.		o With 305 Use Proxy.
			Note: This specification does not define precedence rules for the
			case where the original URI, as navigated to by the user agent,
			and the Location header field value both contain fragment
			identifiers.
	Note: The Content-Location header field (Section 5.7 of [Part3])		Note: The Content-Location header field (Section 5.7 of [Part3])
	differs from Location in that the Content-Location identifies the		differs from Location in that the Content-Location identifies the
	original location of the entity enclosed in the response. It is		original location of the entity enclosed in the response. It is
	therefore possible for a response to contain header fields for		therefore possible for a response to contain header fields for
	both Location and Content-Location.		both Location and Content-Location.
	9.5. Max-Forwards		9.5. Max-Forwards
	The "Max-Forwards" request-header field provides a mechanism with the		The "Max-Forwards" request-header field provides a mechanism with the
	TRACE (Section 7.8) and OPTIONS (Section 7.2) methods to limit the		TRACE (Section 7.8) and OPTIONS (Section 7.2) methods to limit the
	skipping to change at page 42, line 22		skipping to change at page 42, line 22
	12. Acknowledgments		12. Acknowledgments
	13. References		13. References
	13.1. Normative References		13.1. Normative References
	[Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
	and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,		and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,
	and Message Parsing", draft-ietf-httpbis-p1-messaging-09		and Message Parsing",
	(work in progress), March 2010.		draft-ietf-httpbis-p1-messaging-latest (work in progress),
			March 2010.
	[Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
	and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload		and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload
	and Content Negotiation", draft-ietf-httpbis-p3-payload-09		and Content Negotiation",
	(work in progress), March 2010.		draft-ietf-httpbis-p3-payload-latest (work in progress),
			March 2010.
	[Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
	and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional		and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional
	Requests", draft-ietf-httpbis-p4-conditional-09 (work in		Requests", draft-ietf-httpbis-p4-conditional-latest (work
	progress), March 2010.		in progress), March 2010.
	[Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
	and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and		and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and
	Partial Responses", draft-ietf-httpbis-p5-range-09 (work		Partial Responses", draft-ietf-httpbis-p5-range-latest
	in progress), March 2010.		(work in progress), March 2010.
	[Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
	Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part		Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part
	6: Caching", draft-ietf-httpbis-p6-cache-09 (work in		6: Caching", draft-ietf-httpbis-p6-cache-latest (work in
	progress), March 2010.		progress), March 2010.
	[Part7] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part7] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
	and J. Reschke, Ed., "HTTP/1.1, part 7: Authentication",		and J. Reschke, Ed., "HTTP/1.1, part 7: Authentication",
	draft-ietf-httpbis-p7-auth-09 (work in progress),		draft-ietf-httpbis-p7-auth-latest (work in progress),
	March 2010.		March 2010.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
			[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
			Resource Identifier (URI): Generic Syntax", RFC 3986,
			STD 66, January 2005.
	[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax		[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", STD 68, RFC 5234, January 2008.		Specifications: ABNF", STD 68, RFC 5234, January 2008.
	13.2. Informative References		13.2. Informative References
	[RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext		[RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext
	Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.		Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
	[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",
	skipping to change at page 45, line 20		skipping to change at page 45, line 28
	implement it. It used to indicate that the requested resource must		implement it. It used to indicate that the requested resource must
	be accessed through the proxy given by the Location field. The		be accessed through the proxy given by the Location field. The
	Location field gave the URI of the proxy. The recipient was expected		Location field gave the URI of the proxy. The recipient was expected
	to repeat this single request via the proxy. (Section 8.3.6)		to repeat this single request via the proxy. (Section 8.3.6)
	Reclassify Allow header as response header, removing the option to		Reclassify Allow header as response header, removing the option to
	specify it in a PUT request. Relax the server requirement on the		specify it in a PUT request. Relax the server requirement on the
	contents of the Allow header and remove requirement on clients to		contents of the Allow header and remove requirement on clients to
	always trust the header value. (Section 9.1)		always trust the header value. (Section 9.1)
	Correct syntax of Location header to allow fragment, as referred		Correct syntax of Location header to allow URI references (including
	symbol wasn't what was expected, and add some clarifications as to		relative references and fragments), as referred symbol "absoluteURI"
	when it would not be appropriate. (Section 9.4)		wasn't what was expected, and add some clarifications as to when use
			of fragments would not be appropriate. (Section 9.4)
	Allow Referer value of "about:blank" as alternative to not specifying		Allow Referer value of "about:blank" as alternative to not specifying
	it. (Section 9.6)		it. (Section 9.6)
	In the description of the Server header, the Via field was described		In the description of the Server header, the Via field was described
	as a SHOULD. The requirement was and is stated correctly in the		as a SHOULD. The requirement was and is stated correctly in the
	description of the Via header in Section 9.9 of [Part1].		description of the Via header in Section 9.9 of [Part1].
	(Section 9.8)		(Section 9.8)
	Appendix B. Collected ABNF		Appendix B. Collected ABNF
	skipping to change at page 46, line 16		skipping to change at page 46, line 23
	If-Match = <If-Match, defined in [Part4], Section 6.2>		If-Match = <If-Match, defined in [Part4], Section 6.2>
	If-Modified-Since =		If-Modified-Since =
	<If-Modified-Since, defined in [Part4], Section 6.3>		<If-Modified-Since, defined in [Part4], Section 6.3>
	If-None-Match = <If-None-Match, defined in [Part4], Section 6.4>		If-None-Match = <If-None-Match, defined in [Part4], Section 6.4>
	If-Range = <If-Range, defined in [Part5], Section 5.3>		If-Range = <If-Range, defined in [Part5], Section 5.3>
	If-Unmodified-Since =		If-Unmodified-Since =
	<If-Unmodified-Since, defined in [Part4], Section 6.5>		<If-Unmodified-Since, defined in [Part4], Section 6.5>
	Location = "Location:" OWS Location-v		Location = "Location:" OWS Location-v
	Location-v = URI		Location-v = URI-reference
	Max-Forwards = "Max-Forwards:" OWS Max-Forwards-v		Max-Forwards = "Max-Forwards:" OWS Max-Forwards-v
	Max-Forwards-v = 1*DIGIT		Max-Forwards-v = 1*DIGIT
	Method = %x4F.50.54.49.4F.4E.53 ; OPTIONS		Method = %x4F.50.54.49.4F.4E.53 ; OPTIONS
	/ %x47.45.54 ; GET		/ %x47.45.54 ; GET
	/ %x48.45.41.44 ; HEAD		/ %x48.45.41.44 ; HEAD
	/ %x50.4F.53.54 ; POST		/ %x50.4F.53.54 ; POST
	/ %x50.55.54 ; PUT		/ %x50.55.54 ; PUT
	/ %x44.45.4C.45.54.45 ; DELETE		/ %x44.45.4C.45.54.45 ; DELETE
	/ %x54.52.41.43.45 ; TRACE		/ %x54.52.41.43.45 ; TRACE
	skipping to change at page 47, line 13		skipping to change at page 47, line 15
	Server-v = product *( RWS ( product / comment ) )		Server-v = product *( RWS ( product / comment ) )
	Status-Code = "100" / "101" / "200" / "201" / "202" / "203" / "204" /		Status-Code = "100" / "101" / "200" / "201" / "202" / "203" / "204" /
	"205" / "206" / "300" / "301" / "302" / "303" / "304" / "305" /		"205" / "206" / "300" / "301" / "302" / "303" / "304" / "305" /
	"307" / "400" / "401" / "402" / "403" / "404" / "405" / "406" /		"307" / "400" / "401" / "402" / "403" / "404" / "405" / "406" /
	"407" / "408" / "409" / "410" / "411" / "412" / "413" / "414" /		"407" / "408" / "409" / "410" / "411" / "412" / "413" / "414" /
	"415" / "416" / "417" / "500" / "501" / "502" / "503" / "504" /		"415" / "416" / "417" / "500" / "501" / "502" / "503" / "504" /
	"505" / extension-code		"505" / extension-code
	TE = <TE, defined in [Part1], Section 9.8>		TE = <TE, defined in [Part1], Section 9.8>
	URI = <URI, defined in [Part1], Section 2.6>		URI-reference = <URI-reference, defined in [Part1], Section 2.6>
	User-Agent = "User-Agent:" OWS User-Agent-v		User-Agent = "User-Agent:" OWS User-Agent-v
	User-Agent-v = product *( RWS ( product / comment ) )		User-Agent-v = product *( RWS ( product / comment ) )
	Vary = <Vary, defined in [Part6], Section 3.5>		Vary = <Vary, defined in [Part6], Section 3.5>
	WWW-Authenticate =		WWW-Authenticate =
	<WWW-Authenticate, defined in [Part7], Section 3.4>		<WWW-Authenticate, defined in [Part7], Section 3.4>
	absolute-URI = <absolute-URI, defined in [Part1], Section 2.6>		absolute-URI = <absolute-URI, defined in [Part1], Section 2.6>
	skipping to change at page 52, line 27		skipping to change at page 52, line 33
	and TRACE safe?"		and TRACE safe?"
	C.10. Since draft-ietf-httpbis-p2-semantics-08		C.10. Since draft-ietf-httpbis-p2-semantics-08
	Closed issues:		Closed issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/10>: "Safe Methods		o <http://tools.ietf.org/wg/httpbis/trac/ticket/10>: "Safe Methods
	vs Redirection" (we missed the introduction to the 3xx status		vs Redirection" (we missed the introduction to the 3xx status
	codes when fixing this previously)		codes when fixing this previously)
			C.11. Since draft-ietf-httpbis-p2-semantics-09
			Closed issues:
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/43>: "Fragment
			combination / precedence during redirects"
			Partly resolved issues:
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/185>: "Location
			header payload handling"
	Index		Index
	1		1
	100 Continue (status code) 20		100 Continue (status code) 20
	101 Switching Protocols (status code) 20		101 Switching Protocols (status code) 20
	2		2
	200 OK (status code) 21		200 OK (status code) 21
	201 Created (status code) 21		201 Created (status code) 21
	202 Accepted (status code) 22		202 Accepted (status code) 22
	skipping to change at page 54, line 20		skipping to change at page 54, line 38
	extension-code 11		extension-code 11
	extension-method 8		extension-method 8
	From 33		From 33
	From-v 33		From-v 33
	Location 34		Location 34
	Location-v 34		Location-v 34
	Max-Forwards 35		Max-Forwards 35
	Max-Forwards-v 35		Max-Forwards-v 35
	Method 8		Method 8
	Reason-Phrase 11		Reason-Phrase 11
	Referer 35		Referer 36
	Referer-v 35		Referer-v 36
	request-header 9		request-header 9
	response-header 12		response-header 12
	Retry-After 36		Retry-After 36
	Retry-After-v 36		Retry-After-v 36
	Server 36		Server 37
	Server-v 36		Server-v 37
	Status-Code 11		Status-Code 11
	User-Agent 37		User-Agent 37
	User-Agent-v 37		User-Agent-v 37
	H		H
	HEAD method 16		HEAD method 16
	Headers		Headers
	Allow 32		Allow 32
	Expect 32		Expect 32
	From 33		From 33
	Location 34		Location 34
	Max-Forwards 35		Max-Forwards 35
	Referer 35		Referer 35
	Retry-After 36		Retry-After 36
	Server 36		Server 37
	User-Agent 37		User-Agent 37
	I		I
	Idempotent Methods 14		Idempotent Methods 14
	L		L
	LINK method 44		LINK method 44
	Location header 34		Location header 34
	M		M
	skipping to change at page 55, line 34		skipping to change at page 55, line 50
	PATCH method 44		PATCH method 44
	POST method 17		POST method 17
	PUT method 18		PUT method 18
	R		R
	Referer header 35		Referer header 35
	Retry-After header 36		Retry-After header 36
	S		S
	Safe Methods 14		Safe Methods 14
	Server header 36		Server header 37
	Status Codes		Status Codes
	100 Continue 20		100 Continue 20
	101 Switching Protocols 20		101 Switching Protocols 20
	200 OK 21		200 OK 21
	201 Created 21		201 Created 21
	202 Accepted 22		202 Accepted 22
	203 Non-Authoritative Information 22		203 Non-Authoritative Information 22
	204 No Content 22		204 No Content 22
	205 Reset Content 23		205 Reset Content 23
	206 Partial Content 23		206 Partial Content 23
End of changes. 31 change blocks.
	37 lines changed or deleted		67 lines changed or added
This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/