draft-ietf-httpbis-p2-semantics-24.txt		draft-ietf-httpbis-p2-semantics-25.txt
	HTTPbis Working Group R. Fielding, Ed.		HTTPbis Working Group R. Fielding, Ed.
	Internet-Draft Adobe		Internet-Draft Adobe
	Obsoletes: 2616 (if approved) J. Reschke, Ed.		Obsoletes: 2616 (if approved) J. Reschke, Ed.
	Updates: 2817 (if approved) greenbytes		Updates: 2817 (if approved) greenbytes
	Intended status: Standards Track September 25, 2013		Intended status: Standards Track November 17, 2013
	Expires: March 29, 2014		Expires: May 21, 2014
	Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content		Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
	draft-ietf-httpbis-p2-semantics-24		draft-ietf-httpbis-p2-semantics-25
	Abstract		Abstract
	The Hypertext Transfer Protocol (HTTP) is an application-level		The Hypertext Transfer Protocol (HTTP) is an application-level
	protocol for distributed, collaborative, hypertext information		protocol for distributed, collaborative, hypertext information
	systems. This document defines the semantics of HTTP/1.1 messages,		systems. This document defines the semantics of HTTP/1.1 messages,
	as expressed by request methods, request header fields, response		as expressed by request methods, request header fields, response
	status codes, and response header fields, along with the payload of		status codes, and response header fields, along with the payload of
	messages (metadata and body content) and mechanisms for content		messages (metadata and body content) and mechanisms for content
	negotiation.		negotiation.
	skipping to change at page 1, line 34		skipping to change at page 1, line 34
	Discussion of this draft takes place on the HTTPBIS working group		Discussion of this draft takes place on the HTTPBIS working group
	mailing list (ietf-http-wg@w3.org), which is archived at		mailing list (ietf-http-wg@w3.org), which is archived at
	<http://lists.w3.org/Archives/Public/ietf-http-wg/>.		<http://lists.w3.org/Archives/Public/ietf-http-wg/>.
	The current issues list is at		The current issues list is at
	<http://tools.ietf.org/wg/httpbis/trac/report/3> and related		<http://tools.ietf.org/wg/httpbis/trac/report/3> 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 E.4.		The changes in this draft are summarized in Appendix E.2.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted 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). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	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."
	This Internet-Draft will expire on March 29, 2014.		This Internet-Draft will expire on May 21, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 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 3, line 34		skipping to change at page 3, line 34
	5.3.2. Accept . . . . . . . . . . . . . . . . . . . . . . . . 38		5.3.2. Accept . . . . . . . . . . . . . . . . . . . . . . . . 38
	5.3.3. Accept-Charset . . . . . . . . . . . . . . . . . . . . 40		5.3.3. Accept-Charset . . . . . . . . . . . . . . . . . . . . 40
	5.3.4. Accept-Encoding . . . . . . . . . . . . . . . . . . . 41		5.3.4. Accept-Encoding . . . . . . . . . . . . . . . . . . . 41
	5.3.5. Accept-Language . . . . . . . . . . . . . . . . . . . 42		5.3.5. Accept-Language . . . . . . . . . . . . . . . . . . . 42
	5.4. Authentication Credentials . . . . . . . . . . . . . . . . 43		5.4. Authentication Credentials . . . . . . . . . . . . . . . . 43
	5.5. Request Context . . . . . . . . . . . . . . . . . . . . . 44		5.5. Request Context . . . . . . . . . . . . . . . . . . . . . 44
	5.5.1. From . . . . . . . . . . . . . . . . . . . . . . . . . 44		5.5.1. From . . . . . . . . . . . . . . . . . . . . . . . . . 44
	5.5.2. Referer . . . . . . . . . . . . . . . . . . . . . . . 45		5.5.2. Referer . . . . . . . . . . . . . . . . . . . . . . . 45
	5.5.3. User-Agent . . . . . . . . . . . . . . . . . . . . . . 46		5.5.3. User-Agent . . . . . . . . . . . . . . . . . . . . . . 46
	6. Response Status Codes . . . . . . . . . . . . . . . . . . . . 47		6. Response Status Codes . . . . . . . . . . . . . . . . . . . . 47
	6.1. Overview of Status Codes . . . . . . . . . . . . . . . . . 47		6.1. Overview of Status Codes . . . . . . . . . . . . . . . . . 48
	6.2. Informational 1xx . . . . . . . . . . . . . . . . . . . . 50		6.2. Informational 1xx . . . . . . . . . . . . . . . . . . . . 50
	6.2.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 50		6.2.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 50
	6.2.2. 101 Switching Protocols . . . . . . . . . . . . . . . 50		6.2.2. 101 Switching Protocols . . . . . . . . . . . . . . . 50
	6.3. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 51		6.3. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 51
	6.3.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 51		6.3.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 51
	6.3.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 52		6.3.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 52
	6.3.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 52		6.3.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 52
	6.3.4. 203 Non-Authoritative Information . . . . . . . . . . 52		6.3.4. 203 Non-Authoritative Information . . . . . . . . . . 52
	6.3.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 53		6.3.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 53
	6.3.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 53		6.3.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 53
	6.4. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 54		6.4. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 54
	6.4.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 55		6.4.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 55
	6.4.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 56		6.4.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 56
	6.4.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 56		6.4.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 56
	6.4.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 57		6.4.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 57
	6.4.5. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 57		6.4.5. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 57
	6.4.6. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 57		6.4.6. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 58
	6.4.7. 307 Temporary Redirect . . . . . . . . . . . . . . . . 58		6.4.7. 307 Temporary Redirect . . . . . . . . . . . . . . . . 58
	6.5. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 58		6.5. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 58
	6.5.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 58		6.5.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 58
	6.5.2. 402 Payment Required . . . . . . . . . . . . . . . . . 58		6.5.2. 402 Payment Required . . . . . . . . . . . . . . . . . 58
	6.5.3. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 58		6.5.3. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 59
	6.5.4. 404 Not Found . . . . . . . . . . . . . . . . . . . . 59		6.5.4. 404 Not Found . . . . . . . . . . . . . . . . . . . . 59
	6.5.5. 405 Method Not Allowed . . . . . . . . . . . . . . . . 59		6.5.5. 405 Method Not Allowed . . . . . . . . . . . . . . . . 59
	6.5.6. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 59		6.5.6. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 59
	6.5.7. 408 Request Timeout . . . . . . . . . . . . . . . . . 60		6.5.7. 408 Request Timeout . . . . . . . . . . . . . . . . . 60
	6.5.8. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 60		6.5.8. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 60
	6.5.9. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 60		6.5.9. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 60
	6.5.10. 411 Length Required . . . . . . . . . . . . . . . . . 61		6.5.10. 411 Length Required . . . . . . . . . . . . . . . . . 61
	6.5.11. 413 Payload Too Large . . . . . . . . . . . . . . . . 61		6.5.11. 413 Payload Too Large . . . . . . . . . . . . . . . . 61
	6.5.12. 414 URI Too Long . . . . . . . . . . . . . . . . . . . 61		6.5.12. 414 URI Too Long . . . . . . . . . . . . . . . . . . . 61
	6.5.13. 415 Unsupported Media Type . . . . . . . . . . . . . . 61		6.5.13. 415 Unsupported Media Type . . . . . . . . . . . . . . 62
	6.5.14. 417 Expectation Failed . . . . . . . . . . . . . . . . 62		6.5.14. 417 Expectation Failed . . . . . . . . . . . . . . . . 62
	6.5.15. 426 Upgrade Required . . . . . . . . . . . . . . . . . 62		6.5.15. 426 Upgrade Required . . . . . . . . . . . . . . . . . 62
	6.6. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 62		6.6. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 62
	6.6.1. 500 Internal Server Error . . . . . . . . . . . . . . 62		6.6.1. 500 Internal Server Error . . . . . . . . . . . . . . 63
	6.6.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 62		6.6.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 63
	6.6.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 63		6.6.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 63
	6.6.4. 503 Service Unavailable . . . . . . . . . . . . . . . 63		6.6.4. 503 Service Unavailable . . . . . . . . . . . . . . . 63
	6.6.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 63		6.6.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 63
	6.6.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 63		6.6.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 63
	7. Response Header Fields . . . . . . . . . . . . . . . . . . . . 63		7. Response Header Fields . . . . . . . . . . . . . . . . . . . . 64
	7.1. Control Data . . . . . . . . . . . . . . . . . . . . . . . 64		7.1. Control Data . . . . . . . . . . . . . . . . . . . . . . . 64
	7.1.1. Origination Date . . . . . . . . . . . . . . . . . . . 64		7.1.1. Origination Date . . . . . . . . . . . . . . . . . . . 64
	7.1.2. Location . . . . . . . . . . . . . . . . . . . . . . . 68		7.1.2. Location . . . . . . . . . . . . . . . . . . . . . . . 68
	7.1.3. Retry-After . . . . . . . . . . . . . . . . . . . . . 69		7.1.3. Retry-After . . . . . . . . . . . . . . . . . . . . . 69
	7.1.4. Vary . . . . . . . . . . . . . . . . . . . . . . . . . 70		7.1.4. Vary . . . . . . . . . . . . . . . . . . . . . . . . . 70
	7.2. Validator Header Fields . . . . . . . . . . . . . . . . . 71		7.2. Validator Header Fields . . . . . . . . . . . . . . . . . 71
	7.3. Authentication Challenges . . . . . . . . . . . . . . . . 72		7.3. Authentication Challenges . . . . . . . . . . . . . . . . 72
	7.4. Response Context . . . . . . . . . . . . . . . . . . . . . 72		7.4. Response Context . . . . . . . . . . . . . . . . . . . . . 72
	7.4.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . 72		7.4.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . 72
	7.4.2. Server . . . . . . . . . . . . . . . . . . . . . . . . 73		7.4.2. Server . . . . . . . . . . . . . . . . . . . . . . . . 73
	skipping to change at page 5, line 10		skipping to change at page 5, line 10
	8.3. Header Field Registry . . . . . . . . . . . . . . . . . . 77		8.3. Header Field Registry . . . . . . . . . . . . . . . . . . 77
	8.3.1. Considerations for New Header Fields . . . . . . . . . 78		8.3.1. Considerations for New Header Fields . . . . . . . . . 78
	8.3.2. Registrations . . . . . . . . . . . . . . . . . . . . 80		8.3.2. Registrations . . . . . . . . . . . . . . . . . . . . 80
	8.4. Content Coding Registry . . . . . . . . . . . . . . . . . 80		8.4. Content Coding Registry . . . . . . . . . . . . . . . . . 80
	8.4.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 80		8.4.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 80
	8.4.2. Registrations . . . . . . . . . . . . . . . . . . . . 81		8.4.2. Registrations . . . . . . . . . . . . . . . . . . . . 81
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 81		9. Security Considerations . . . . . . . . . . . . . . . . . . . 81
	9.1. Attacks Based On File and Path Names . . . . . . . . . . . 81		9.1. Attacks Based On File and Path Names . . . . . . . . . . . 81
	9.2. Personal Information . . . . . . . . . . . . . . . . . . . 82		9.2. Personal Information . . . . . . . . . . . . . . . . . . . 82
	9.3. Sensitive Information in URIs . . . . . . . . . . . . . . 82		9.3. Sensitive Information in URIs . . . . . . . . . . . . . . 82
	9.4. Product Information . . . . . . . . . . . . . . . . . . . 83		9.4. Product Information . . . . . . . . . . . . . . . . . . . 82
	9.5. Fragment after Redirects . . . . . . . . . . . . . . . . . 83		9.5. Fragment after Redirects . . . . . . . . . . . . . . . . . 83
	9.6. Browser Fingerprinting . . . . . . . . . . . . . . . . . . 83		9.6. Browser Fingerprinting . . . . . . . . . . . . . . . . . . 83
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 84		10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 84
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 84		11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 84
	11.1. Normative References . . . . . . . . . . . . . . . . . . . 84		11.1. Normative References . . . . . . . . . . . . . . . . . . . 84
	11.2. Informative References . . . . . . . . . . . . . . . . . . 86		11.2. Informative References . . . . . . . . . . . . . . . . . . 85
	Appendix A. Differences between HTTP and MIME . . . . . . . . . . 88		Appendix A. Differences between HTTP and MIME . . . . . . . . . . 87
	A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 88		A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 88
	A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 88		A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 88
	A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 89		A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 88
	A.4. Conversion of Content-Encoding . . . . . . . . . . . . . . 89		A.4. Conversion of Content-Encoding . . . . . . . . . . . . . . 88
	A.5. Conversion of Content-Transfer-Encoding . . . . . . . . . 89		A.5. Conversion of Content-Transfer-Encoding . . . . . . . . . 89
	A.6. MHTML and Line Length Limitations . . . . . . . . . . . . 89		A.6. MHTML and Line Length Limitations . . . . . . . . . . . . 89
	Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 90		Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 89
	Appendix C. Imported ABNF . . . . . . . . . . . . . . . . . . . . 92		Appendix C. Imported ABNF . . . . . . . . . . . . . . . . . . . . 92
	Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 93		Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 92
	Appendix E. Change Log (to be removed by RFC Editor before		Appendix E. Change Log (to be removed by RFC Editor before
	publication) . . . . . . . . . . . . . . . . . . . . 96		publication) . . . . . . . . . . . . . . . . . . . . 95
	E.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 96		E.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 95
	E.2. Since draft-ietf-httpbis-p2-semantics-21 . . . . . . . . . 96		E.2. Since draft-ietf-httpbis-p2-semantics-24 . . . . . . . . . 95
	E.3. Since draft-ietf-httpbis-p2-semantics-22 . . . . . . . . . 97		Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
	E.4. Since draft-ietf-httpbis-p2-semantics-23 . . . . . . . . . 97
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
	1. Introduction		1. Introduction
	Each Hypertext Transfer Protocol (HTTP) message is either a request		Each Hypertext Transfer Protocol (HTTP) message is either a request
	or a response. A server listens on a connection for a request,		or a response. A server listens on a connection for a request,
	parses each message received, interprets the message semantics in		parses each message received, interprets the message semantics in
	relation to the identified request target, and responds to that		relation to the identified request target, and responds to that
	request with one or more response messages. A client constructs		request with one or more response messages. A client constructs
	request messages to communicate specific intentions, and examines		request messages to communicate specific intentions, and examines
	received responses to see if the intentions were carried out and		received responses to see if the intentions were carried out and
	skipping to change at page 23, line 48		skipping to change at page 23, line 48
	query parameters, such as "page?do=delete". If the purpose of such a		query parameters, such as "page?do=delete". If the purpose of such a
	resource is to perform an unsafe action, then the resource owner MUST		resource is to perform an unsafe action, then the resource owner MUST
	disable or disallow that action when it is accessed using a safe		disable or disallow that action when it is accessed using a safe
	request method. Failure to do so will result in unfortunate side-		request method. Failure to do so will result in unfortunate side-
	effects when automated processes perform a GET on every URI reference		effects when automated processes perform a GET on every URI reference
	for the sake of link maintenance, pre-fetching, building a search		for the sake of link maintenance, pre-fetching, building a search
	index, etc.		index, etc.
	4.2.2. Idempotent Methods		4.2.2. Idempotent Methods
	Request methods are considered "idempotent" if the intended effect of		A request method is considered "idempotent" if the intended effect on
	multiple identical requests is the same as for a single request. Of		the server of multiple identical requests with that method is the
	the request methods defined by this specification, the PUT, DELETE,		same as the effect for a single such request. Of the request methods
	and safe request methods are idempotent.		defined by this specification, PUT, DELETE, and safe request methods
			are idempotent.
	Like the definition of safe, the idempotent property only applies to		Like the definition of safe, the idempotent property only applies to
	what has been requested by the user; a server is free to log each		what has been requested by the user; a server is free to log each
	request separately, retain a revision control history, or implement		request separately, retain a revision control history, or implement
	other non-idempotent side-effects for each idempotent request.		other non-idempotent side-effects for each idempotent request.
	Idempotent methods are distinguished because the request can be		Idempotent methods are distinguished because the request can be
	repeated automatically if a communication failure occurs before the		repeated automatically if a communication failure occurs before the
	client is able to read the server's response. For example, if a		client is able to read the server's response. For example, if a
	client sends a PUT request and the underlying connection is closed		client sends a PUT request and the underlying connection is closed
	before any response is received, then it can establish a new		before any response is received, then the client can establish a new
	connection and retry the idempotent request because it knows that		connection and retry the idempotent request because it knows that
	repeating the request will have the same effect even if the original		repeating the request will have the same effect (even if the original
	request succeeded. Note, however, that repeated failures would		request succeeded, though the status codes might differ in response).
	indicate a problem within the server.		Note, however, that repeated communication failures might indicate
			that the server has failed in general, or that something in the
			request is triggering a connection drop.
	4.2.3. Cacheable Methods		4.2.3. Cacheable Methods
	Request methods can be defined as "cacheable" to indicate that		Request methods can be defined as "cacheable" to indicate that
	responses to them are allowed to be stored for future reuse; for		responses to them are allowed to be stored for future reuse; for
	specific requirements see [Part6]. In general, safe methods that do		specific requirements see [Part6]. In general, safe methods that do
	not depend on a current or authoritative response are defined as		not depend on a current or authoritative response are defined as
	cacheable; this specification defines GET, HEAD and POST as		cacheable; this specification defines GET, HEAD and POST as
	cacheable, although the overwhelming majority of cache		cacheable, although the overwhelming majority of cache
	implementations only support GET and HEAD.		implementations only support GET and HEAD.
	skipping to change at page 45, line 17		skipping to change at page 45, line 17
	The "Referer" [sic] header field allows the user agent to specify a		The "Referer" [sic] header field allows the user agent to specify a
	URI reference for the resource from which the target URI was obtained		URI reference for the resource from which the target URI was obtained
	(i.e., the "referrer", though the field name is misspelled). A user		(i.e., the "referrer", though the field name is misspelled). A user
	agent MUST NOT include the fragment and userinfo components of the		agent MUST NOT include the fragment and userinfo components of the
	URI reference [RFC3986], if any, when generating the Referer field		URI reference [RFC3986], if any, when generating the Referer field
	value.		value.
	Referer = absolute-URI / partial-URI		Referer = absolute-URI / partial-URI
	Referer allows servers to generate back-links to other resources for		The Referer header field allows servers to generate back-links to
	simple analytics, logging, optimized caching, etc. It also allows		other resources for simple analytics, logging, optimized caching,
	obsolete or mistyped links to be found for maintenance. Some servers		etc. It also allows obsolete or mistyped links to be found for
	use Referer as a means of denying links from other sites (so-called		maintenance. Some servers use the Referer header field as a means of
	"deep linking") or restricting cross-site request forgery (CSRF), but		denying links from other sites (so-called "deep linking") or
	not all requests contain a Referer header field.		restricting cross-site request forgery (CSRF), but not all requests
			contain it.
	Example:		Example:
	Referer: http://www.example.org/hypertext/Overview.html		Referer: http://www.example.org/hypertext/Overview.html
	If the target URI was obtained from a source that does not have its		If the target URI was obtained from a source that does not have its
	own URI (e.g., input from the user keyboard, or an entry within the		own URI (e.g., input from the user keyboard, or an entry within the
	user's bookmarks/favorites), the user agent MUST either exclude		user's bookmarks/favorites), the user agent MUST either exclude
	Referer or send it with a value of "about:blank".		Referer or send it with a value of "about:blank".
	skipping to change at page 48, line 7		skipping to change at page 48, line 13
	valid request		valid request
	6.1. Overview of Status Codes		6.1. Overview of Status Codes
	The status codes listed below are defined in this specification,		The status codes listed below are defined in this specification,
	Section 4 of [Part4], Section 4 of [Part5], and Section 3 of [Part7].		Section 4 of [Part4], Section 4 of [Part5], and Section 3 of [Part7].
	The reason phrases listed here are only recommendations -- they can		The reason phrases listed here are only recommendations -- they can
	be replaced by local equivalents without affecting the protocol.		be replaced by local equivalents without affecting the protocol.
	Responses with status codes that are defined as cacheable by default		Responses with status codes that are defined as cacheable by default
	(e.g., 200, 203, 206, 300, 301, and 410 in this specification) can be		(e.g., 200, 203, 204, 206, 300, 301, 404, 405, 410, 414, 501 in this
	reused by a cache with heuristic expiration unless otherwise		specification) can be reused by a cache with heuristic expiration
	indicated by the method definition or explicit cache controls		unless otherwise indicated by the method definition or explicit cache
	[Part6]; all other status codes are not cacheable by default.		controls [Part6]; all other status codes are not cacheable by
			default.
	+------+-------------------------------+------------------------+		+------+-------------------------------+------------------------+
	| code | reason-phrase | Defined in... |		| code | reason-phrase | Defined in... |
	+------+-------------------------------+------------------------+		+------+-------------------------------+------------------------+
	| 100 | Continue | Section 6.2.1 |		| 100 | Continue | Section 6.2.1 |
	| 101 | Switching Protocols | Section 6.2.2 |		| 101 | Switching Protocols | Section 6.2.2 |
	| 200 | OK | Section 6.3.1 |		| 200 | OK | Section 6.3.1 |
	| 201 | Created | Section 6.3.2 |		| 201 | Created | Section 6.3.2 |
	| 202 | Accepted | Section 6.3.3 |		| 202 | Accepted | Section 6.3.3 |
	| 203 | Non-Authoritative Information | Section 6.3.4 |		| 203 | Non-Authoritative Information | Section 6.3.4 |
	skipping to change at page 51, line 47		skipping to change at page 51, line 47
	TRACE a representation of the request message as received by the end		TRACE a representation of the request message as received by the end
	server.		server.
	Aside from responses to CONNECT, a 200 response always has a payload,		Aside from responses to CONNECT, a 200 response always has a payload,
	though an origin server MAY generate a payload body of zero length.		though an origin server MAY generate a payload body of zero length.
	If no payload is desired, an origin server ought to send 204 (No		If no payload is desired, an origin server ought to send 204 (No
	Content) instead. For CONNECT, no payload is allowed because the		Content) instead. For CONNECT, no payload is allowed because the
	successful result is a tunnel, which begins immediately after the 200		successful result is a tunnel, which begins immediately after the 200
	response header section.		response header section.
	A 200 response is cacheable unless otherwise indicated by the method		A 200 response is cacheable by default; i.e., unless otherwise
	definition or explicit cache controls (see Section 4.2.2 of [Part6]).		indicated by the method definition or explicit cache controls (see
			Section 4.2.2 of [Part6]).
	6.3.2. 201 Created		6.3.2. 201 Created
	The 201 (Created) status code indicates that the request has been		The 201 (Created) status code indicates that the request has been
	fulfilled and has resulted in one or more new resources being		fulfilled and has resulted in one or more new resources being
	created. The primary resource created by the request is identified		created. The primary resource created by the request is identified
	by either a Location header field in the response or, if no Location		by either a Location header field in the response or, if no Location
	field is received, by the effective request URI.		field is received, by the effective request URI.
	The 201 response payload typically describes and links to the		The 201 response payload typically describes and links to the
	skipping to change at page 52, line 52		skipping to change at page 52, line 52
	to notify recipients when a transformation has been applied, since		to notify recipients when a transformation has been applied, since
	that knowledge might impact later decisions regarding the content.		that knowledge might impact later decisions regarding the content.
	For example, future cache validation requests for the content might		For example, future cache validation requests for the content might
	only be applicable along the same request path (through the same		only be applicable along the same request path (through the same
	proxies).		proxies).
	The 203 response is similar to the Warning code of 214 Transformation		The 203 response is similar to the Warning code of 214 Transformation
	Applied (Section 5.5 of [Part6]), which has the advantage of being		Applied (Section 5.5 of [Part6]), which has the advantage of being
	applicable to responses with any status code.		applicable to responses with any status code.
	A 203 response is cacheable unless otherwise indicated by the method		A 203 response is cacheable by default; i.e., unless otherwise
	definition or explicit cache controls (see Section 4.2.2 of [Part6]).		indicated by the method definition or explicit cache controls (see
			Section 4.2.2 of [Part6]).
	6.3.5. 204 No Content		6.3.5. 204 No Content
	The 204 (No Content) status code indicates that the server has		The 204 (No Content) status code indicates that the server has
	successfully fulfilled the request and that there is no additional		successfully fulfilled the request and that there is no additional
	content to send in the response payload body. Metadata in the		content to send in the response payload body. Metadata in the
	response header fields refer to the target resource and its selected		response header fields refer to the target resource and its selected
	representation after the requested action was applied.		representation after the requested action was applied.
	For example, if a 204 status code is received in response to a PUT		For example, if a 204 status code is received in response to a PUT
	skipping to change at page 53, line 36		skipping to change at page 53, line 37
	For example, a 204 status code is commonly used with document editing		For example, a 204 status code is commonly used with document editing
	interfaces corresponding to a "save" action, such that the document		interfaces corresponding to a "save" action, such that the document
	being saved remains available to the user for editing. It is also		being saved remains available to the user for editing. It is also
	frequently used with interfaces that expect automated data transfers		frequently used with interfaces that expect automated data transfers
	to be prevalent, such as within distributed version control systems.		to be prevalent, such as within distributed version control systems.
	A 204 response is terminated by the first empty line after the header		A 204 response is terminated by the first empty line after the header
	fields because it cannot contain a message body.		fields because it cannot contain a message body.
	A 204 response is cacheable unless otherwise indicated by the method		A 204 response is cacheable by default; i.e., unless otherwise
	definition or explicit cache controls (see Section 4.2.2 of [Part6]).		indicated by the method definition or explicit cache controls (see
			Section 4.2.2 of [Part6]).
	6.3.6. 205 Reset Content		6.3.6. 205 Reset Content
	The 205 (Reset Content) status code indicates that the server has		The 205 (Reset Content) status code indicates that the server has
	fulfilled the request and desires that the user agent reset the		fulfilled the request and desires that the user agent reset the
	"document view", which caused the request to be sent, to its original		"document view", which caused the request to be sent, to its original
	state as received from the origin server.		state as received from the origin server.
	This response is intended to support a common data entry use case		This response is intended to support a common data entry use case
	where the user receives content that supports data entry (a form,		where the user receives content that supports data entry (a form,
	skipping to change at page 55, line 43		skipping to change at page 55, line 46
	redirection.		redirection.
	For request methods other than HEAD, the server SHOULD generate a		For request methods other than HEAD, the server SHOULD generate a
	payload in the 300 response containing a list of representation		payload in the 300 response containing a list of representation
	metadata and URI reference(s) from which the user or user agent can		metadata and URI reference(s) from which the user or user agent can
	choose the one most preferred. The user agent MAY make a selection		choose the one most preferred. The user agent MAY make a selection
	from that list automatically, depending upon the list format, but		from that list automatically, depending upon the list format, but
	this specification does not define a standard for such automatic		this specification does not define a standard for such automatic
	selection.		selection.
	A 300 response is cacheable unless otherwise indicated by the method		A 300 response is cacheable by default; i.e., unless otherwise
	definition or explicit cache controls (see Section 4.2.2 of [Part6]).		indicated by the method definition or explicit cache controls (see
			Section 4.2.2 of [Part6]).
	Note: The original proposal for 300 defined the URI header field		Note: The original proposal for 300 defined the URI header field
	as providing a list of alternative representations, such that it		as providing a list of alternative representations, such that it
	would be usable for 200, 300, and 406 responses and be transferred		would be usable for 200, 300, and 406 responses and be transferred
	in responses to the HEAD method. However, lack of deployment and		in responses to the HEAD method. However, lack of deployment and
	disagreement over syntax led to both URI and Alternates (a		disagreement over syntax led to both URI and Alternates (a
	subsequent proposal) being dropped from this specification. It is		subsequent proposal) being dropped from this specification. It is
	possible to communicate the list using a set of Link header fields		possible to communicate the list using a set of Link header fields
	[RFC5988], each with a relationship of "alternate", though		[RFC5988], each with a relationship of "alternate", though
	deployment is a chicken-and-egg problem.		deployment is a chicken-and-egg problem.
	skipping to change at page 56, line 28		skipping to change at page 56, line 35
	containing a preferred URI reference for the new permanent URI. The		containing a preferred URI reference for the new permanent URI. The
	user agent MAY use the Location field value for automatic		user agent MAY use the Location field value for automatic
	redirection. The server's response payload usually contains a short		redirection. The server's response payload usually contains a short
	hypertext note with a hyperlink to the new URI(s).		hypertext note with a hyperlink to the new URI(s).
	Note: For historic reasons, a user agent MAY change the request		Note: For historic reasons, a user agent MAY change the request
	method from POST to GET for the subsequent request. If this		method from POST to GET for the subsequent request. If this
	behavior is undesired, the 307 (Temporary Redirect) status code		behavior is undesired, the 307 (Temporary Redirect) status code
	can be used instead.		can be used instead.
	A 301 response is cacheable unless otherwise indicated by the method		A 301 response is cacheable by default; i.e., unless otherwise
	definition or explicit cache controls (see Section 4.2.2 of [Part6]).		indicated by the method definition or explicit cache controls (see
			Section 4.2.2 of [Part6]).
	6.4.3. 302 Found		6.4.3. 302 Found
	The 302 (Found) status code indicates that the target resource		The 302 (Found) status code indicates that the target resource
	resides temporarily under a different URI. Since the redirection		resides temporarily under a different URI. Since the redirection
	might be altered on occasion, the client ought to continue to use the		might be altered on occasion, the client ought to continue to use the
	effective request URI for future requests.		effective request URI for future requests.
	The server SHOULD generate a Location header field in the response		The server SHOULD generate a Location header field in the response
	containing a URI reference for the different URI. The user agent MAY		containing a URI reference for the different URI. The user agent MAY
	skipping to change at page 59, line 26		skipping to change at page 59, line 33
	6.5.4. 404 Not Found		6.5.4. 404 Not Found
	The 404 (Not Found) status code indicates that the origin server did		The 404 (Not Found) status code indicates that the origin server did
	not find a current representation for the target resource or is not		not find a current representation for the target resource or is not
	willing to disclose that one exists. A 404 status code does not		willing to disclose that one exists. A 404 status code does not
	indicate whether this lack of representation is temporary or		indicate whether this lack of representation is temporary or
	permanent; the 410 (Gone) status code is preferred over 404 if the		permanent; the 410 (Gone) status code is preferred over 404 if the
	origin server knows, presumably through some configurable means, that		origin server knows, presumably through some configurable means, that
	the condition is likely to be permanent.		the condition is likely to be permanent.
	A 404 response is cacheable unless otherwise indicated by the method		A 404 response is cacheable by default; i.e., unless otherwise
	definition or explicit cache controls (see Section 4.2.2 of [Part6]).		indicated by the method definition or explicit cache controls (see
			Section 4.2.2 of [Part6]).
	6.5.5. 405 Method Not Allowed		6.5.5. 405 Method Not Allowed
	The 405 (Method Not Allowed) status code indicates that the method		The 405 (Method Not Allowed) status code indicates that the method
	received in the request-line is known by the origin server but not		received in the request-line is known by the origin server but not
	supported by the target resource. The origin server MUST generate an		supported by the target resource. The origin server MUST generate an
	Allow header field in a 405 response containing a list of the target		Allow header field in a 405 response containing a list of the target
	resource's currently supported methods.		resource's currently supported methods.
	A 405 response is cacheable unless otherwise indicated by the method		A 405 response is cacheable by default; i.e., unless otherwise
	definition or explicit cache controls (see Section 4.2.2 of [Part6]).		indicated by the method definition or explicit cache controls (see
			Section 4.2.2 of [Part6]).
	6.5.6. 406 Not Acceptable		6.5.6. 406 Not Acceptable
	The 406 (Not Acceptable) status code indicates that the target		The 406 (Not Acceptable) status code indicates that the target
	resource does not have a current representation that would be		resource does not have a current representation that would be
	acceptable to the user agent, according to the proactive negotiation		acceptable to the user agent, according to the proactive negotiation
	header fields received in the request (Section 5.3), and the server		header fields received in the request (Section 5.3), and the server
	is unwilling to supply a default representation.		is unwilling to supply a default representation.
	The server SHOULD generate a payload containing a list of available		The server SHOULD generate a payload containing a list of available
	skipping to change at page 61, line 5		skipping to change at page 61, line 15
	The 410 response is primarily intended to assist the task of web		The 410 response is primarily intended to assist the task of web
	maintenance by notifying the recipient that the resource is		maintenance by notifying the recipient that the resource is
	intentionally unavailable and that the server owners desire that		intentionally unavailable and that the server owners desire that
	remote links to that resource be removed. Such an event is common		remote links to that resource be removed. Such an event is common
	for limited-time, promotional services and for resources belonging to		for limited-time, promotional services and for resources belonging to
	individuals no longer associated with the origin server's site. It		individuals no longer associated with the origin server's site. It
	is not necessary to mark all permanently unavailable resources as		is not necessary to mark all permanently unavailable resources as
	"gone" or to keep the mark for any length of time -- that is left to		"gone" or to keep the mark for any length of time -- that is left to
	the discretion of the server owner.		the discretion of the server owner.
	A 410 response is cacheable unless otherwise indicated by the method		A 410 response is cacheable by default; i.e., unless otherwise
	definition or explicit cache controls (see Section 4.2.2 of [Part6]).		indicated by the method definition or explicit cache controls (see
			Section 4.2.2 of [Part6]).
	6.5.10. 411 Length Required		6.5.10. 411 Length Required
	The 411 (Length Required) status code indicates that the server		The 411 (Length Required) status code indicates that the server
	refuses to accept the request without a defined Content-Length		refuses to accept the request without a defined Content-Length
	(Section 3.3.2 of [Part1]). The client MAY repeat the request if it		(Section 3.3.2 of [Part1]). The client MAY repeat the request if it
	adds a valid Content-Length header field containing the length of the		adds a valid Content-Length header field containing the length of the
	message body in the request message.		message body in the request message.
	6.5.11. 413 Payload Too Large		6.5.11. 413 Payload Too Large
	skipping to change at page 61, line 39		skipping to change at page 61, line 50
	The 414 (URI Too Long) status code indicates that the server is		The 414 (URI Too Long) status code indicates that the server is
	refusing to service the request because the request-target (Section		refusing to service the request because the request-target (Section
	5.3 of [Part1]) is longer than the server is willing to interpret.		5.3 of [Part1]) is longer than the server is willing to interpret.
	This rare condition is only likely to occur when a client has		This rare condition is only likely to occur when a client has
	improperly converted a POST request to a GET request with long query		improperly converted a POST request to a GET request with long query
	information, when the client has descended into a "black hole" of		information, when the client has descended into a "black hole" of
	redirection (e.g., a redirected URI prefix that points to a suffix of		redirection (e.g., a redirected URI prefix that points to a suffix of
	itself), or when the server is under attack by a client attempting to		itself), or when the server is under attack by a client attempting to
	exploit potential security holes.		exploit potential security holes.
	A 414 response is cacheable unless otherwise indicated by the method		A 414 response is cacheable by default; i.e., unless otherwise
	definition or explicit cache controls (see Section 4.2.2 of [Part6]).		indicated by the method definition or explicit cache controls (see
			Section 4.2.2 of [Part6]).
	6.5.13. 415 Unsupported Media Type		6.5.13. 415 Unsupported Media Type
	The 415 (Unsupported Media Type) status code indicates that the		The 415 (Unsupported Media Type) status code indicates that the
	origin server is refusing to service the request because the payload		origin server is refusing to service the request because the payload
	is in a format not supported by this method on the target resource.		is in a format not supported by this method on the target resource.
	The format problem might be due to the request's indicated Content-		The format problem might be due to the request's indicated Content-
	Type or Content-Encoding, or as a result of inspecting the data		Type or Content-Encoding, or as a result of inspecting the data
	directly.		directly.
	skipping to change at page 63, line 6		skipping to change at page 63, line 18
	encountered an unexpected condition that prevented it from fulfilling		encountered an unexpected condition that prevented it from fulfilling
	the request.		the request.
	6.6.2. 501 Not Implemented		6.6.2. 501 Not Implemented
	The 501 (Not Implemented) status code indicates that the server does		The 501 (Not Implemented) status code indicates that the server does
	not support the functionality required to fulfill the request. This		not support the functionality required to fulfill the request. This
	is the appropriate response when the server does not recognize the		is the appropriate response when the server does not recognize the
	request method and is not capable of supporting it for any resource.		request method and is not capable of supporting it for any resource.
	A 501 response is cacheable unless otherwise indicated by the method		A 501 response is cacheable by default; i.e., unless otherwise
	definition or explicit cache controls (see Section 4.2.2 of [Part6]).		indicated by the method definition or explicit cache controls (see
			Section 4.2.2 of [Part6]).
	6.6.3. 502 Bad Gateway		6.6.3. 502 Bad Gateway
	The 502 (Bad Gateway) status code indicates that the server, while		The 502 (Bad Gateway) status code indicates that the server, while
	acting as a gateway or proxy, received an invalid response from an		acting as a gateway or proxy, received an invalid response from an
	inbound server it accessed while attempting to fulfill the request.		inbound server it accessed while attempting to fulfill the request.
	6.6.4. 503 Service Unavailable		6.6.4. 503 Service Unavailable
	The 503 (Service Unavailable) status code indicates that the server		The 503 (Service Unavailable) status code indicates that the server
	skipping to change at page 65, line 13		skipping to change at page 65, line 25
	MUST accept all three HTTP-date formats. When a sender generates a		MUST accept all three HTTP-date formats. When a sender generates a
	header field that contains one or more timestamps defined as HTTP-		header field that contains one or more timestamps defined as HTTP-
	date, the sender MUST generate those timestamps in the IMF-fixdate		date, the sender MUST generate those timestamps in the IMF-fixdate
	format.		format.
	An HTTP-date value represents time as an instance of Coordinated		An HTTP-date value represents time as an instance of Coordinated
	Universal Time (UTC). The first two formats indicate UTC by the		Universal Time (UTC). The first two formats indicate UTC by the
	three-letter abbreviation for Greenwich Mean Time, "GMT", a		three-letter abbreviation for Greenwich Mean Time, "GMT", a
	predecessor of the UTC name; values in the asctime format are assumed		predecessor of the UTC name; values in the asctime format are assumed
	to be in UTC. A sender that generates HTTP-date values from a local		to be in UTC. A sender that generates HTTP-date values from a local
	clock ought to use NTP ([RFC1305]) or some similar protocol to		clock ought to use NTP ([RFC5905]) or some similar protocol to
	synchronize its clock to UTC.		synchronize its clock to UTC.
	Preferred format:		Preferred format:
	IMF-fixdate = day-name "," SP date1 SP time-of-day SP GMT		IMF-fixdate = day-name "," SP date1 SP time-of-day SP GMT
	; fixed length/zone subset of the format defined in		; fixed length/zone subset of the format defined in
	; Section 3.3 of [RFC5322]		; Section 3.3 of [RFC5322]
	day-name = %x4D.6F.6E ; "Mon", case-sensitive		day-name = %x4D.6F.6E ; "Mon", case-sensitive
	/ %x54.75.65 ; "Tue", case-sensitive		/ %x54.75.65 ; "Tue", case-sensitive
	skipping to change at page 70, line 7		skipping to change at page 70, line 7
	7.1.3. Retry-After		7.1.3. Retry-After
	Servers send the "Retry-After" header field to indicate how long the		Servers send the "Retry-After" header field to indicate how long the
	user agent ought to wait before making a follow-up request. When		user agent ought to wait before making a follow-up request. When
	sent with a 503 (Service Unavailable) response, Retry-After indicates		sent with a 503 (Service Unavailable) response, Retry-After indicates
	how long the service is expected to be unavailable to the client.		how long the service is expected to be unavailable to the client.
	When sent with any 3xx (Redirection) response, Retry-After indicates		When sent with any 3xx (Redirection) response, Retry-After indicates
	the minimum time that the user agent is asked to wait before issuing		the minimum time that the user agent is asked to wait before issuing
	the redirected request.		the redirected request.
	The value of this field can be either an HTTP-date or an integer		The value of this field can be either an HTTP-date or a number of
	number of seconds (in decimal) after the time of the response.		seconds to delay after the response is received.
	Retry-After = HTTP-date / delta-seconds		Retry-After = HTTP-date / delay-seconds
	Time spans are non-negative decimal integers, representing time in		A delay-seconds value is a non-negative decimal integer, representing
	seconds.		time in seconds.
	delta-seconds = 1*DIGIT		delay-seconds = 1*DIGIT
	Two examples of its use are		Two examples of its use are
	Retry-After: Fri, 31 Dec 1999 23:59:59 GMT		Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
	Retry-After: 120		Retry-After: 120
	In the latter example, the delay is 2 minutes.		In the latter example, the delay is 2 minutes.
	7.1.4. Vary		7.1.4. Vary
	skipping to change at page 74, line 8		skipping to change at page 74, line 8
	subproducts by third parties. Overly long and detailed Server field		subproducts by third parties. Overly long and detailed Server field
	values increase response latency and potentially reveal internal		values increase response latency and potentially reveal internal
	implementation details that might make it (slightly) easier for		implementation details that might make it (slightly) easier for
	attackers to find and exploit known security holes.		attackers to find and exploit known security holes.
	8. IANA Considerations		8. IANA Considerations
	8.1. Method Registry		8.1. Method Registry
	The HTTP Method Registry defines the name space for the request		The HTTP Method Registry defines the name space for the request
	method token (Section 4). The method registry will be created and		method token (Section 4). The method registry will be created and
	maintained at <http://www.iana.org/assignments/http-methods>.		maintained at (the suggested URI)
			<http://www.iana.org/assignments/http-methods>.
	8.1.1. Procedure		8.1.1. Procedure
	HTTP method registrations MUST include the following fields:		HTTP method registrations MUST include the following fields:
	o Method Name (see Section 4)		o Method Name (see Section 4)
	o Safe ("yes" or "no", see Section 4.2.1)		o Safe ("yes" or "no", see Section 4.2.1)
	o Idempotent ("yes" or "no", see Section 4.2.2)		o Idempotent ("yes" or "no", see Section 4.2.2)
	skipping to change at page 78, line 13		skipping to change at page 78, line 13
	message-header-index.html>, as defined by [BCP90].		message-header-index.html>, as defined by [BCP90].
	8.3.1. Considerations for New Header Fields		8.3.1. Considerations for New Header Fields
	Header fields are key:value pairs that can be used to communicate		Header fields are key:value pairs that can be used to communicate
	data about the message, its payload, the target resource, or the		data about the message, its payload, the target resource, or the
	connection (i.e., control data). See Section 3.2 of [Part1] for a		connection (i.e., control data). See Section 3.2 of [Part1] for a
	general definition of header field syntax in HTTP messages.		general definition of header field syntax in HTTP messages.
	The requirements for header field names are defined in [BCP90].		The requirements for header field names are defined in [BCP90].
	Authors of specifications defining new fields are advised to keep the		Authors of specifications defining new fields are advised to keep the
	name as short as practical and to not prefix the name with "X-"		name as short as practical and to not prefix the name with "X-"
	unless the header field will never be used on the Internet. (The		unless the header field will never be used on the Internet. (The
	"x-" prefix idiom has been extensively misused in practice; it was		"x-" prefix idiom has been extensively misused in practice; it was
	intended to only be used as a mechanism for avoiding name collisions		intended to only be used as a mechanism for avoiding name collisions
	inside proprietary software or intranet processing, since the prefix		inside proprietary software or intranet processing, since the prefix
	would ensure that private names never collide with a newly registered		would ensure that private names never collide with a newly registered
	Internet name.)		Internet name; see [BCP178] for further information)
	New header field values typically have their syntax defined using		New header field values typically have their syntax defined using
	ABNF ([RFC5234]), using the extension defined in Section 7 of [Part1]		ABNF ([RFC5234]), using the extension defined in Section 7 of [Part1]
	as necessary, and are usually constrained to the range of ASCII		as necessary, and are usually constrained to the range of ASCII
	characters. Header fields needing a greater range of characters can		characters. Header fields needing a greater range of characters can
	use an encoding such as the one defined in [RFC5987].		use an encoding such as the one defined in [RFC5987].
	Leading and trailing whitespace in raw field values is removed upon		Leading and trailing whitespace in raw field values is removed upon
	field parsing (Section 3.2.4 of [Part1]). Field definitions where		field parsing (Section 3.2.4 of [Part1]). Field definitions where
	leading or trailing whitespace in values is significant will have to		leading or trailing whitespace in values is significant will have to
	skipping to change at page 81, line 25		skipping to change at page 81, line 25
	Values to be added to this name space require IETF Review (see		Values to be added to this name space require IETF Review (see
	Section 4.1 of [RFC5226]), and MUST conform to the purpose of content		Section 4.1 of [RFC5226]), and MUST conform to the purpose of content
	coding defined in this section.		coding defined in this section.
	8.4.2. Registrations		8.4.2. Registrations
	The HTTP Content Codings Registry shall be updated with the		The HTTP Content Codings Registry shall be updated with the
	registrations below:		registrations below:
	+------------+--------------------------------------+---------------+		+----------+----------------------------------------+---------------+
	| Name | Description | Reference |		| Name | Description | Reference |
	+------------+--------------------------------------+---------------+		+----------+----------------------------------------+---------------+
	| compress | UNIX "compress" data format [Welch] | Section 4.2.1 |		| identity | Reserved (synonym for "no encoding" in | Section 5.3.4 |
	| | | of [Part1] |		| | Accept-Encoding) | |
	| deflate | "deflate" compressed data | Section 4.2.2 |		+----------+----------------------------------------+---------------+
	| | ([RFC1951]) inside the "zlib" data | of [Part1] |
	| | format ([RFC1950]) | |
	| gzip | GZIP file format [RFC1952] | Section 4.2.3 |
	| | | of [Part1] |
	| identity | Reserved (synonym for "no encoding" | Section 5.3.4 |
	| | in Accept-Encoding) | |
	| x-compress | Deprecated (alias for compress) | Section 4.2.1 |
	| | | of [Part1] |
	| x-gzip | Deprecated (alias for gzip) | Section 4.2.3 |
	| | | of [Part1] |
	+------------+--------------------------------------+---------------+
	9. Security Considerations		9. Security Considerations
	This section is meant to inform developers, information providers,		This section is meant to inform developers, information providers,
	and users of known security concerns relevant to HTTP/1.1 semantics		and users of known security concerns relevant to HTTP/1.1 semantics
	and its use for transferring information over the Internet.		and its use for transferring information over the Internet.
	9.1. Attacks Based On File and Path Names		9.1. Attacks Based On File and Path Names
	Origin servers frequently make use of their local file system to		Origin servers frequently make use of their local file system to
	skipping to change at page 84, line 48		skipping to change at page 84, line 37
	10. Acknowledgments		10. Acknowledgments
	See Section 10 of [Part1].		See Section 10 of [Part1].
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[Part1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext		[Part1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
	Transfer Protocol (HTTP/1.1): Message Syntax and		Transfer Protocol (HTTP/1.1): Message Syntax and
	Routing", draft-ietf-httpbis-p1-messaging-24 (work in		Routing", draft-ietf-httpbis-p1-messaging-25 (work in
	progress), September 2013.		progress), November 2013.
	[Part4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext		[Part4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
	Transfer Protocol (HTTP/1.1): Conditional Requests",		Transfer Protocol (HTTP/1.1): Conditional Requests",
	draft-ietf-httpbis-p4-conditional-24 (work in		draft-ietf-httpbis-p4-conditional-25 (work in
	progress), September 2013.		progress), November 2013.
	[Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,		[Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
	"Hypertext Transfer Protocol (HTTP/1.1): Range		"Hypertext Transfer Protocol (HTTP/1.1): Range
	Requests", draft-ietf-httpbis-p5-range-24 (work in		Requests", draft-ietf-httpbis-p5-range-25 (work in
	progress), September 2013.		progress), November 2013.
	[Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,		[Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
	Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",		Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
	draft-ietf-httpbis-p6-cache-24 (work in progress),		draft-ietf-httpbis-p6-cache-25 (work in progress),
	September 2013.		November 2013.
	[Part7] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext		[Part7] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
	Transfer Protocol (HTTP/1.1): Authentication",		Transfer Protocol (HTTP/1.1): Authentication",
	draft-ietf-httpbis-p7-auth-24 (work in progress),		draft-ietf-httpbis-p7-auth-25 (work in progress),
	September 2013.		November 2013.
	[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data
	Format Specification version 3.3", RFC 1950, May 1996.
	[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format
	Specification version 1.3", RFC 1951, May 1996.
	[RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and
	G. Randers-Pehrson, "GZIP file format specification
	version 4.3", RFC 1952, May 1996.
	[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet		[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet
	Mail Extensions (MIME) Part One: Format of Internet		Mail Extensions (MIME) Part One: Format of Internet
	Message Bodies", RFC 2045, November 1996.		Message Bodies", RFC 2045, November 1996.
	[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet		[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet
	Mail Extensions (MIME) Part Two: Media Types",		Mail Extensions (MIME) Part Two: Media Types",
	RFC 2046, November 1996.		RFC 2046, November 1996.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	skipping to change at page 86, line 15		skipping to change at page 85, line 42
	January 2008.		January 2008.
	[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for		[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for
	Identifying Languages", BCP 47, RFC 5646,		Identifying Languages", BCP 47, RFC 5646,
	September 2009.		September 2009.
	[RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in		[RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in
	Internationalization in the IETF", BCP 166, RFC 6365,		Internationalization in the IETF", BCP 166, RFC 6365,
	September 2011.		September 2011.
	[Welch] Welch, T., "A Technique for High Performance Data
	Compression", IEEE Computer 17(6), June 1984.
	11.2. Informative References		11.2. Informative References
	[BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type		[BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type
	Specifications and Registration Procedures", BCP 13,		Specifications and Registration Procedures", BCP 13,
	RFC 6838, January 2013.		RFC 6838, January 2013.
			[BCP178] Saint-Andre, P., Crocker, D., and M. Nottingham,
			"Deprecating the "X-" Prefix and Similar Constructs in
			Application Protocols", BCP 178, RFC 6648, June 2012.
	[BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration		[BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration
	Procedures for Message Header Fields", BCP 90,		Procedures for Message Header Fields", BCP 90,
	RFC 3864, September 2004.		RFC 3864, September 2004.
	[REST] Fielding, R., "Architectural Styles and the Design of		[REST] Fielding, R., "Architectural Styles and the Design of
	Network-based Software Architectures", Doctoral		Network-based Software Architectures", Doctoral
	Dissertation, University of California, Irvine ,		Dissertation, University of California, Irvine ,
	September 2000,		September 2000,
	<http://roy.gbiv.com/pubs/dissertation/top.htm>.		<http://roy.gbiv.com/pubs/dissertation/top.htm>.
	[RFC1305] Mills, D., "Network Time Protocol (Version 3)
	Specification, Implementation", RFC 1305, March 1992.
	[RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen,		[RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen,
	"Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945,		"Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945,
	May 1996.		May 1996.
	[RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet		[RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet
	Mail Extensions (MIME) Part Five: Conformance Criteria		Mail Extensions (MIME) Part Five: Conformance Criteria
	and Examples", RFC 2049, November 1996.		and Examples", RFC 2049, November 1996.
	[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and		[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and
	T. Berners-Lee, "Hypertext Transfer Protocol --		T. Berners-Lee, "Hypertext Transfer Protocol --
	skipping to change at page 87, line 35		skipping to change at page 87, line 11
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing		[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing
	an IANA Considerations Section in RFCs", BCP 26,		an IANA Considerations Section in RFCs", BCP 26,
	RFC 5226, May 2008.		RFC 5226, May 2008.
	[RFC5322] Resnick, P., "Internet Message Format", RFC 5322,		[RFC5322] Resnick, P., "Internet Message Format", RFC 5322,
	October 2008.		October 2008.
	[RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP",		[RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP",
	RFC 5789, March 2010.		RFC 5789, March 2010.
			[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
			"Network Time Protocol Version 4: Protocol and
			Algorithms Specification", RFC 5905, June 2010.
	[RFC5987] Reschke, J., "Character Set and Language Encoding for		[RFC5987] Reschke, J., "Character Set and Language Encoding for
	Hypertext Transfer Protocol (HTTP) Header Field		Hypertext Transfer Protocol (HTTP) Header Field
	Parameters", RFC 5987, August 2010.		Parameters", RFC 5987, August 2010.
	[RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010.		[RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010.
	[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,		[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
	April 2011.		April 2011.
	[RFC6266] Reschke, J., "Use of the Content-Disposition Header		[RFC6266] Reschke, J., "Use of the Content-Disposition Header
	skipping to change at page 94, line 4		skipping to change at page 93, line 22
	Expect = "100-continue"		Expect = "100-continue"
	From = mailbox		From = mailbox
	GMT = %x47.4D.54 ; GMT		GMT = %x47.4D.54 ; GMT
	HTTP-date = IMF-fixdate / obs-date		HTTP-date = IMF-fixdate / obs-date
	IMF-fixdate = day-name "," SP date1 SP time-of-day SP GMT		IMF-fixdate = day-name "," SP date1 SP time-of-day SP GMT
	Location = URI-reference		Location = URI-reference
	Max-Forwards = 1*DIGIT		Max-Forwards = 1*DIGIT
	OWS = <OWS, defined in [Part1], Section 3.2.3>		OWS = <OWS, defined in [Part1], Section 3.2.3>
	RWS = <RWS, defined in [Part1], Section 3.2.3>		RWS = <RWS, defined in [Part1], Section 3.2.3>
	Referer = absolute-URI / partial-URI		Referer = absolute-URI / partial-URI
	Retry-After = HTTP-date / delta-seconds		Retry-After = HTTP-date / delay-seconds
	Server = product *( RWS ( product / comment ) )		Server = product *( RWS ( product / comment ) )
	URI-reference = <URI-reference, defined in [Part1], Section 2.7>		URI-reference = <URI-reference, defined in [Part1], Section 2.7>
	User-Agent = product *( RWS ( product / comment ) )		User-Agent = product *( RWS ( product / comment ) )
	Vary = "*" / ( *( "," OWS ) field-name *( OWS "," [ OWS field-name ]		Vary = "*" / ( *( "," OWS ) field-name *( OWS "," [ OWS field-name ]
	) )		) )
	absolute-URI = <absolute-URI, defined in [Part1], Section 2.7>		absolute-URI = <absolute-URI, defined in [Part1], Section 2.7>
	skipping to change at page 94, line 51		skipping to change at page 94, line 22
	/ %x46.72.69 ; Fri		/ %x46.72.69 ; Fri
	/ %x53.61.74 ; Sat		/ %x53.61.74 ; Sat
	/ %x53.75.6E ; Sun		/ %x53.75.6E ; Sun
	day-name-l = %x4D.6F.6E.64.61.79 ; Monday		day-name-l = %x4D.6F.6E.64.61.79 ; Monday
	/ %x54.75.65.73.64.61.79 ; Tuesday		/ %x54.75.65.73.64.61.79 ; Tuesday
	/ %x57.65.64.6E.65.73.64.61.79 ; Wednesday		/ %x57.65.64.6E.65.73.64.61.79 ; Wednesday
	/ %x54.68.75.72.73.64.61.79 ; Thursday		/ %x54.68.75.72.73.64.61.79 ; Thursday
	/ %x46.72.69.64.61.79 ; Friday		/ %x46.72.69.64.61.79 ; Friday
	/ %x53.61.74.75.72.64.61.79 ; Saturday		/ %x53.61.74.75.72.64.61.79 ; Saturday
	/ %x53.75.6E.64.61.79 ; Sunday		/ %x53.75.6E.64.61.79 ; Sunday
	delta-seconds = 1*DIGIT		delay-seconds = 1*DIGIT
	field-name = <comment, defined in [Part1], Section 3.2>		field-name = <comment, defined in [Part1], Section 3.2>
	hour = 2DIGIT		hour = 2DIGIT
	language-range = <language-range, defined in [RFC4647], Section 2.1>		language-range = <language-range, defined in [RFC4647], Section 2.1>
	language-tag = <Language-Tag, defined in [RFC5646], Section 2.1>		language-tag = <Language-Tag, defined in [RFC5646], Section 2.1>
	mailbox = <mailbox, defined in [RFC5322], Section 3.4>		mailbox = <mailbox, defined in [RFC5322], Section 3.4>
	media-range = ( "*/*" / ( type "/*" ) / ( type "/" subtype ) ) *( OWS		media-range = ( "*/*" / ( type "/*" ) / ( type "/" subtype ) ) *( OWS
	";" OWS parameter )		";" OWS parameter )
	skipping to change at page 96, line 12		skipping to change at page 95, line 32
	weight = OWS ";" OWS "q=" qvalue		weight = OWS ";" OWS "q=" qvalue
	word = <word, defined in [Part1], Section 3.2.6>		word = <word, defined in [Part1], Section 3.2.6>
	year = 4DIGIT		year = 4DIGIT
	Appendix E. Change Log (to be removed by RFC Editor before publication)		Appendix E. Change Log (to be removed by RFC Editor before publication)
	E.1. Since RFC 2616		E.1. Since RFC 2616
	Changes up to the first Working Group Last Call draft are summarized		Changes up to the IETF Last Call draft are summarized in <http://
	in <http://trac.tools.ietf.org/html/		trac.tools.ietf.org/html/
	draft-ietf-httpbis-p2-semantics-21#appendix-F>.		draft-ietf-httpbis-p2-semantics-24#appendix-E>.
	E.2. Since draft-ietf-httpbis-p2-semantics-21
	Closed issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/22>: "ETag (and
	other metadata) in status messages"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/96>: "Conditional
	GET text"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/146>: "Clarify
	description of 405 (Not Allowed)"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/223>: "Allowing
	heuristic caching for new status codes"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/315>: "method
	semantics: retrieval/representation"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/388>: "User
	confirmation for unsafe methods"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/404>: "Tentative
	Status Codes"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/418>: "No-Transform"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/419>: "p2 editorial
	feedback"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/424>: "Absence of
	Accept-Encoding"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/428>: "Accept-
	Language ordering for identical qvalues"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/432>: "Identify
	additional status codes as cacheable by default"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/434>: "mention in
	header field considerations that leading/trailing WS is lossy"
	E.3. Since draft-ietf-httpbis-p2-semantics-22
	Closed issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/436>: "explain list
	expansion in ABNF appendices"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/448>: "Fallback for
	Accept-Language"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/449>: "Receiving a
	higher minor HTTP version number"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/456>: "Language-tag
	vs. language-range"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/457>: "Registering
	x-gzip and x-deflate"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/459>: "RFC2774 and
	method registrations"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/488>: "Selection
	based upon request target"
	E.4. Since draft-ietf-httpbis-p2-semantics-23		E.2. Since draft-ietf-httpbis-p2-semantics-24
	Closed issues:		Closed issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/303>: "400 response		o <http://tools.ietf.org/wg/httpbis/trac/ticket/432>: "Review
	isn't generic"		Cachability of Status Codes WRT 'Negative Caching'"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/450>: "p2 Editorial
	feedback"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/452>: "Content-
	Length in HEAD responses"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/458>: "Requirements
	upon proxies for Expect"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/468>: "Expectation
	Extensions"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/470>: "What is		o <http://tools.ietf.org/wg/httpbis/trac/ticket/499>: "RFC 1305 ref
	'Cacheable'?"		needs to be updated to 5905"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/478>: "MUSTs and		o <http://tools.ietf.org/wg/httpbis/trac/ticket/501>: "idempotency:
	other feedback"		clarify 'effect'"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/487>: "Resubmission		o <http://tools.ietf.org/wg/httpbis/trac/ticket/503>: "APPSDIR
	of 403"		review of draft-ietf-httpbis-p2-semantics-24"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/491>: "does 205		o <http://tools.ietf.org/wg/httpbis/trac/ticket/517>: "move IANA
	allow chunked encoding?"		registrations to correct draft"
	Index		Index
	1		1
	1xx Informational (status code class) 50		1xx Informational (status code class) 50
	2		2
	2xx Successful (status code class) 51		2xx Successful (status code class) 51
	3		3
	skipping to change at page 99, line 7		skipping to change at page 96, line 44
	203 Non-Authoritative Information (status code) 52		203 Non-Authoritative Information (status code) 52
	204 No Content (status code) 53		204 No Content (status code) 53
	205 Reset Content (status code) 53		205 Reset Content (status code) 53
	3		3
	300 Multiple Choices (status code) 55		300 Multiple Choices (status code) 55
	301 Moved Permanently (status code) 56		301 Moved Permanently (status code) 56
	302 Found (status code) 56		302 Found (status code) 56
	303 See Other (status code) 57		303 See Other (status code) 57
	305 Use Proxy (status code) 57		305 Use Proxy (status code) 57
	306 (Unused) (status code) 57		306 (Unused) (status code) 58
	307 Temporary Redirect (status code) 58		307 Temporary Redirect (status code) 58
	4		4
	400 Bad Request (status code) 58		400 Bad Request (status code) 58
	402 Payment Required (status code) 58		402 Payment Required (status code) 58
	403 Forbidden (status code) 58		403 Forbidden (status code) 59
	404 Not Found (status code) 59		404 Not Found (status code) 59
	405 Method Not Allowed (status code) 59		405 Method Not Allowed (status code) 59
	406 Not Acceptable (status code) 59		406 Not Acceptable (status code) 59
	408 Request Timeout (status code) 60		408 Request Timeout (status code) 60
	409 Conflict (status code) 60		409 Conflict (status code) 60
	410 Gone (status code) 60		410 Gone (status code) 60
	411 Length Required (status code) 61		411 Length Required (status code) 61
	413 Payload Too Large (status code) 61		413 Payload Too Large (status code) 61
	414 URI Too Long (status code) 61		414 URI Too Long (status code) 61
	415 Unsupported Media Type (status code) 61		415 Unsupported Media Type (status code) 62
	417 Expectation Failed (status code) 62		417 Expectation Failed (status code) 62
	426 Upgrade Required (status code) 62		426 Upgrade Required (status code) 62
	5		5
	500 Internal Server Error (status code) 62		500 Internal Server Error (status code) 63
	501 Not Implemented (status code) 62		501 Not Implemented (status code) 63
	502 Bad Gateway (status code) 63		502 Bad Gateway (status code) 63
	503 Service Unavailable (status code) 63		503 Service Unavailable (status code) 63
	504 Gateway Timeout (status code) 63		504 Gateway Timeout (status code) 63
	505 HTTP Version Not Supported (status code) 63		505 HTTP Version Not Supported (status code) 63
	A		A
	Accept header field 38		Accept header field 38
	Accept-Charset header field 40		Accept-Charset header field 40
	Accept-Encoding header field 41		Accept-Encoding header field 41
	Accept-Language header field 42		Accept-Language header field 42
	skipping to change at page 100, line 42		skipping to change at page 98, line 30
	content-coding 11		content-coding 11
	Content-Encoding 12		Content-Encoding 12
	Content-Language 13		Content-Language 13
	Content-Location 15		Content-Location 15
	Content-Type 10		Content-Type 10
	Date 67		Date 67
	date1 66		date1 66
	day 66		day 66
	day-name 66		day-name 66
	day-name-l 66		day-name-l 66
	delta-seconds 70		delay-seconds 70
	Expect 34		Expect 34
	From 44		From 44
	GMT 66		GMT 66
	hour 66		hour 66
	HTTP-date 64		HTTP-date 64
	IMF-fixdate 66		IMF-fixdate 66
	language-range 42		language-range 42
	language-tag 13		language-tag 13
	Location 68		Location 68
	Max-Forwards 36		Max-Forwards 36
End of changes. 64 change blocks.
	216 lines changed or deleted		135 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/