draft-ietf-httpbis-p2-semantics-01.txt		draft-ietf-httpbis-p2-semantics-02.txt
	Network Working Group R. Fielding, Ed.		Network 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
	Intended status: Standards Track One Laptop per Child		Intended status: Standards Track One Laptop per Child
	Expires: July 15, 2008 J. Mogul		Expires: August 27, 2008 J. Mogul
	HP		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
	January 12, 2008		February 24, 2008
	HTTP/1.1, part 2: Message Semantics		HTTP/1.1, part 2: Message Semantics
	draft-ietf-httpbis-p2-semantics-01		draft-ietf-httpbis-p2-semantics-02
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 49		skipping to change at page 1, line 49
	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 July 15, 2008.		This Internet-Draft will expire on August 27, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2008).		Copyright (C) The IETF Trust (2008).
	Abstract		Abstract
	The Hypertext Transfer Protocol (HTTP) is an application-level		The Hypertext Transfer Protocol (HTTP) is an application-level
	protocol for distributed, collaborative, hypermedia information		protocol for distributed, collaborative, hypermedia information
	systems. HTTP has been in use by the World Wide Web global		systems. HTTP has been in use by the World Wide Web global
	skipping to change at page 3, line 9		skipping to change at page 3, line 9
	This draft incorporates those issue resolutions that were either		This draft incorporates those issue resolutions that were either
	collected in the original RFC2616 errata list		collected in the original RFC2616 errata list
	(<http://purl.org/NET/http-errata>), or which were agreed upon on the		(<http://purl.org/NET/http-errata>), or which were agreed upon on the
	mailing list between October 2006 and November 2007 (as published in		mailing list between October 2006 and November 2007 (as published in
	"draft-lafon-rfc2616bis-03").		"draft-lafon-rfc2616bis-03").
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
	1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6		1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6
	2. Product Tokens . . . . . . . . . . . . . . . . . . . . . . . . 6		2. Notational Conventions and Generic Grammar . . . . . . . . . . 6
	3. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7		3. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	4. Request Header Fields . . . . . . . . . . . . . . . . . . . . 7		4. Request Header Fields . . . . . . . . . . . . . . . . . . . . 8
	5. Status Code and Reason Phrase . . . . . . . . . . . . . . . . 8		5. Status Code and Reason Phrase . . . . . . . . . . . . . . . . 9
	6. Response Header Fields . . . . . . . . . . . . . . . . . . . . 10		6. Response Header Fields . . . . . . . . . . . . . . . . . . . . 11
	7. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10		7. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	8. Method Definitions . . . . . . . . . . . . . . . . . . . . . . 11		8. Method Definitions . . . . . . . . . . . . . . . . . . . . . . 12
	8.1. Safe and Idempotent Methods . . . . . . . . . . . . . . . 11		8.1. Safe and Idempotent Methods . . . . . . . . . . . . . . . 12
	8.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . 11		8.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . 12
	8.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . . 11		8.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . . 12
	8.2. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 12		8.2. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 13
	8.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . . . 13		8.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	8.4. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . . 13		8.4. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	8.5. POST . . . . . . . . . . . . . . . . . . . . . . . . . . . 14		8.5. POST . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
	8.6. PUT . . . . . . . . . . . . . . . . . . . . . . . . . . . 15		8.6. PUT . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
	8.7. DELETE . . . . . . . . . . . . . . . . . . . . . . . . . . 16		8.7. DELETE . . . . . . . . . . . . . . . . . . . . . . . . . . 17
	8.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . . . 16		8.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . . . 17
	8.9. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . . 17		8.9. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . . 18
	9. Status Code Definitions . . . . . . . . . . . . . . . . . . . 17		9. Status Code Definitions . . . . . . . . . . . . . . . . . . . 18
	9.1. Informational 1xx . . . . . . . . . . . . . . . . . . . . 17		9.1. Informational 1xx . . . . . . . . . . . . . . . . . . . . 18
	9.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 17		9.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 18
	9.1.2. 101 Switching Protocols . . . . . . . . . . . . . . . 18		9.1.2. 101 Switching Protocols . . . . . . . . . . . . . . . 19
	9.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 18		9.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 19
	9.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 18		9.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 19
	9.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 18		9.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 19
	9.2.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 19		9.2.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 20
	9.2.4. 203 Non-Authoritative Information . . . . . . . . . . 19		9.2.4. 203 Non-Authoritative Information . . . . . . . . . . 20
	9.2.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 19		9.2.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 20
	9.2.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 20		9.2.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 21
	9.2.7. 206 Partial Content . . . . . . . . . . . . . . . . . 20		9.2.7. 206 Partial Content . . . . . . . . . . . . . . . . . 21
	9.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 20		9.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 21
	9.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 20		9.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 21
	9.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 21		9.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 22
	9.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 21		9.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 22
	9.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 22		9.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 23
	9.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . . 22		9.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . . 23
	9.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 22		9.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 23
	9.3.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 23		9.3.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 24
	9.3.8. 307 Temporary Redirect . . . . . . . . . . . . . . . . 23		9.3.8. 307 Temporary Redirect . . . . . . . . . . . . . . . . 24
	9.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 23		9.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 24
	9.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 24		9.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 25
	9.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . . 24		9.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . . 25
	9.4.3. 402 Payment Required . . . . . . . . . . . . . . . . . 24		9.4.3. 402 Payment Required . . . . . . . . . . . . . . . . . 25
	9.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 24		9.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 25
	9.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . . 24		9.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . . 25
	9.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . . 24		9.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . . 25
	9.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 24		9.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 25
	9.4.8. 407 Proxy Authentication Required . . . . . . . . . . 25		9.4.8. 407 Proxy Authentication Required . . . . . . . . . . 26
	9.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . . 25		9.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . . 26
	9.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 25		9.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 26
	9.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 26		9.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 27
	9.4.12. 411 Length Required . . . . . . . . . . . . . . . . . 26		9.4.12. 411 Length Required . . . . . . . . . . . . . . . . . 27
	9.4.13. 412 Precondition Failed . . . . . . . . . . . . . . . 26		9.4.13. 412 Precondition Failed . . . . . . . . . . . . . . . 27
	9.4.14. 413 Request Entity Too Large . . . . . . . . . . . . . 26		9.4.14. 413 Request Entity Too Large . . . . . . . . . . . . . 27
	9.4.15. 414 Request-URI Too Long . . . . . . . . . . . . . . . 27		9.4.15. 414 Request-URI Too Long . . . . . . . . . . . . . . . 28
	9.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . . 27		9.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . . 28
	9.4.17. 416 Requested Range Not Satisfiable . . . . . . . . . 27		9.4.17. 416 Requested Range Not Satisfiable . . . . . . . . . 28
	9.4.18. 417 Expectation Failed . . . . . . . . . . . . . . . . 27		9.4.18. 417 Expectation Failed . . . . . . . . . . . . . . . . 28
	9.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 27		9.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 28
	9.5.1. 500 Internal Server Error . . . . . . . . . . . . . . 27		9.5.1. 500 Internal Server Error . . . . . . . . . . . . . . 28
	9.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 28		9.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 29
	9.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 28		9.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 29
	9.5.4. 503 Service Unavailable . . . . . . . . . . . . . . . 28		9.5.4. 503 Service Unavailable . . . . . . . . . . . . . . . 29
	9.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 28		9.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 29
	9.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 28		9.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 29
	10. Header Field Definitions . . . . . . . . . . . . . . . . . . . 29		10. Header Field Definitions . . . . . . . . . . . . . . . . . . . 30
	10.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . . . 29		10.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . . . 30
	10.2. Expect . . . . . . . . . . . . . . . . . . . . . . . . . . 29		10.2. Expect . . . . . . . . . . . . . . . . . . . . . . . . . . 30
	10.3. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 30		10.3. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
	10.4. Location . . . . . . . . . . . . . . . . . . . . . . . . . 31		10.4. Location . . . . . . . . . . . . . . . . . . . . . . . . . 32
	10.5. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . . 32		10.5. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . . 33
	10.6. Referer . . . . . . . . . . . . . . . . . . . . . . . . . 32		10.6. Referer . . . . . . . . . . . . . . . . . . . . . . . . . 33
	10.7. Retry-After . . . . . . . . . . . . . . . . . . . . . . . 33		10.7. Retry-After . . . . . . . . . . . . . . . . . . . . . . . 34
	10.8. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 33		10.8. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 34
	10.9. User-Agent . . . . . . . . . . . . . . . . . . . . . . . . 34		10.9. User-Agent . . . . . . . . . . . . . . . . . . . . . . . . 35
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
	12. Security Considerations . . . . . . . . . . . . . . . . . . . 34		12. Security Considerations . . . . . . . . . . . . . . . . . . . 35
	12.1. Transfer of Sensitive Information . . . . . . . . . . . . 34		12.1. Transfer of Sensitive Information . . . . . . . . . . . . 35
	12.2. Encoding Sensitive Information in URI's . . . . . . . . . 35		12.2. Encoding Sensitive Information in URIs . . . . . . . . . . 36
	12.3. Location Headers and Spoofing . . . . . . . . . . . . . . 36		12.3. Location Headers and Spoofing . . . . . . . . . . . . . . 37
	13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36		13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37
	14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36		14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
	14.1. Normative References . . . . . . . . . . . . . . . . . . . 36		14.1. Normative References . . . . . . . . . . . . . . . . . . . 37
	14.2. Informative References . . . . . . . . . . . . . . . . . . 37		14.2. Informative References . . . . . . . . . . . . . . . . . . 38
	Appendix A. Compatibility with Previous Versions . . . . . . . . 37		Appendix A. Compatibility with Previous Versions . . . . . . . . 38
	A.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 37		A.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 38
	A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 38		A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 39
	Appendix B. Change Log (to be removed by RFC Editor before		Appendix B. Change Log (to be removed by RFC Editor before
	publication) . . . . . . . . . . . . . . . . . . . . 39		publication) . . . . . . . . . . . . . . . . . . . . 40
	B.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 39		B.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 40
	B.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 39		B.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 40
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39		B.3. Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . . 41
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43		Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
	Intellectual Property and Copyright Statements . . . . . . . . . . 47		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45
			Intellectual Property and Copyright Statements . . . . . . . . . . 48
	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 6, line 42		skipping to change at page 6, line 42
	An implementation is not compliant if it fails to satisfy one or more		An implementation is not compliant if it fails to satisfy one or more
	of the MUST or REQUIRED level requirements for the protocols it		of the MUST or REQUIRED level requirements for the protocols it
	implements. An implementation that satisfies all the MUST or		implements. An implementation that satisfies all the MUST or
	REQUIRED level and all the SHOULD level requirements for its		REQUIRED level and all the SHOULD level requirements for its
	protocols is said to be "unconditionally compliant"; one that		protocols is said to be "unconditionally compliant"; one that
	satisfies all the MUST level requirements but not all the SHOULD		satisfies all the MUST level requirements but not all the SHOULD
	level requirements for its protocols is said to be "conditionally		level requirements for its protocols is said to be "conditionally
	compliant."		compliant."
	2. Product Tokens		2. Notational Conventions and Generic Grammar
	Product tokens are used to allow communicating applications to		This specification uses the ABNF syntax defined in Section 2.1 of
	identify themselves by software name and version. Most fields using		[Part1] and the core rules defined in Section 2.2 of [Part1]:
	product tokens also allow sub-products which form a significant part		[[abnf.dep: ABNF syntax and basic rules will be adopted from RFC
	of the application to be listed, separated by white space. By		5234, see <http://tools.ietf.org/wg/httpbis/trac/ticket/36>.]]
	convention, the products are listed in order of their significance
	for identifying the application.
	product = token ["/" product-version]		DIGIT = <DIGIT, defined in [Part1], Section 2.2>
	product-version = token		comment = <comment, defined in [Part1], Section 2.2>
			quoted-string = <quoted-string, defined in [Part1], Section 2.2>
			token = <token, defined in [Part1], Section 2.2>
	Examples:		The ABNF rules below are defined in other parts:
	User-Agent: CERN-LineMode/2.15 libwww/2.17b3		absoluteURI = <absoluteURI, defined in [Part1], Section 3.2.1>
	Server: Apache/0.8.4		fragment = <fragment, defined in [Part1], Section 3.2.1>
			Host = <Host, defined in [Part1], Section 8.4>
			HTTP-date = <HTTP-date, defined in [Part1], Section 3.3.1>
			product = <product, defined in [Part1], Section 3.5>
			relativeURI = <relativeURI, defined in [Part1], Section 3.2.1>
			TE = <TE, defined in [Part1], Section 8.8>
	Product tokens SHOULD be short and to the point. They MUST NOT be		Accept = <Accept, defined in [Part3], Section 6.1>
	used for advertising or other non-essential information. Although		Accept-Charset =
	any token character MAY appear in a product-version, this token		<Accept-Charset, defined in [Part3], Section 6.2>
	SHOULD only be used for a version identifier (i.e., successive		Accept-Encoding =
	versions of the same product SHOULD only differ in the product-		<Accept-Encoding, defined in [Part3], Section 6.3>
	version portion of the product value).		Accept-Language =
			<Accept-Language, defined in [Part3], Section 6.4>
			ETag = <ETag, defined in [Part4], Section 7.1>
			If-Match = <If-Match, defined in [Part4], Section 7.2>
			If-Modified-Since =
			<If-Modified-Since, defined in [Part4], Section 7.3>
			If-None-Match = <If-None-Match, defined in [Part4], Section 7.4>
			If-Unmodified-Since =
			<If-Unmodified-Since, defined in [Part4], Section 7.5>
			Accept-Ranges = <Accept-Ranges, defined in [Part5], Section 6.1>
			If-Range = <If-Range, defined in [Part5], Section 6.3>
			Range = <Range, defined in [Part5], Section 6.4>
			Age = <Age, defined in [Part6], Section 16.1>
			Vary = <Vary, defined in [Part6], Section 16.5>
			Authorization = <Authorization, defined in [Part7], Section 4.1>
			Proxy-Authenticate =
			<Proxy-Authenticate, defined in [Part7], Section 4.2>
			Proxy-Authorization =
			<Proxy-Authorization, defined in [Part7], Section 4.3>
			WWW-Authenticate =
			<WWW-Authenticate, defined in [Part7], Section 4.4>
	3. Method		3. Method
	The Method token indicates the method to be performed on the resource		The Method token indicates the method to be performed on the resource
	identified by the Request-URI. The method is case-sensitive.		identified by the Request-URI. The method is case-sensitive.
	Method = "OPTIONS" ; Section 8.2		Method = "OPTIONS" ; Section 8.2
	| "GET" ; Section 8.3		| "GET" ; Section 8.3
	| "HEAD" ; Section 8.4		| "HEAD" ; Section 8.4
	| "POST" ; Section 8.5		| "POST" ; Section 8.5
	skipping to change at page 8, line 9		skipping to change at page 9, line 5
	those specified in Section 8.		those specified in Section 8.
	4. Request Header Fields		4. Request Header Fields
	The request-header fields allow the client to pass additional		The request-header fields allow the client to pass additional
	information about the request, and about the client itself, to the		information about the request, and about the client itself, to the
	server. These fields act as request modifiers, with semantics		server. These fields act as request modifiers, with semantics
	equivalent to the parameters on a programming language method		equivalent to the parameters on a programming language method
	invocation.		invocation.
	request-header = Accept ; [Part3], Section 5.1		request-header = Accept ; [Part3], Section 6.1
	| Accept-Charset ; [Part3], Section 5.2		| Accept-Charset ; [Part3], Section 6.2
	| Accept-Encoding ; [Part3], Section 5.3		| Accept-Encoding ; [Part3], Section 6.3
	| Accept-Language ; [Part3], Section 5.4		| Accept-Language ; [Part3], Section 6.4
	| Authorization ; [Part7], Section 3.1		| Authorization ; [Part7], Section 4.1
	| Expect ; Section 10.2		| Expect ; Section 10.2
	| From ; Section 10.3		| From ; Section 10.3
	| Host ; [Part1], Section 8.4		| Host ; [Part1], Section 8.4
	| If-Match ; [Part4], Section 6.2		| If-Match ; [Part4], Section 7.2
	| If-Modified-Since ; [Part4], Section 6.3		| If-Modified-Since ; [Part4], Section 7.3
	| If-None-Match ; [Part4], Section 6.4		| If-None-Match ; [Part4], Section 7.4
	| If-Range ; [Part5], Section 5.3		| If-Range ; [Part5], Section 6.3
	| If-Unmodified-Since ; [Part4], Section 6.5		| If-Unmodified-Since ; [Part4], Section 7.5
	| Max-Forwards ; Section 10.5		| Max-Forwards ; Section 10.5
	| Proxy-Authorization ; [Part7], Section 3.3		| Proxy-Authorization ; [Part7], Section 4.3
	| Range ; [Part5], Section 5.4		| Range ; [Part5], Section 6.4
	| Referer ; Section 10.6		| Referer ; Section 10.6
	| TE ; [Part1], Section 8.8		| TE ; [Part1], Section 8.8
	| User-Agent ; Section 10.9		| User-Agent ; Section 10.9
	Request-header field names can be extended reliably only in		Request-header field names can be extended reliably only in
	combination with a change in the protocol version. However, new or		combination with a change in the protocol version. However, new or
	experimental header fields MAY be given the semantics of request-		experimental header fields MAY be given the semantics of request-
	header fields if all parties in the communication recognize them to		header fields if all parties in the communication recognize them to
	be request-header fields. Unrecognized header fields are treated as		be request-header fields. Unrecognized header fields are treated as
	entity-header fields.		entity-header fields.
	skipping to change at page 10, line 23		skipping to change at page 11, line 23
	with the response, since that entity is likely to include human-		with the response, since that entity is likely to include human-
	readable information which will explain the unusual status.		readable information which will explain the unusual status.
	6. Response Header Fields		6. Response Header Fields
	The response-header fields allow the server to pass additional		The response-header fields allow the server to pass additional
	information about the response which cannot be placed in the Status-		information about the response which cannot be placed in the Status-
	Line. These header fields give information about the server and		Line. These header fields give information about the server and
	about further access to the resource identified by the Request-URI.		about further access to the resource identified by the Request-URI.
	response-header = Accept-Ranges ; [Part5], Section 5.1		response-header = Accept-Ranges ; [Part5], Section 6.1
	| Age ; [Part6], Section 15.1		| Age ; [Part6], Section 16.1
	| ETag ; [Part4], Section 6.1		| ETag ; [Part4], Section 7.1
	| Location ; Section 10.4		| Location ; Section 10.4
	| Proxy-Authenticate ; [Part7], Section 3.2		| Proxy-Authenticate ; [Part7], Section 4.2
	| Retry-After ; Section 10.7		| Retry-After ; Section 10.7
	| Server ; Section 10.8		| Server ; Section 10.8
	| Vary ; [Part6], Section 15.5		| Vary ; [Part6], Section 16.5
	| WWW-Authenticate ; [Part7], Section 3.4		| WWW-Authenticate ; [Part7], Section 4.4
	Response-header field names can be extended reliably only in		Response-header field names can be extended reliably only in
	combination with a change in the protocol version. However, new or		combination with a change in the protocol version. However, new or
	experimental header fields MAY be given the semantics of response-		experimental header fields MAY be given the semantics of response-
	header fields if all parties in the communication recognize them to		header fields if all parties in the communication recognize them to
	be response-header fields. Unrecognized header fields are treated as		be response-header fields. Unrecognized header fields are treated as
	entity-header fields.		entity-header fields.
	7. Entity		7. Entity
	skipping to change at page 11, line 13		skipping to change at page 12, line 13
	present, as described in Section 4.3 of [Part1]. The entity-body is		present, as described in Section 4.3 of [Part1]. The entity-body is
	obtained from the message-body by decoding any Transfer-Encoding that		obtained from the message-body by decoding any Transfer-Encoding that
	might have been applied to ensure safe and proper transfer of the		might have been applied to ensure safe and proper transfer of the
	message.		message.
	8. Method Definitions		8. Method Definitions
	The set of common methods for HTTP/1.1 is defined below. Although		The set of common methods for HTTP/1.1 is defined below. Although
	this set can be expanded, additional methods cannot be assumed to		this set can be expanded, additional methods cannot be assumed to
	share the same semantics for separately extended clients and servers.		share the same semantics for separately extended clients and servers.
	The Host request-header field (Section 8.4 of [Part1]) MUST accompany
	all HTTP/1.1 requests.
	8.1. Safe and Idempotent Methods		8.1. Safe and Idempotent Methods
	8.1.1. Safe Methods		8.1.1. Safe Methods
	Implementors should be aware that the software represents the user in		Implementors should be aware that the software represents the user in
	their interactions over the Internet, and should be careful to allow		their interactions over the Internet, and should be careful to allow
	the user to be aware of any actions they might take which may have an		the user to be aware of any actions they might take which may have an
	unexpected significance to themselves or others.		unexpected significance to themselves or others.
	skipping to change at page 13, line 37		skipping to change at page 14, line 34
	If-Match, If-None-Match, or If-Range header field. A conditional GET		If-Match, If-None-Match, or If-Range header field. A conditional GET
	method requests that the entity be transferred only under the		method requests that the entity be transferred only under the
	circumstances described by the conditional header field(s). The		circumstances described by the conditional header field(s). The
	conditional GET method is intended to reduce unnecessary network		conditional GET method is intended to reduce unnecessary network
	usage by allowing cached entities to be refreshed without requiring		usage by allowing cached entities to be refreshed without requiring
	multiple requests or transferring data already held by the client.		multiple requests or transferring data already held by the client.
	The semantics of the GET method change to a "partial GET" if the		The semantics of the GET method change to a "partial GET" if the
	request message includes a Range header field. A partial GET		request message includes a Range header field. A partial GET
	requests that only part of the entity be transferred, as described in		requests that only part of the entity be transferred, as described in
	Section 5.4 of [Part5]. The partial GET method is intended to reduce		Section 6.4 of [Part5]. The partial GET method is intended to reduce
	unnecessary network usage by allowing partially-retrieved entities to		unnecessary network usage by allowing partially-retrieved entities to
	be completed without transferring data already held by the client.		be completed without transferring data already held by the client.
	The response to a GET request is cacheable if and only if it meets		The response to a GET request is cacheable if and only if it meets
	the requirements for HTTP caching described in [Part6].		the requirements for HTTP caching described in [Part6].
	See Section 12.2 for security considerations when used for forms.		See Section 12.2 for security considerations when used for forms.
	8.4. HEAD		8.4. HEAD
	skipping to change at page 15, line 14		skipping to change at page 16, line 14
	8.6. PUT		8.6. PUT
	The PUT method requests that the enclosed entity be stored under the		The PUT method requests that the enclosed entity be stored under the
	supplied Request-URI. If the Request-URI refers to an already		supplied Request-URI. If the Request-URI refers to an already
	existing resource, the enclosed entity SHOULD be considered as a		existing resource, the enclosed entity SHOULD be considered as a
	modified version of the one residing on the origin server. If the		modified version of the one residing on the origin server. If the
	Request-URI does not point to an existing resource, and that URI is		Request-URI does not point to an existing resource, and that URI is
	capable of being defined as a new resource by the requesting user		capable of being defined as a new resource by the requesting user
	agent, the origin server can create the resource with that URI. If a		agent, the origin server can create the resource with that URI. If a
	new resource is created, the origin server MUST inform the user agent		new resource is created at the Request-URI, the origin server MUST
	via the 201 (Created) response. If an existing resource is modified,		inform the user agent via the 201 (Created) response. If an existing
	either the 200 (OK) or 204 (No Content) response codes SHOULD be sent		resource is modified, either the 200 (OK) or 204 (No Content)
	to indicate successful completion of the request. If the resource		response codes SHOULD be sent to indicate successful completion of
	could not be created or modified with the Request-URI, an appropriate		the request. If the resource could not be created or modified with
	error response SHOULD be given that reflects the nature of the		the Request-URI, an appropriate error response SHOULD be given that
	problem. The recipient of the entity MUST NOT ignore any Content-*		reflects the nature of the problem. The recipient of the entity MUST
	(e.g. Content-Range) headers that it does not understand or		NOT ignore any Content-* (e.g. Content-Range) headers that it does
	implement and MUST return a 501 (Not Implemented) response in such		not understand or implement and MUST return a 501 (Not Implemented)
	cases.		response in such cases.
	If the request passes through a cache and the Request-URI identifies		If the request passes through a cache and the Request-URI identifies
	one or more currently cached entities, those entries SHOULD be		one or more currently cached entities, those entries SHOULD be
	treated as stale. Responses to this method are not cacheable.		treated as stale. Responses to this method are not cacheable.
	The fundamental difference between the POST and PUT requests is		The fundamental difference between the POST and PUT requests is
	reflected in the different meaning of the Request-URI. The URI in a		reflected in the different meaning of the Request-URI. The URI in a
	POST request identifies the resource that will handle the enclosed		POST request identifies the resource that will handle the enclosed
	entity. That resource might be a data-accepting process, a gateway		entity. That resource might be a data-accepting process, a gateway
	to some other protocol, or a separate entity that accepts		to some other protocol, or a separate entity that accepts
	skipping to change at page 18, line 8		skipping to change at page 19, line 8
	been received and has not yet been rejected by the server. The		been received and has not yet been rejected by the server. The
	client SHOULD continue by sending the remainder of the request or, if		client SHOULD continue by sending the remainder of the request or, if
	the request has already been completed, ignore this response. The		the request has already been completed, ignore this response. The
	server MUST send a final response after the request has been		server MUST send a final response after the request has been
	completed. See Section 7.2.3 of [Part1] for detailed discussion of		completed. See Section 7.2.3 of [Part1] for detailed discussion of
	the use and handling of this status code.		the use and handling of this status code.
	9.1.2. 101 Switching Protocols		9.1.2. 101 Switching Protocols
	The server understands and is willing to comply with the client's		The server understands and is willing to comply with the client's
	request, via the Upgrade message header field (Section 5.4 of		request, via the Upgrade message header field (Section 6.4 of
	[Part5]), for a change in the application protocol being used on this		[Part5]), for a change in the application protocol being used on this
	connection. The server will switch protocols to those defined by the		connection. The server will switch protocols to those defined by the
	response's Upgrade header field immediately after the empty line		response's Upgrade header field immediately after the empty line
	which terminates the 101 response.		which terminates the 101 response.
	The protocol SHOULD be switched only when it is advantageous to do		The protocol SHOULD be switched only when it is advantageous to do
	so. For example, switching to a newer version of HTTP is		so. For example, switching to a newer version of HTTP is
	advantageous over older versions, and switching to a real-time,		advantageous over older versions, and switching to a real-time,
	synchronous protocol might be advantageous when delivering resources		synchronous protocol might be advantageous when delivering resources
	that use such features.		that use such features.
	skipping to change at page 19, line 8		skipping to change at page 20, line 8
	SHOULD include an entity containing a list of resource		SHOULD include an entity containing a list of resource
	characteristics and location(s) from which the user or user agent can		characteristics and location(s) from which the user or user agent can
	choose the one most appropriate. The entity format is specified by		choose the one most appropriate. The entity format is specified by
	the media type given in the Content-Type header field. The origin		the media type given in the Content-Type header field. The origin
	server MUST create the resource before returning the 201 status code.		server MUST create the resource before returning the 201 status code.
	If the action cannot be carried out immediately, the server SHOULD		If the action cannot be carried out immediately, the server SHOULD
	respond with 202 (Accepted) response instead.		respond with 202 (Accepted) response instead.
	A 201 response MAY contain an ETag response header field indicating		A 201 response MAY contain an ETag response header field indicating
	the current value of the entity tag for the requested variant just		the current value of the entity tag for the requested variant just
	created, see Section 6.1 of [Part4].		created, see Section 7.1 of [Part4].
	9.2.3. 202 Accepted		9.2.3. 202 Accepted
	The request has been accepted for processing, but the processing has		The request has been accepted for processing, but the processing has
	not been completed. The request might or might not eventually be		not been completed. The request might or might not eventually be
	acted upon, as it might be disallowed when processing actually takes		acted upon, as it might be disallowed when processing actually takes
	place. There is no facility for re-sending a status code from an		place. There is no facility for re-sending a status code from an
	asynchronous operation such as this.		asynchronous operation such as this.
	The 202 response is intentionally non-committal. Its purpose is to		The 202 response is intentionally non-committal. Its purpose is to
	skipping to change at page 20, line 41		skipping to change at page 21, line 41
	Note: previous versions of this specification recommended a		Note: previous versions of this specification recommended a
	maximum of five redirections. Content developers should be aware		maximum of five redirections. Content developers should be aware
	that there might be clients that implement such a fixed		that there might be clients that implement such a fixed
	limitation.		limitation.
	9.3.1. 300 Multiple Choices		9.3.1. 300 Multiple Choices
	The requested resource corresponds to any one of a set of		The requested resource corresponds to any one of a set of
	representations, each with its own specific location, and agent-		representations, each with its own specific location, and agent-
	driven negotiation information (Section 4 of [Part3]) is being		driven negotiation information (Section 5 of [Part3]) is being
	provided so that the user (or user agent) can select a preferred		provided so that the user (or user agent) can select a preferred
	representation and redirect its request to that location.		representation and redirect its request to that location.
	Unless it was a HEAD request, the response SHOULD include an entity		Unless it was a HEAD request, the response SHOULD include an entity
	containing a list of resource characteristics and location(s) from		containing a list of resource characteristics and location(s) from
	which the user or user agent can choose the one most appropriate.		which the user or user agent can choose the one most appropriate.
	The entity format is specified by the media type given in the		The entity format is specified by the media type given in the
	Content-Type header field. Depending upon the format and the		Content-Type header field. Depending upon the format and the
	capabilities of the user agent, selection of the most appropriate		capabilities of the user agent, selection of the most appropriate
	choice MAY be performed automatically. However, this specification		choice MAY be performed automatically. However, this specification
	skipping to change at page 27, line 25		skipping to change at page 28, line 25
	buffers for reading or manipulating the Request-URI.		buffers for reading or manipulating the Request-URI.
	9.4.16. 415 Unsupported Media Type		9.4.16. 415 Unsupported Media Type
	The server is refusing to service the request because the entity of		The server is refusing to service the request because the entity of
	the request is in a format not supported by the requested resource		the request is in a format not supported by the requested resource
	for the requested method.		for the requested method.
	9.4.17. 416 Requested Range Not Satisfiable		9.4.17. 416 Requested Range Not Satisfiable
	The request included a Range request-header field (Section 5.4 of		The request included a Range request-header field (Section 6.4 of
	[Part5]) and none of the range-specifier values in this field overlap		[Part5]) and none of the range-specifier values in this field overlap
	the current extent of the selected resource.		the current extent of the selected resource.
	9.4.18. 417 Expectation Failed		9.4.18. 417 Expectation Failed
	The expectation given in an Expect request-header field (see		The expectation given in an Expect request-header field (see
	Section 10.2) could not be met by this server, or, if the server is a		Section 10.2) could not be met by this server, or, if the server is a
	proxy, the server has unambiguous evidence that the request could not		proxy, the server has unambiguous evidence that the request could not
	be met by the next-hop server.		be met by the next-hop server.
	skipping to change at page 28, line 43		skipping to change at page 29, line 43
	The server, while acting as a gateway or proxy, did not receive a		The server, while acting as a gateway or proxy, did not receive a
	timely response from the upstream server specified by the URI (e.g.		timely response from the upstream server specified by the URI (e.g.
	HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed		HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed
	to access in attempting to complete the request.		to access in attempting to complete the request.
	Note: Note to implementors: some deployed proxies are known to		Note: Note to implementors: some deployed proxies are known to
	return 400 or 500 when DNS lookups time out.		return 400 or 500 when DNS lookups time out.
	9.5.6. 505 HTTP Version Not Supported		9.5.6. 505 HTTP Version Not Supported
	The server does not support, or refuses to support, the HTTP protocol		The server does not support, or refuses to support, the protocol
	version that was used in the request message. The server is		version that was used in the request message. The server is
	indicating that it is unable or unwilling to complete the request		indicating that it is unable or unwilling to complete the request
	using the same major version as the client, as described in Section		using the same major version as the client, as described in Section
	3.1 of [Part1], other than with this error message. The response		3.1 of [Part1], other than with this error message. The response
	SHOULD contain an entity describing why that version is not supported		SHOULD contain an entity describing why that version is not supported
	and what other protocols are supported by that server.		and what other protocols are supported by that server.
	10. Header Field Definitions		10. Header Field Definitions
	This section defines the syntax and semantics of HTTP/1.1 header		This section defines the syntax and semantics of HTTP/1.1 header
	skipping to change at page 30, line 43		skipping to change at page 31, line 43
	10.3. From		10.3. From
	The From request-header field, if given, SHOULD contain an Internet		The From request-header field, if given, SHOULD contain an Internet
	e-mail address for the human user who controls the requesting user		e-mail address for the human user who controls the requesting user
	agent. The address SHOULD be machine-usable, as defined by "mailbox"		agent. The address SHOULD be machine-usable, as defined by "mailbox"
	in Section 3.4 of [RFC2822]:		in Section 3.4 of [RFC2822]:
	From = "From" ":" mailbox		From = "From" ":" mailbox
			mailbox = <mailbox, defined in [RFC2822], Section 3.4>
	An example is:		An example is:
	From: webmaster@example.org		From: webmaster@example.org
	This header field MAY be used for logging purposes and as a means for		This header field MAY be used for logging purposes and as a means for
	identifying the source of invalid or unwanted requests. It SHOULD		identifying the source of invalid or unwanted requests. It SHOULD
	NOT be used as an insecure form of access protection. The		NOT be used as an insecure form of access protection. The
	interpretation of this field is that the request is being performed		interpretation of this field is that the request is being performed
	on behalf of the person given, who accepts responsibility for the		on behalf of the person given, who accepts responsibility for the
	method performed. In particular, robot agents SHOULD include this		method performed. In particular, robot agents SHOULD include this
	skipping to change at page 31, line 35		skipping to change at page 32, line 37
	by the request. For 3xx responses, the location SHOULD indicate the		by the request. For 3xx responses, the location SHOULD indicate the
	server's preferred URI for automatic redirection to the resource.		server's preferred URI for automatic redirection to the resource.
	The field value consists of a single absolute URI.		The field value consists of a single absolute URI.
	Location = "Location" ":" absoluteURI [ "#" fragment ]		Location = "Location" ":" absoluteURI [ "#" fragment ]
	An example is:		An example is:
	Location: http://www.example.org/pub/WWW/People.html		Location: http://www.example.org/pub/WWW/People.html
	Note: The Content-Location header field (Section 5.7 of [Part3])		Note: The Content-Location header field (Section 6.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 request. It is		original location of the entity enclosed in the request. 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.
	There are circumstances in which a fragment identifier in a Location		There are circumstances in which a fragment identifier in a Location
	URL would not be appropriate:		URL 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 URL for the entire created resource.		header specifies the URL for the entire created resource.
	skipping to change at page 33, line 19		skipping to change at page 34, line 19
	The Retry-After response-header field can be used with a 503 (Service		The Retry-After response-header field can be used with a 503 (Service
	Unavailable) response to indicate how long the service is expected to		Unavailable) response to indicate how long the service is expected to
	be unavailable to the requesting client. This field MAY also be used		be unavailable to the requesting client. This field MAY also be used
	with any 3xx (Redirection) response to indicate the minimum time the		with any 3xx (Redirection) response to indicate the minimum time the
	user-agent is asked wait before issuing the redirected request. The		user-agent is asked wait before issuing the redirected request. The
	value of this field can be either an HTTP-date or an integer number		value of this field can be either an HTTP-date or an integer number
	of seconds (in decimal) after the time of the response.		of seconds (in decimal) after the time of the response.
	Retry-After = "Retry-After" ":" ( HTTP-date | delta-seconds )		Retry-After = "Retry-After" ":" ( HTTP-date | delta-seconds )
			Time spans are non-negative decimal integers, representing time in
			seconds.
			delta-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.
	10.8. Server		10.8. Server
	The Server response-header field contains information about the		The Server response-header field contains information about the
	software used by the origin server to handle the request. The field		software used by the origin server to handle the request. The field
	can contain multiple product tokens (Section 2) and comments		can contain multiple product tokens (Section 3.5 of [Part1]) and
	identifying the server and any significant subproducts. The product		comments identifying the server and any significant subproducts. The
	tokens are listed in order of their significance for identifying the		product tokens are listed in order of their significance for
	application.		identifying the application.
	Server = "Server" ":" 1*( product | comment )		Server = "Server" ":" 1*( product | comment )
	Example:		Example:
	Server: CERN/3.0 libwww/2.17		Server: CERN/3.0 libwww/2.17
	If the response is being forwarded through a proxy, the proxy		If the response is being forwarded through a proxy, the proxy
	application MUST NOT modify the Server response-header. Instead, it		application MUST NOT modify the Server response-header. Instead, it
	MUST include a Via field (as described in Section 8.9 of [Part1]).		MUST include a Via field (as described in Section 8.9 of [Part1]).
	skipping to change at page 34, line 13		skipping to change at page 35, line 15
	option.		option.
	10.9. User-Agent		10.9. User-Agent
	The User-Agent request-header field contains information about the		The User-Agent request-header field contains information about the
	user agent originating the request. This is for statistical		user agent originating the request. This is for statistical
	purposes, the tracing of protocol violations, and automated		purposes, the tracing of protocol violations, and automated
	recognition of user agents for the sake of tailoring responses to		recognition of user agents for the sake of tailoring responses to
	avoid particular user agent limitations. User agents SHOULD include		avoid particular user agent limitations. User agents SHOULD include
	this field with requests. The field can contain multiple product		this field with requests. The field can contain multiple product
	tokens (Section 2) and comments identifying the agent and any		tokens (Section 3.5 of [Part1]) and comments identifying the agent
	subproducts which form a significant part of the user agent. By		and any subproducts which form a significant part of the user agent.
	convention, the product tokens are listed in order of their		By convention, the product tokens are listed in order of their
	significance for identifying the application.		significance for identifying the application.
	User-Agent = "User-Agent" ":" 1*( product | comment )		User-Agent = "User-Agent" ":" 1*( product | comment )
	Example:		Example:
	User-Agent: CERN-LineMode/2.15 libwww/2.17b3		User-Agent: CERN-LineMode/2.15 libwww/2.17b3
	11. IANA Considerations		11. IANA Considerations
	TBD.		[[anchor1: TBD.]]
	12. Security Considerations		12. Security Considerations
	This section is meant to inform application developers, information		This section is meant to inform application developers, information
	providers, and users of the security limitations in HTTP/1.1 as		providers, and users of the security limitations in HTTP/1.1 as
	described by this document. The discussion does not include		described by this document. The discussion does not include
	definitive solutions to the problems revealed, though it does make		definitive solutions to the problems revealed, though it does make
	some suggestions for reducing security risks.		some suggestions for reducing security risks.
	12.1. Transfer of Sensitive Information		12.1. Transfer of Sensitive Information
	skipping to change at page 35, line 35		skipping to change at page 36, line 37
	We suggest, though do not require, that a convenient toggle interface		We suggest, though do not require, that a convenient toggle interface
	be provided for the user to enable or disable the sending of From and		be provided for the user to enable or disable the sending of From and
	Referer information.		Referer information.
	The User-Agent (Section 10.9) or Server (Section 10.8) header fields		The User-Agent (Section 10.9) or Server (Section 10.8) header fields
	can sometimes be used to determine that a specific client or server		can sometimes be used to determine that a specific client or server
	have a particular security hole which might be exploited.		have a particular security hole which might be exploited.
	Unfortunately, this same information is often used for other valuable		Unfortunately, this same information is often used for other valuable
	purposes for which HTTP currently has no better mechanism.		purposes for which HTTP currently has no better mechanism.
	12.2. Encoding Sensitive Information in URI's		12.2. Encoding Sensitive Information in URIs
	Because the source of a link might be private information or might		Because the source of a link might be private information or might
	reveal an otherwise private information source, it is strongly		reveal an otherwise private information source, it is strongly
	recommended that the user be able to select whether or not the		recommended that the user be able to select whether or not the
	Referer field is sent. For example, a browser client could have a		Referer field is sent. For example, a browser client could have a
	toggle switch for browsing openly/anonymously, which would		toggle switch for browsing openly/anonymously, which would
	respectively enable/disable the sending of Referer and From		respectively enable/disable the sending of Referer and From
	information.		information.
	Clients SHOULD NOT include a Referer header field in a (non-secure)		Clients SHOULD NOT include a Referer header field in a (non-secure)
	HTTP request if the referring page was transferred with a secure		HTTP request if the referring page was transferred with a secure
	protocol.		protocol.
	Authors of services which use the HTTP protocol SHOULD NOT use GET		Authors of services should not use GET-based forms for the submission
	based forms for the submission of sensitive data, because this will		of sensitive data because that data will be encoded in the Request-
	cause this data to be encoded in the Request-URI. Many existing		URI. Many existing servers, proxies, and user agents log or display
	servers, proxies, and user agents will log the request URI in some		the Request-URI in places where it might be visible to third parties.
	place where it might be visible to third parties. Servers can use		Such services can use POST-based form submission instead.
	POST-based form submission instead
	12.3. Location Headers and Spoofing		12.3. Location Headers and Spoofing
	If a single server supports multiple organizations that do not trust		If a single server supports multiple organizations that do not trust
	one another, then it MUST check the values of Location and Content-		one another, then it MUST check the values of Location and Content-
	Location headers in responses that are generated under control of		Location headers in responses that are generated under control of
	said organizations to make sure that they do not attempt to		said organizations to make sure that they do not attempt to
	invalidate resources over which they have no authority.		invalidate resources over which they have no authority.
	13. Acknowledgments		13. Acknowledgments
	14. References		14. References
	14.1. Normative References		14.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-01		and Message Parsing", draft-ietf-httpbis-p1-messaging-02
	(work in progress), January 2008.		(work in progress), February 2008.
	[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-01		and Content Negotiation", draft-ietf-httpbis-p3-payload-02
	(work in progress), January 2008.		(work in progress), February 2008.
	[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-01 (work in		Requests", draft-ietf-httpbis-p4-conditional-02 (work in
	progress), January 2008.		progress), February 2008.
	[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-01 (work		Partial Responses", draft-ietf-httpbis-p5-range-02 (work
	in progress), January 2008.		in progress), February 2008.
	[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.,
	and J. Reschke, Ed., "HTTP/1.1, part 6: Caching",		and J. Reschke, Ed., "HTTP/1.1, part 6: Caching",
	draft-ietf-httpbis-p6-cache-01 (work in progress),		draft-ietf-httpbis-p6-cache-02 (work in progress),
	January 2008.		February 2008.
	[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-01 (work in progress),		draft-ietf-httpbis-p7-auth-02 (work in progress),
	January 2008.		February 2008.
	[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.
	14.2. Informative References		14.2. Informative References
	[Luo1998] Luotonen, A., "Tunneling TCP based protocols through Web		[Luo1998] Luotonen, A., "Tunneling TCP based protocols through Web
	proxy servers", draft-luotonen-web-proxy-tunneling-01		proxy servers", draft-luotonen-web-proxy-tunneling-01
	(work in progress), August 1998.		(work in progress), August 1998.
	skipping to change at page 39, line 46		skipping to change at page 41, line 5
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/65>:		o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/65>:
	"Informative references"		"Informative references"
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/84>: "Redundant		o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/84>: "Redundant
	cross-references"		cross-references"
	Other changes:		Other changes:
	o Move definitions of 304 and 412 condition codes to [Part4]		o Move definitions of 304 and 412 condition codes to [Part4]
			B.3. Since draft-ietf-httpbis-p2-semantics-01
			Closed issues:
			o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/21>: "PUT side
			effects"
			o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/91>: "Duplicate
			Host header requirements"
			Ongoing work on ABNF conversion
			(<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36>):
			o Move "Product Tokens" section (back) into Part 1, as "token" is
			used in the definition of the Upgrade header.
			o Add explicit references to BNF syntax and rules imported from
			other parts of the specification.
			o Copy definition of delta-seconds from Part6 instead of referencing
			it.
	Index		Index
	1		1
	100 Continue (status code) 17		100 Continue (status code) 18
	101 Switching Protocols (status code) 18		101 Switching Protocols (status code) 19
	2		2
	200 OK (status code) 18		200 OK (status code) 19
	201 Created (status code) 18		201 Created (status code) 19
	202 Accepted (status code) 19		202 Accepted (status code) 20
	203 Non-Authoritative Information (status code) 19		203 Non-Authoritative Information (status code) 20
	204 No Content (status code) 19		204 No Content (status code) 20
	205 Reset Content (status code) 20		205 Reset Content (status code) 21
	206 Partial Content (status code) 20		206 Partial Content (status code) 21
	3		3
	300 Multiple Choices (status code) 20		300 Multiple Choices (status code) 21
	301 Moved Permanently (status code) 21		301 Moved Permanently (status code) 22
	302 Found (status code) 21		302 Found (status code) 22
	303 See Other (status code) 22		303 See Other (status code) 23
	304 Not Modified (status code) 22		304 Not Modified (status code) 23
	305 Use Proxy (status code) 22		305 Use Proxy (status code) 23
	306 (Unused) (status code) 23		306 (Unused) (status code) 24
	307 Temporary Redirect (status code) 23		307 Temporary Redirect (status code) 24
	4		4
	400 Bad Request (status code) 24		400 Bad Request (status code) 25
	401 Unauthorized (status code) 24		401 Unauthorized (status code) 25
	402 Payment Required (status code) 24		402 Payment Required (status code) 25
	403 Forbidden (status code) 24		403 Forbidden (status code) 25
	404 Not Found (status code) 24		404 Not Found (status code) 25
	405 Method Not Allowed (status code) 24		405 Method Not Allowed (status code) 25
	406 Not Acceptable (status code) 24		406 Not Acceptable (status code) 25
	407 Proxy Authentication Required (status code) 25		407 Proxy Authentication Required (status code) 26
	408 Request Timeout (status code) 25		408 Request Timeout (status code) 26
	409 Conflict (status code) 25		409 Conflict (status code) 26
	410 Gone (status code) 26		410 Gone (status code) 27
	411 Length Required (status code) 26		411 Length Required (status code) 27
	412 Precondition Failed (status code) 26		412 Precondition Failed (status code) 27
	413 Request Entity Too Large (status code) 26		413 Request Entity Too Large (status code) 27
	414 Request-URI Too Long (status code) 27		414 Request-URI Too Long (status code) 28
	415 Unsupported Media Type (status code) 27		415 Unsupported Media Type (status code) 28
	416 Requested Range Not Satisfiable (status code) 27		416 Requested Range Not Satisfiable (status code) 28
	417 Expectation Failed (status code) 27		417 Expectation Failed (status code) 28
	5		5
	500 Internal Server Error (status code) 27		500 Internal Server Error (status code) 28
	501 Not Implemented (status code) 28		501 Not Implemented (status code) 29
	502 Bad Gateway (status code) 28		502 Bad Gateway (status code) 29
	503 Service Unavailable (status code) 28		503 Service Unavailable (status code) 29
	504 Gateway Timeout (status code) 28		504 Gateway Timeout (status code) 29
	505 HTTP Version Not Supported (status code) 28		505 HTTP Version Not Supported (status code) 29
	A		A
	Allow header 29		Allow header 30
	C		C
	CONNECT method 17		CONNECT method 18
	D		D
	DELETE method 16		DELETE method 17
	E		E
	Expect header 29		Expect header 30
	F		F
	From header 30		From header 31
	G		G
	GET method 13		GET method 14
	Grammar		Grammar
	Allow 29		Allow 30
	Expect 29		delta-seconds 34
	expect-params 29		Expect 30
	expectation 29		expect-params 30
	expectation-extension 29		expectation 30
	extension-code 9		expectation-extension 30
	extension-method 7		extension-code 10
	From 30		extension-method 8
	Location 31		From 31
	Max-Forwards 32		Location 32
	Method 7		Max-Forwards 33
	product 6		Method 8
	product-version 6		Reason-Phrase 10
	Reason-Phrase 9		Referer 33
	Referer 32		request-header 9
	request-header 8		response-header 11
	response-header 10		Retry-After 34
	Retry-After 33		Server 34
	Server 33		Status-Code 10
	Status-Code 9		User-Agent 35
	User-Agent 34
	H		H
	HEAD method 13		HEAD method 14
	Headers		Headers
	Allow 29		Allow 30
	Expect 29		Expect 30
	From 30		From 31
	Location 31		Location 32
	Max-Forwards 32		Max-Forwards 33
	Referer 32		Referer 33
	Retry-After 33		Retry-After 34
	Server 33		Server 34
	User-Agent 34		User-Agent 35
	L		L
	LINK method 38		LINK method 39
	Location header 31		Location header 32
	M		M
	Max-Forwards header 32		Max-Forwards header 33
	Methods		Methods
	CONNECT 17		CONNECT 18
	DELETE 16		DELETE 17
	GET 13		GET 14
	HEAD 13		HEAD 14
	LINK 38		LINK 39
	OPTIONS 12		OPTIONS 13
	PATCH 38		PATCH 39
	POST 14		POST 15
	PUT 15		PUT 16
	TRACE 16		TRACE 17
	UNLINK 38		UNLINK 39
	O		O
	OPTIONS method 12		OPTIONS method 13
	P		P
	PATCH method 38		PATCH method 39
	POST method 14		POST method 15
	PUT method 15		PUT method 16
	R		R
	Referer header 32		Referer header 33
	Retry-After header 33		Retry-After header 34
	S		S
	Server header 33		Server header 34
	Status Codes		Status Codes
	100 Continue 17		100 Continue 18
	101 Switching Protocols 18		101 Switching Protocols 19
	200 OK 18		200 OK 19
	201 Created 18		201 Created 19
	202 Accepted 19		202 Accepted 20
	203 Non-Authoritative Information 19		203 Non-Authoritative Information 20
	204 No Content 19		204 No Content 20
	205 Reset Content 20		205 Reset Content 21
	206 Partial Content 20		206 Partial Content 21
	300 Multiple Choices 20		300 Multiple Choices 21
	301 Moved Permanently 21		301 Moved Permanently 22
	302 Found 21		302 Found 22
	303 See Other 22		303 See Other 23
	304 Not Modified 22		304 Not Modified 23
	305 Use Proxy 22		305 Use Proxy 23
	306 (Unused) 23		306 (Unused) 24
	307 Temporary Redirect 23		307 Temporary Redirect 24
	400 Bad Request 24		400 Bad Request 25
	401 Unauthorized 24		401 Unauthorized 25
	402 Payment Required 24		402 Payment Required 25
	403 Forbidden 24		403 Forbidden 25
	404 Not Found 24		404 Not Found 25
	405 Method Not Allowed 24		405 Method Not Allowed 25
	406 Not Acceptable 24		406 Not Acceptable 25
	407 Proxy Authentication Required 25		407 Proxy Authentication Required 26
	408 Request Timeout 25		408 Request Timeout 26
	409 Conflict 25		409 Conflict 26
	410 Gone 26		410 Gone 27
	411 Length Required 26		411 Length Required 27
	412 Precondition Failed 26		412 Precondition Failed 27
	413 Request Entity Too Large 26		413 Request Entity Too Large 27
	414 Request-URI Too Long 27		414 Request-URI Too Long 28
	415 Unsupported Media Type 27		415 Unsupported Media Type 28
	416 Requested Range Not Satisfiable 27		416 Requested Range Not Satisfiable 28
	417 Expectation Failed 27		417 Expectation Failed 28
	500 Internal Server Error 27		500 Internal Server Error 28
	501 Not Implemented 28		501 Not Implemented 29
	502 Bad Gateway 28		502 Bad Gateway 29
	503 Service Unavailable 28		503 Service Unavailable 29
	504 Gateway Timeout 28		504 Gateway Timeout 29
	505 HTTP Version Not Supported 28		505 HTTP Version Not Supported 29
	T		T
	TRACE method 16		TRACE method 17
	U		U
	UNLINK method 38		UNLINK method 39
	User-Agent header 34		User-Agent header 35
	Authors' Addresses		Authors' Addresses
	Roy T. Fielding (editor)		Roy T. Fielding (editor)
	Day Software		Day Software
	23 Corporate Plaza DR, Suite 280		23 Corporate Plaza DR, Suite 280
	Newport Beach, CA 92660		Newport Beach, CA 92660
	USA		USA
	Phone: +1-949-706-5300		Phone: +1-949-706-5300
End of changes. 65 change blocks.
	323 lines changed or deleted		378 lines changed or added
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/