draft-ietf-httpbis-p1-messaging-19.txt		draft-ietf-httpbis-p1-messaging-latest.txt
	HTTPbis Working Group R. Fielding, Ed.		HTTPbis Working Group R. Fielding, Ed.
	Internet-Draft Adobe		Internet-Draft Adobe
	Obsoletes: 2145,2616 (if approved) Y. Lafon, Ed.		Obsoletes: 2145,2616 (if approved) Y. Lafon, Ed.
	Updates: 2817 (if approved) W3C		Updates: 2817 (if approved) W3C
	Intended status: Standards Track J. Reschke, Ed.		Intended status: Standards Track J. Reschke, Ed.
	Expires: September 13, 2012 greenbytes		Expires: November 20, 2012 greenbytes
	March 12, 2012		May 19, 2012
	HTTP/1.1, part 1: URIs, Connections, and Message Parsing		HTTP/1.1, part 1: URIs, Connections, and Message Parsing
	draft-ietf-httpbis-p1-messaging-19		draft-ietf-httpbis-p1-messaging-latest
	Abstract		Abstract
	The Hypertext Transfer Protocol (HTTP) is an application-level		The Hypertext Transfer Protocol (HTTP) is an application-level
	protocol for distributed, collaborative, hypertext information		protocol for distributed, collaborative, hypertext information
	systems. HTTP has been in use by the World Wide Web global		systems. HTTP has been in use by the World Wide Web global
	information initiative since 1990. This document is Part 1 of the		information initiative since 1990. This document is Part 1 of the
	seven-part specification that defines the protocol referred to as		seven-part specification that defines the protocol referred to as
	"HTTP/1.1" and, taken together, obsoletes RFC 2616 and moves it to		"HTTP/1.1" and, taken together, obsoletes RFC 2616 and moves it to
	historic status, along with its predecessor RFC 2068.		historic status, along with its predecessor RFC 2068.
	skipping to change at page 1, line 45		skipping to change at page 1, line 45
	Discussion of this draft should take place on the HTTPBIS working		Discussion of this draft should take place on the HTTPBIS working
	group mailing list (ietf-http-wg@w3.org), which is archived at		group 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 C.20.		The changes in this draft are summarized in Appendix C.21.
	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 September 13, 2012.		This Internet-Draft will expire on November 20, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 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 5, line 16		skipping to change at page 5, line 16
	C.11. Since draft-ietf-httpbis-p1-messaging-09 . . . . . . . . . 83		C.11. Since draft-ietf-httpbis-p1-messaging-09 . . . . . . . . . 83
	C.12. Since draft-ietf-httpbis-p1-messaging-10 . . . . . . . . . 83		C.12. Since draft-ietf-httpbis-p1-messaging-10 . . . . . . . . . 83
	C.13. Since draft-ietf-httpbis-p1-messaging-11 . . . . . . . . . 84		C.13. Since draft-ietf-httpbis-p1-messaging-11 . . . . . . . . . 84
	C.14. Since draft-ietf-httpbis-p1-messaging-12 . . . . . . . . . 84		C.14. Since draft-ietf-httpbis-p1-messaging-12 . . . . . . . . . 84
	C.15. Since draft-ietf-httpbis-p1-messaging-13 . . . . . . . . . 85		C.15. Since draft-ietf-httpbis-p1-messaging-13 . . . . . . . . . 85
	C.16. Since draft-ietf-httpbis-p1-messaging-14 . . . . . . . . . 85		C.16. Since draft-ietf-httpbis-p1-messaging-14 . . . . . . . . . 85
	C.17. Since draft-ietf-httpbis-p1-messaging-15 . . . . . . . . . 85		C.17. Since draft-ietf-httpbis-p1-messaging-15 . . . . . . . . . 85
	C.18. Since draft-ietf-httpbis-p1-messaging-16 . . . . . . . . . 86		C.18. Since draft-ietf-httpbis-p1-messaging-16 . . . . . . . . . 86
	C.19. Since draft-ietf-httpbis-p1-messaging-17 . . . . . . . . . 86		C.19. Since draft-ietf-httpbis-p1-messaging-17 . . . . . . . . . 86
	C.20. Since draft-ietf-httpbis-p1-messaging-18 . . . . . . . . . 87		C.20. Since draft-ietf-httpbis-p1-messaging-18 . . . . . . . . . 87
			C.21. Since draft-ietf-httpbis-p1-messaging-19 . . . . . . . . . 87
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87		Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
	1. Introduction		1. Introduction
	The Hypertext Transfer Protocol (HTTP) is an application-level		The Hypertext Transfer Protocol (HTTP) is an application-level
	request/response protocol that uses extensible semantics and MIME-		request/response protocol that uses extensible semantics and MIME-
	like message payloads for flexible interaction with network-based		like message payloads for flexible interaction with network-based
	hypertext information systems. HTTP relies upon the Uniform Resource		hypertext information systems. HTTP relies upon the Uniform Resource
	Identifier (URI) standard [RFC3986] to indicate the target resource		Identifier (URI) standard [RFC3986] to indicate the target resource
	(Section 5.1) and relationships between resources. Messages are		(Section 5.1) and relationships between resources. Messages are
	passed in a format similar to that used by Internet mail [RFC5322]		passed in a format similar to that used by Internet mail [RFC5322]
	and the Multipurpose Internet Mail Extensions (MIME) [RFC2045] (see		and the Multipurpose Internet Mail Extensions (MIME) [RFC2045] (see
	Appendix A of [Part3] for the differences between HTTP and MIME		Appendix A of [Part2] for the differences between HTTP and MIME
	messages).		messages).
	HTTP is a generic interface protocol for information systems. It is		HTTP is a generic interface protocol for information systems. It is
	designed to hide the details of how a service is implemented by		designed to hide the details of how a service is implemented by
	presenting a uniform interface to clients that is independent of the		presenting a uniform interface to clients that is independent of the
	types of resources provided. Likewise, servers do not need to be		types of resources provided. Likewise, servers do not need to be
	aware of each client's purpose: an HTTP request can be considered in		aware of each client's purpose: an HTTP request can be considered in
	isolation rather than being associated with a specific type of client		isolation rather than being associated with a specific type of client
	or a predetermined sequence of application steps. The result is a		or a predetermined sequence of application steps. The result is a
	protocol that can be used effectively in many different contexts and		protocol that can be used effectively in many different contexts and
	skipping to change at page 10, line 52		skipping to change at page 10, line 52
	that would be significant to the original sender or potentially		that would be significant to the original sender or potentially
	significant to downstream recipients). For example, a transforming		significant to downstream recipients). For example, a transforming
	proxy might be acting as a shared annotation server (modifying		proxy might be acting as a shared annotation server (modifying
	responses to include references to a local annotation database), a		responses to include references to a local annotation database), a
	malware filter, a format transcoder, or an intranet-to-Internet		malware filter, a format transcoder, or an intranet-to-Internet
	privacy filter. Such transformations are presumed to be desired by		privacy filter. Such transformations are presumed to be desired by
	the client (or client organization) that selected the proxy and are		the client (or client organization) that selected the proxy and are
	beyond the scope of this specification. However, when a proxy is not		beyond the scope of this specification. However, when a proxy is not
	intended to transform a given message, we use the term "non-		intended to transform a given message, we use the term "non-
	transforming proxy" to target requirements that preserve HTTP message		transforming proxy" to target requirements that preserve HTTP message
	semantics. See Section 7.2.4 of [Part2] and Section 3.6 of [Part6]		semantics. See Section 4.4.4 of [Part2] and Section 3.6 of [Part6]
	for status and warning codes related to transformations.		for status and warning codes related to transformations.
	A "gateway" (a.k.a., "reverse proxy") is a receiving agent that acts		A "gateway" (a.k.a., "reverse proxy") is a receiving agent that acts
	as a layer above some other server(s) and translates the received		as a layer above some other server(s) and translates the received
	requests to the underlying server's protocol. Gateways are often		requests to the underlying server's protocol. Gateways are often
	used to encapsulate legacy or untrusted information services, to		used to encapsulate legacy or untrusted information services, to
	improve server performance through "accelerator" caching, and to		improve server performance through "accelerator" caching, and to
	enable partitioning or load-balancing of HTTP services across		enable partitioning or load-balancing of HTTP services across
	multiple machines.		multiple machines.
	skipping to change at page 21, line 7		skipping to change at page 21, line 7
	directly instead of properly percent-encoding the disallowed		directly instead of properly percent-encoding the disallowed
	characters. Recipients of an invalid request-line SHOULD respond		characters. Recipients of an invalid request-line SHOULD respond
	with either a 400 (Bad Request) error or a 301 (Moved Permanently)		with either a 400 (Bad Request) error or a 301 (Moved Permanently)
	redirect with the request-target properly encoded. Recipients SHOULD		redirect with the request-target properly encoded. Recipients SHOULD
	NOT attempt to autocorrect and then process the request without a		NOT attempt to autocorrect and then process the request without a
	redirect, since the invalid request-line might be deliberately		redirect, since the invalid request-line might be deliberately
	crafted to bypass security filters along the request chain.		crafted to bypass security filters along the request chain.
	HTTP does not place a pre-defined limit on the length of a request-		HTTP does not place a pre-defined limit on the length of a request-
	line. A server that receives a method longer than any that it		line. A server that receives a method longer than any that it
	implements SHOULD respond with either a 404 (Not Allowed), if it is		implements SHOULD respond with either a 405 (Not Allowed), if it is
	an origin server, or a 501 (Not Implemented) status code. A server		an origin server, or a 501 (Not Implemented) status code. A server
	MUST be prepared to receive URIs of unbounded length and respond with		MUST be prepared to receive URIs of unbounded length and respond with
	the 414 (URI Too Long) status code if the received request-target		the 414 (URI Too Long) status code if the received request-target
	would be longer than the server wishes to handle (see Section 7.4.12		would be longer than the server wishes to handle (see Section 4.6.12
	of [Part2]).		of [Part2]).
	Various ad-hoc limitations on request-line length are found in		Various ad-hoc limitations on request-line length are found in
	practice. It is RECOMMENDED that all HTTP senders and recipients		practice. It is RECOMMENDED that all HTTP senders and recipients
	support, at a minimum, request-line lengths of up to 8000 octets.		support, at a minimum, request-line lengths of up to 8000 octets.
	3.1.2. Status Line		3.1.2. Status Line
	The first line of a response message is the status-line, consisting		The first line of a response message is the status-line, consisting
	of the protocol version, a space (SP), the status code, another		of the protocol version, a space (SP), the status code, another
	skipping to change at page 22, line 15		skipping to change at page 22, line 15
	header-field = field-name ":" OWS field-value BWS		header-field = field-name ":" OWS field-value BWS
	field-name = token		field-name = token
	field-value = *( field-content / obs-fold )		field-value = *( field-content / obs-fold )
	field-content = *( HTAB / SP / VCHAR / obs-text )		field-content = *( HTAB / SP / VCHAR / obs-text )
	obs-fold = CRLF ( SP / HTAB )		obs-fold = CRLF ( SP / HTAB )
	; obsolete line folding		; obsolete line folding
	; see Section 3.2.2		; see Section 3.2.2
	The field-name token labels the corresponding field-value as having		The field-name token labels the corresponding field-value as having
	the semantics defined by that header field. For example, the Date		the semantics defined by that header field. For example, the Date
	header field is defined in Section 10.2 of [Part2] as containing the		header field is defined in Section 9.10 of [Part2] as containing the
	origination timestamp for the message in which it appears.		origination timestamp for the message in which it appears.
	HTTP header fields are fully extensible: there is no limit on the		HTTP header fields are fully extensible: there is no limit on the
	introduction of new field names, each presumably defining new		introduction of new field names, each presumably defining new
	semantics, or on the number of header fields used in a given message.		semantics, or on the number of header fields used in a given message.
	Existing fields are defined in each part of this specification and in		Existing fields are defined in each part of this specification and in
	many other specifications outside the standards process. New header		many other specifications outside the standards process. New header
	fields can be introduced without changing the protocol version if		fields can be introduced without changing the protocol version if
	their defined semantics allow them to be safely ignored by recipients		their defined semantics allow them to be safely ignored by recipients
	that do not recognize them.		that do not recognize them.
	skipping to change at page 28, line 42		skipping to change at page 28, line 42
	indicates that the payload body has been compressed using the gzip		indicates that the payload body has been compressed using the gzip
	coding and then chunked using the chunked coding while forming the		coding and then chunked using the chunked coding while forming the
	message body.		message body.
	If more than one Transfer-Encoding header field is present in a		If more than one Transfer-Encoding header field is present in a
	message, the multiple field-values MUST be combined into one field-		message, the multiple field-values MUST be combined into one field-
	value, according to the algorithm defined in Section 3.2, before		value, according to the algorithm defined in Section 3.2, before
	determining the message body length.		determining the message body length.
	Unlike Content-Encoding (Section 2.2 of [Part3]), Transfer-Encoding		Unlike Content-Encoding (Section 5.4 of [Part2]), Transfer-Encoding
	is a property of the message, not of the payload, and thus MAY be		is a property of the message, not of the payload, and thus MAY be
	added or removed by any implementation along the request/response		added or removed by any implementation along the request/response
	chain. Additional information about the encoding parameters MAY be		chain. Additional information about the encoding parameters MAY be
	provided by other header fields not defined by this specification.		provided by other header fields not defined by this specification.
	Transfer-Encoding MAY be sent in a response to a HEAD request or in a		Transfer-Encoding MAY be sent in a response to a HEAD request or in a
	304 response to a GET request, neither of which includes a message		304 response to a GET request, neither of which includes a message
	body, to indicate that the origin server would have applied a		body, to indicate that the origin server would have applied a
	transfer coding to the message body if the request had been an		transfer coding to the message body if the request had been an
	unconditional GET. This indication is not required, however, because		unconditional GET. This indication is not required, however, because
	skipping to change at page 33, line 4		skipping to change at page 33, line 4
	if the zero-sized chunk that terminates the encoding has not been		if the zero-sized chunk that terminates the encoding has not been
	received. A message that uses a valid Content-Length is incomplete		received. A message that uses a valid Content-Length is incomplete
	if the size of the message body received (in octets) is less than the		if the size of the message body received (in octets) is less than the
	value given by Content-Length. A response that has neither chunked		value given by Content-Length. A response that has neither chunked
	transfer encoding nor Content-Length is terminated by closure of the		transfer encoding nor Content-Length is terminated by closure of the
	connection, and thus is considered complete regardless of the number		connection, and thus is considered complete regardless of the number
	of message body octets received, provided that the header block was		of message body octets received, provided that the header block was
	received intact.		received intact.
	A user agent MUST NOT render an incomplete response message body as		A user agent MUST NOT render an incomplete response message body as
	if it were complete (i.e., some indication must be given to the user		if it were complete (i.e., some indication needs to be given to the
	that an error occurred). Cache requirements for incomplete responses		user that an error occurred). Cache requirements for incomplete
	are defined in Section 2.1 of [Part6].		responses are defined in Section 2.1 of [Part6].
	A server MUST read the entire request message body or close the		A server MUST read the entire request message body or close the
	connection after sending its response, since otherwise the remaining		connection after sending its response, since otherwise the remaining
	data on a persistent connection would be misinterpreted as the next		data on a persistent connection would be misinterpreted as the next
	request. Likewise, a client MUST read the entire response message		request. Likewise, a client MUST read the entire response message
	body if it intends to reuse the same connection for a subsequent		body if it intends to reuse the same connection for a subsequent
	request. Pipelining multiple requests on a connection is described		request. Pipelining multiple requests on a connection is described
	in Section 6.3.2.2.		in Section 6.3.2.2.
	3.5. Message Parsing Robustness		3.5. Message Parsing Robustness
	skipping to change at page 38, line 16		skipping to change at page 38, line 16
	transfer-coding with the highest non-zero qvalue is preferred.		transfer-coding with the highest non-zero qvalue is preferred.
	The "chunked" transfer-coding always has a qvalue of 1.		The "chunked" transfer-coding always has a qvalue of 1.
	If the TE field-value is empty or if no TE field is present, the only		If the TE field-value is empty or if no TE field is present, the only
	acceptable transfer-coding is "chunked". A message with no transfer-		acceptable transfer-coding is "chunked". A message with no transfer-
	coding is always acceptable.		coding is always acceptable.
	4.3.1. Quality Values		4.3.1. Quality Values
	Both transfer codings (TE request header field, Section 4.3) and		Both transfer codings (TE request header field, Section 4.3) and
	content negotiation (Section 5 of [Part3]) use short "floating point"		content negotiation (Section 8 of [Part2]) use short "floating point"
	numbers to indicate the relative importance ("weight") of various		numbers to indicate the relative importance ("weight") of various
	negotiable parameters. A weight is normalized to a real number in		negotiable parameters. A weight is normalized to a real number in
	the range 0 through 1, where 0 is the minimum and 1 the maximum		the range 0 through 1, where 0 is the minimum and 1 the maximum
	value. If a parameter has a quality value of 0, then content with		value. If a parameter has a quality value of 0, then content with
	this parameter is "not acceptable" for the client. HTTP/1.1		this parameter is "not acceptable" for the client. HTTP/1.1
	applications MUST NOT generate more than three digits after the		applications MUST NOT generate more than three digits after the
	decimal point. User configuration of these values SHOULD also be		decimal point. User configuration of these values SHOULD also be
	limited in this fashion.		limited in this fashion.
	qvalue = ( "0" [ "." 0*3DIGIT ] )		qvalue = ( "0" [ "." 0*3DIGIT ] )
	skipping to change at page 41, line 31		skipping to change at page 41, line 31
	An example absolute-form of request-line would be:		An example absolute-form of request-line would be:
	GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1		GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1
	To allow for transition to the absolute-form for all requests in some		To allow for transition to the absolute-form for all requests in some
	future version of HTTP, HTTP/1.1 servers MUST accept the absolute-		future version of HTTP, HTTP/1.1 servers MUST accept the absolute-
	form in requests, even though HTTP/1.1 clients will only send them in		form in requests, even though HTTP/1.1 clients will only send them in
	requests to proxies.		requests to proxies.
	The authority-form of request-target is only used for CONNECT		The authority-form of request-target is only used for CONNECT
	requests (Section 6.9 of [Part2]). When making a CONNECT request to		requests (Section 2.3.8 of [Part2]). When making a CONNECT request
	establish a tunnel through one or more proxies, a client MUST send		to establish a tunnel through one or more proxies, a client MUST send
	only the target URI's authority component (excluding any userinfo) as		only the target URI's authority component (excluding any userinfo) as
	the request-target. For example,		the request-target. For example,
	CONNECT www.example.com:80 HTTP/1.1		CONNECT www.example.com:80 HTTP/1.1
	The asterisk-form of request-target is only used for a server-wide		The asterisk-form of request-target is only used for a server-wide
	OPTIONS request (Section 6.2 of [Part2]). When a client wishes to		OPTIONS request (Section 2.3.1 of [Part2]). When a client wishes to
	request OPTIONS for the server as a whole, as opposed to a specific		request OPTIONS for the server as a whole, as opposed to a specific
	named resource of that server, the client MUST send only "*" (%x2A)		named resource of that server, the client MUST send only "*" (%x2A)
	as the request-target. For example,		as the request-target. For example,
	OPTIONS * HTTP/1.1		OPTIONS * HTTP/1.1
	If a proxy receives an OPTIONS request with an absolute-form of		If a proxy receives an OPTIONS request with an absolute-form of
	request-target in which the URI has an empty path and no query		request-target in which the URI has an empty path and no query
	component, then the last proxy on the request chain MUST send a		component, then the last proxy on the request chain MUST send a
	request-target of "*" when it forwards the request to the indicated		request-target of "*" when it forwards the request to the indicated
	skipping to change at page 47, line 11		skipping to change at page 47, line 11
	does not include no-transform, but if it does so, it MUST add a		does not include no-transform, but if it does so, it MUST add a
	Warning 214 (Transformation applied) if one does not already appear		Warning 214 (Transformation applied) if one does not already appear
	in the message (see Section 3.6 of [Part6]).		in the message (see Section 3.6 of [Part6]).
	Warning: Unnecessary modification of end-to-end header fields		Warning: Unnecessary modification of end-to-end header fields
	might cause authentication failures if stronger authentication		might cause authentication failures if stronger authentication
	mechanisms are introduced in later versions of HTTP. Such		mechanisms are introduced in later versions of HTTP. Such
	authentication mechanisms MAY rely on the values of header fields		authentication mechanisms MAY rely on the values of header fields
	not listed here.		not listed here.
	A non-transforming proxy MUST preserve the message payload ([Part3]),		A non-transforming proxy MUST preserve the message payload ([Part2]),
	though it MAY change the message body through application or removal		though it MAY change the message body through application or removal
	of a transfer-coding (Section 4).		of a transfer-coding (Section 4).
	5.7. Associating a Response to a Request		5.7. Associating a Response to a Request
	HTTP does not include a request identifier for associating a given		HTTP does not include a request identifier for associating a given
	request message with its corresponding one or more response messages.		request message with its corresponding one or more response messages.
	Hence, it relies on the order of response arrival to correspond		Hence, it relies on the order of response arrival to correspond
	exactly to the order in which requests are made on the same		exactly to the order in which requests are made on the same
	connection. More than one response message per request only occurs		connection. More than one response message per request only occurs
	when one or more informational responses (1xx, see Section 7.1 of		when one or more informational responses (1xx, see Section 4.3 of
	[Part2]) precede a final response to the same request.		[Part2]) precede a final response to the same request.
	A client that uses persistent connections and sends more than one		A client that uses persistent connections and sends more than one
	request per connection MUST maintain a list of outstanding requests		request per connection MUST maintain a list of outstanding requests
	in the order sent on that connection and MUST associate each received		in the order sent on that connection and MUST associate each received
	response message to the highest ordered request that has not yet		response message to the highest ordered request that has not yet
	received a final (non-1xx) response.		received a final (non-1xx) response.
	6. Connection Management		6. Connection Management
	skipping to change at page 52, line 42		skipping to change at page 52, line 42
	Clients which assume persistent connections and pipeline immediately		Clients which assume persistent connections and pipeline immediately
	after connection establishment SHOULD be prepared to retry their		after connection establishment SHOULD be prepared to retry their
	connection if the first pipelined attempt fails. If a client does		connection if the first pipelined attempt fails. If a client does
	such a retry, it MUST NOT pipeline before it knows the connection is		such a retry, it MUST NOT pipeline before it knows the connection is
	persistent. Clients MUST also be prepared to resend their requests		persistent. Clients MUST also be prepared to resend their requests
	if the server closes the connection before sending all of the		if the server closes the connection before sending all of the
	corresponding responses.		corresponding responses.
	Clients SHOULD NOT pipeline requests using non-idempotent request		Clients SHOULD NOT pipeline requests using non-idempotent request
	methods or non-idempotent sequences of request methods (see Section		methods or non-idempotent sequences of request methods (see Section
	6.1.2 of [Part2]). Otherwise, a premature termination of the		2.1.2 of [Part2]). Otherwise, a premature termination of the
	transport connection could lead to indeterminate results. A client		transport connection could lead to indeterminate results. A client
	wishing to send a non-idempotent request SHOULD wait to send that		wishing to send a non-idempotent request SHOULD wait to send that
	request until it has received the response status line for the		request until it has received the response status line for the
	previous request.		previous request.
	6.3.3. Practical Considerations		6.3.3. Practical Considerations
	Servers will usually have some time-out value beyond which they will		Servers will usually have some time-out value beyond which they will
	no longer maintain an inactive connection. Proxy servers might make		no longer maintain an inactive connection. Proxy servers might make
	this a higher value since it is likely that the client will be making		this a higher value since it is likely that the client will be making
	skipping to change at page 53, line 49		skipping to change at page 53, line 49
	Note that servers might reject traffic that they deem abusive,		Note that servers might reject traffic that they deem abusive,
	including an excessive number of connections from a client.		including an excessive number of connections from a client.
	6.3.4. Retrying Requests		6.3.4. Retrying Requests
	Senders can close the transport connection at any time. Therefore,		Senders can close the transport connection at any time. Therefore,
	clients, servers, and proxies MUST be able to recover from		clients, servers, and proxies MUST be able to recover from
	asynchronous close events. Client software MAY reopen the transport		asynchronous close events. Client software MAY reopen the transport
	connection and retransmit the aborted sequence of requests without		connection and retransmit the aborted sequence of requests without
	user interaction so long as the request sequence is idempotent (see		user interaction so long as the request sequence is idempotent (see
	Section 6.1.2 of [Part2]). Non-idempotent request methods or		Section 2.1.2 of [Part2]). Non-idempotent request methods or
	sequences MUST NOT be automatically retried, although user agents MAY		sequences MUST NOT be automatically retried, although user agents MAY
	offer a human operator the choice of retrying the request(s).		offer a human operator the choice of retrying the request(s).
	Confirmation by user-agent software with semantic understanding of		Confirmation by user-agent software with semantic understanding of
	the application MAY substitute for user confirmation. The automatic		the application MAY substitute for user confirmation. The automatic
	retry SHOULD NOT be repeated if the second sequence of requests		retry SHOULD NOT be repeated if the second sequence of requests
	fails.		fails.
	6.4. Message Transmission Requirements		6.4. Message Transmission Requirements
	skipping to change at page 54, line 32		skipping to change at page 54, line 32
	the network connection for an error status code while it is		the network connection for an error status code while it is
	transmitting the request. If the client sees an error status code,		transmitting the request. If the client sees an error status code,
	it SHOULD immediately cease transmitting the body. If the body is		it SHOULD immediately cease transmitting the body. If the body is
	being sent using a "chunked" encoding (Section 4), a zero length		being sent using a "chunked" encoding (Section 4), a zero length
	chunk and empty trailer MAY be used to prematurely mark the end of		chunk and empty trailer MAY be used to prematurely mark the end of
	the message. If the body was preceded by a Content-Length header		the message. If the body was preceded by a Content-Length header
	field, the client MUST close the connection.		field, the client MUST close the connection.
	6.4.3. Use of the 100 (Continue) Status		6.4.3. Use of the 100 (Continue) Status
	The purpose of the 100 (Continue) status code (see Section 7.1.1 of		The purpose of the 100 (Continue) status code (see Section 4.3.1 of
	[Part2]) is to allow a client that is sending a request message with		[Part2]) is to allow a client that is sending a request message with
	a request body to determine if the origin server is willing to accept		a request body to determine if the origin server is willing to accept
	the request (based on the request header fields) before the client		the request (based on the request header fields) before the client
	sends the request body. In some cases, it might either be		sends the request body. In some cases, it might either be
	inappropriate or highly inefficient for the client to send the body		inappropriate or highly inefficient for the client to send the body
	if the server will reject the message without looking at the body.		if the server will reject the message without looking at the body.
	Requirements for HTTP/1.1 clients:		Requirements for HTTP/1.1 clients:
	o If a client will wait for a 100 (Continue) response before sending		o If a client will wait for a 100 (Continue) response before sending
	the request body, it MUST send an Expect header field (Section		the request body, it MUST send an Expect header field (Section
	10.3 of [Part2]) with the "100-continue" expectation.		9.11 of [Part2]) with the "100-continue" expectation.
	o A client MUST NOT send an Expect header field (Section 10.3 of		o A client MUST NOT send an Expect header field (Section 9.11 of
	[Part2]) with the "100-continue" expectation if it does not intend		[Part2]) with the "100-continue" expectation if it does not intend
	to send a request body.		to send a request body.
	Because of the presence of older implementations, the protocol allows		Because of the presence of older implementations, the protocol allows
	ambiguous situations in which a client might send "Expect: 100-		ambiguous situations in which a client might send "Expect: 100-
	continue" without receiving either a 417 (Expectation Failed) or a		continue" without receiving either a 417 (Expectation Failed) or a
	100 (Continue) status code. Therefore, when a client sends this		100 (Continue) status code. Therefore, when a client sends this
	header field to an origin server (possibly via a proxy) from which it		header field to an origin server (possibly via a proxy) from which it
	has never seen a 100 (Continue) status code, the client SHOULD NOT		has never seen a 100 (Continue) status code, the client SHOULD NOT
	wait for an indefinite period before sending the request body.		wait for an indefinite period before sending the request body.
	skipping to change at page 56, line 26		skipping to change at page 56, line 26
	HTTP/1.0 or lower, it MUST NOT forward the request, and it MUST		HTTP/1.0 or lower, it MUST NOT forward the request, and it MUST
	respond with a 417 (Expectation Failed) status code.		respond with a 417 (Expectation Failed) status code.
	o Proxies SHOULD maintain a record of the HTTP version numbers		o Proxies SHOULD maintain a record of the HTTP version numbers
	received from recently-referenced next-hop servers.		received from recently-referenced next-hop servers.
	o A proxy MUST NOT forward a 100 (Continue) response if the request		o A proxy MUST NOT forward a 100 (Continue) response if the request
	message was received from an HTTP/1.0 (or earlier) client and did		message was received from an HTTP/1.0 (or earlier) client and did
	not include an Expect header field with the "100-continue"		not include an Expect header field with the "100-continue"
	expectation. This requirement overrides the general rule for		expectation. This requirement overrides the general rule for
	forwarding of 1xx responses (see Section 7.1 of [Part2]).		forwarding of 1xx responses (see Section 4.3 of [Part2]).
	6.4.4. Closing Connections on Error		6.4.4. Closing Connections on Error
	If the client is sending data, a server implementation using TCP		If the client is sending data, a server implementation using TCP
	SHOULD be careful to ensure that the client acknowledges receipt of		SHOULD be careful to ensure that the client acknowledges receipt of
	the packet(s) containing the response, before the server closes the		the packet(s) containing the response, before the server closes the
	input connection. If the client continues sending data to the server		input connection. If the client continues sending data to the server
	after the close, the server's TCP stack will send a reset packet to		after the close, the server's TCP stack will send a reset packet to
	the client, which might erase the client's unacknowledged input		the client, which might erase the client's unacknowledged input
	buffers before they can be read and interpreted by the HTTP		buffers before they can be read and interpreted by the HTTP
	skipping to change at page 57, line 37		skipping to change at page 57, line 37
	after changing the protocol MUST be a response to the initial HTTP		after changing the protocol MUST be a response to the initial HTTP
	request containing the Upgrade header field.		request containing the Upgrade header field.
	The Upgrade header field only applies to the immediate connection.		The Upgrade header field only applies to the immediate connection.
	Therefore, the upgrade keyword MUST be supplied within a Connection		Therefore, the upgrade keyword MUST be supplied within a Connection
	header field (Section 6.1) whenever Upgrade is present in an HTTP/1.1		header field (Section 6.1) whenever Upgrade is present in an HTTP/1.1
	message.		message.
	The Upgrade header field cannot be used to indicate a switch to a		The Upgrade header field cannot be used to indicate a switch to a
	protocol on a different connection. For that purpose, it is more		protocol on a different connection. For that purpose, it is more
	appropriate to use a 3xx redirection response (Section 7.3 of		appropriate to use a 3xx redirection response (Section 4.5 of
	[Part2]).		[Part2]).
	Servers MUST include the "Upgrade" header field in 101 (Switching		Servers MUST include the "Upgrade" header field in 101 (Switching
	Protocols) responses to indicate which protocol(s) are being switched		Protocols) responses to indicate which protocol(s) are being switched
	to, and MUST include it in 426 (Upgrade Required) responses to		to, and MUST include it in 426 (Upgrade Required) responses to
	indicate acceptable protocols to upgrade to. Servers MAY include it		indicate acceptable protocols to upgrade to. Servers MAY include it
	in any other response to indicate that they are willing to upgrade to		in any other response to indicate that they are willing to upgrade to
	one of the specified protocols.		one of the specified protocols.
	This specification only defines the protocol name "HTTP" for use by		This specification only defines the protocol name "HTTP" for use by
	skipping to change at page 61, line 39		skipping to change at page 61, line 39
	Registrations MUST include the following fields:		Registrations MUST include the following fields:
	o Name		o Name
	o Description		o Description
	o Pointer to specification text		o Pointer to specification text
	Names of transfer codings MUST NOT overlap with names of content		Names of transfer codings MUST NOT overlap with names of content
	codings (Section 2.2 of [Part3]) unless the encoding transformation		codings (Section 5.4 of [Part2]) unless the encoding transformation
	is identical, as it is the case for the compression codings defined		is identical, as it is the case for the compression codings defined
	in Section 4.2.		in Section 4.2.
	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		Section 4.1 of [RFC5226]), and MUST conform to the purpose of
	transfer coding defined in this section.		transfer coding defined in this section.
	The registry itself is maintained at		The registry itself is maintained at
	<http://www.iana.org/assignments/http-parameters>.		<http://www.iana.org/assignments/http-parameters>.
	skipping to change at page 65, line 42		skipping to change at page 65, line 42
	unlimited lengths.		unlimited lengths.
	To promote interoperability, this specification makes specific		To promote interoperability, this specification makes specific
	recommendations for minimum size limits on request-line		recommendations for minimum size limits on request-line
	(Section 3.1.1) and blocks of header fields (Section 3.2). These are		(Section 3.1.1) and blocks of header fields (Section 3.2). These are
	minimum recommendations, chosen to be supportable even by		minimum recommendations, chosen to be supportable even by
	implementations with limited resources; it is expected that most		implementations with limited resources; it is expected that most
	implementations will choose substantially higher limits.		implementations will choose substantially higher limits.
	This specification also provides a way for servers to reject messages		This specification also provides a way for servers to reject messages
	that have request-targets that are too long (Section 7.4.12 of		that have request-targets that are too long (Section 4.6.12 of
	[Part2]) or request entities that are too large (Section 7.4 of		[Part2]) or request entities that are too large (Section 4.6 of
	[Part2]).		[Part2]).
	Other fields (including but not limited to request methods, response		Other fields (including but not limited to request methods, response
	status phrases, header field-names, and body chunks) SHOULD be		status phrases, header field-names, and body chunks) SHOULD be
	limited by implementations carefully, so as to not impede		limited by implementations carefully, so as to not impede
	interoperability.		interoperability.
	9. Acknowledgments		9. Acknowledgments
	This edition of HTTP builds on the many contributions that went into		This edition of HTTP builds on the many contributions that went into
	skipping to change at page 66, line 19		skipping to change at page 66, line 19
	contributions made by the previous authors, editors, and working		contributions made by the previous authors, editors, and working
	group chairs: Tim Berners-Lee, Ari Luotonen, Roy T. Fielding, Henrik		group chairs: Tim Berners-Lee, Ari Luotonen, Roy T. Fielding, Henrik
	Frystyk Nielsen, Jim Gettys, Jeffrey C. Mogul, Larry Masinter, Paul		Frystyk Nielsen, Jim Gettys, Jeffrey C. Mogul, Larry Masinter, Paul
	J. Leach, and Mark Nottingham. See Section 16 of [RFC2616] for		J. Leach, and Mark Nottingham. See Section 16 of [RFC2616] for
	additional acknowledgements from prior revisions.		additional acknowledgements from prior revisions.
	Since 1999, the following contributors have helped improve the HTTP		Since 1999, the following contributors have helped improve the HTTP
	specification by reporting bugs, asking smart questions, drafting or		specification by reporting bugs, asking smart questions, drafting or
	reviewing text, and evaluating open issues:		reviewing text, and evaluating open issues:
	Adam Barth, Adam Roach, Addison Phillips, Adrian Chadd, Adrien de		Adam Barth, Adam Roach, Addison Phillips, Adrian Chadd, Adrien W. de
	Croy, Alan Ford, Alan Ruttenberg, Albert Lunde, Alex Rousskov, Alexey		Croy, Alan Ford, Alan Ruttenberg, Albert Lunde, Alex Rousskov,
	Melnikov, Alisha Smith, Amichai Rothman, Amit Klein, Amos Jeffries,		Alexandre Morgaut, Alexey Melnikov, Alisha Smith, Amichai Rothman,
	Andreas Maier, Andreas Petersson, Anne van Kesteren, Anthony Bryan,		Amit Klein, Amos Jeffries, Andreas Maier, Andreas Petersson, Anne van
	Asbjorn Ulsberg, Balachander Krishnamurthy, Barry Leiba, Ben Laurie,		Kesteren, Anthony Bryan, Asbjorn Ulsberg, Balachander Krishnamurthy,
	Benjamin Niven-Jenkins, Bil Corry, Bill Burke, Bjoern Hoehrmann, Bob		Barry Leiba, Ben Laurie, Benjamin Niven-Jenkins, Bil Corry, Bill
	Scheifler, Boris Zbarsky, Brett Slatkin, Brian Kell, Brian McBarron,		Burke, Bjoern Hoehrmann, Bob Scheifler, Boris Zbarsky, Brett Slatkin,
	Brian Pane, Brian Smith, Bryce Nesbitt, Cameron Heavon-Jones, Carl		Brian Kell, Brian McBarron, Brian Pane, Brian Smith, Bryce Nesbitt,
	Kugler, Carsten Bormann, Charles Fry, Chris Newman, Cyrus Daboo, Dale		Cameron Heavon-Jones, Carl Kugler, Carsten Bormann, Charles Fry,
	Robert Anderson, Dan Winship, Daniel Stenberg, Dave Cridland, Dave		Chris Newman, Cyrus Daboo, Dale Robert Anderson, Dan Winship, Daniel
	Crocker, Dave Kristol, David Booth, David Singer, David W. Morris,		Stenberg, Dave Cridland, Dave Crocker, Dave Kristol, David Booth,
	Diwakar Shetty, Dmitry Kurochkin, Drummond Reed, Duane Wessels,		David Singer, David W. Morris, Diwakar Shetty, Dmitry Kurochkin,
	Edward Lee, Eliot Lear, Eran Hammer-Lahav, Eric D. Williams, Eric J.		Drummond Reed, Duane Wessels, Edward Lee, Eliot Lear, Eran Hammer-
	Bowman, Eric Lawrence, Eric Rescorla, Erik Aronesty, Florian Weimer,		Lahav, Eric D. Williams, Eric J. Bowman, Eric Lawrence, Eric
	Frank Ellermann, Fred Bohle, Geoffrey Sneddon, Gervase Markham, Greg		Rescorla, Erik Aronesty, Florian Weimer, Frank Ellermann, Fred Bohle,
	Wilkins, Harald Tveit Alvestrand, Harry Halpin, Helge Hess, Henrik		Geoffrey Sneddon, Gervase Markham, Greg Wilkins, Harald Tveit
	Nordstrom, Henry S. Thompson, Henry Story, Herbert van de Sompel,		Alvestrand, Harry Halpin, Helge Hess, Henrik Nordstrom, Henry S.
	Howard Melman, Hugo Haas, Ian Hickson, Ingo Struck, J. Ross Nicoll,		Thompson, Henry Story, Herbert van de Sompel, Howard Melman, Hugo
	James H. Manger, James Lacey, James M. Snell, Jamie Lokier, Jan		Haas, Ian Hickson, Ingo Struck, J. Ross Nicoll, James H. Manger,
	Algermissen, Jeff Hodges (for coming up with the term 'effective		James Lacey, James M. Snell, Jamie Lokier, Jan Algermissen, Jeff
	Request-URI'), Jeff Walden, Jim Luther, Joe D. Williams, Joe		Hodges (for coming up with the term 'effective Request-URI'), Jeff
	Gregorio, Joe Orton, John C. Klensin, John C. Mallery, John Cowan,		Walden, Jim Luther, Joe D. Williams, Joe Gregorio, Joe Orton, John C.
	John Kemp, John Panzer, John Schneider, John Stracke, Jonas Sicking,		Klensin, John C. Mallery, John Cowan, John Kemp, John Panzer, John
	Jonathan Billington, Jonathan Moore, Jonathan Rees, Jordi Ros, Joris		Schneider, John Stracke, Jonas Sicking, Jonathan Billington, Jonathan
	Dobbelsteen, Josh Cohen, Julien Pierre, Jungshik Shin, Justin		Moore, Jonathan Rees, Jordi Ros, Joris Dobbelsteen, Josh Cohen,
	Chapweske, Justin Erenkrantz, Justin James, Kalvinder Singh, Karl		Julien Pierre, Jungshik Shin, Justin Chapweske, Justin Erenkrantz,
	Dubost, Keith Hoffman, Keith Moore, Koen Holtman, Konstantin		Justin James, Kalvinder Singh, Karl Dubost, Keith Hoffman, Keith
	Voronkov, Kris Zyp, Lisa Dusseault, Maciej Stachowiak, Marc		Moore, Koen Holtman, Konstantin Voronkov, Kris Zyp, Lisa Dusseault,
	Schneider, Marc Slemko, Mark Baker, Mark Pauley, Markus Lanthaler,		Maciej Stachowiak, Marc Schneider, Marc Slemko, Mark Baker, Mark
	Martin J. Duerst, Martin Thomson, Matt Lynch, Matthew Cox, Max Clark,		Pauley, Mark Watson, Markus Isomaki, Markus Lanthaler, Martin J.
	Michael Burrows, Michael Hausenblas, Mike Amundsen, Mike Belshe, Mike		Duerst, Martin Thomson, Matt Lynch, Matthew Cox, Max Clark, Michael
	Kelly, Mike Schinkel, Miles Sabin, Mykyta Yevstifeyev, Nathan Rixham,		Burrows, Michael Hausenblas, Mike Amundsen, Mike Belshe, Mike Kelly,
	Nicholas Shanks, Nico Williams, Nicolas Alvarez, Nicolas Mailhot,		Mike Schinkel, Miles Sabin, Murray S. Kucherawy, Mykyta Yevstifeyev,
	Noah Slater, Pablo Castro, Pat Hayes, Patrick R. McManus, Paul E.		Nathan Rixham, Nicholas Shanks, Nico Williams, Nicolas Alvarez,
			Nicolas Mailhot, Noah Slater, Pablo Castro, Pat Hayes, Patrick R.
	Jones, Paul Hoffman, Paul Marquess, Peter Saint-Andre, Peter Watkins,		McManus, Paul E. Jones, Paul Hoffman, Paul Marquess, Peter Lepeska,
	Phil Archer, Phillip Hallam-Baker, Poul-Henning Kamp, Preethi		Peter Saint-Andre, Peter Watkins, Phil Archer, Phillip Hallam-Baker,
	Natarajan, Ray Polk, Reto Bachmann-Gmuer, Richard Cyganiak, Robert		Poul-Henning Kamp, Preethi Natarajan, Ray Polk, Reto Bachmann-Gmuer,
	Brewer, Robert Collins, Robert O'Callahan, Robert Olofsson, Robert		Richard Cyganiak, Robert Brewer, Robert Collins, Robert O'Callahan,
	Sayre, Robert Siemer, Robert de Wilde, Roberto Javier Godoy, Ronny		Robert Olofsson, Robert Sayre, Robert Siemer, Robert de Wilde,
	Widjaja, S. Mike Dierken, Salvatore Loreto, Sam Johnston, Sam Ruby,		Roberto Javier Godoy, Roberto Peon, Ronny Widjaja, S. Mike Dierken,
	Scott Lawrence (for maintaining the original issues list), Sean B.		Salvatore Loreto, Sam Johnston, Sam Ruby, Scott Lawrence (for
	Palmer, Shane McCarron, Stefan Eissing, Stefan Tilkov, Stefanos		maintaining the original issues list), Sean B. Palmer, Shane
	Harhalakis, Stephane Bortzmeyer, Stephen Farrell, Stuart Williams,		McCarron, Stefan Eissing, Stefan Tilkov, Stefanos Harhalakis,
	Subbu Allamaraju, Sylvain Hellegouarch, Tapan Divekar, Ted Hardie,		Stephane Bortzmeyer, Stephen Farrell, Stuart Williams, Subbu
	Thomas Broyer, Thomas Nordin, Thomas Roessler, Tim Morgan, Tim Olsen,		Allamaraju, Sylvain Hellegouarch, Tapan Divekar, Ted Hardie, Thomas
	Travis Snoozy, Tyler Close, Vincent Murphy, Wenbo Zhu, Werner		Broyer, Thomas Nordin, Thomas Roessler, Tim Bray, Tim Morgan, Tim
	Baumann, Wilbur Streett, Wilfredo Sanchez Vega, William A. Rowe Jr.,		Olsen, Tom Zhou, Travis Snoozy, Tyler Close, Vincent Murphy, Wenbo
	William Chan, Willy Tarreau, Xiaoshu Wang, Yaron Goland, Yngve		Zhu, Werner Baumann, Wilbur Streett, Wilfredo Sanchez Vega, William
	Nysaeter Pettersen, Yogesh Bang, Yutaka Oiwa, Zed A. Shaw, and Zhong		A. Rowe Jr., William Chan, Willy Tarreau, Xiaoshu Wang, Yaron Goland,
	Yu.		Yngve Nysaeter Pettersen, Yogesh Bang, Yutaka Oiwa, Zed A. Shaw, and
			Zhong Yu.
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[ISO-8859-1] International Organization for Standardization,		[ISO-8859-1] International Organization for Standardization,
	"Information technology -- 8-bit single-byte coded		"Information technology -- 8-bit single-byte coded
	graphic character sets -- Part 1: Latin alphabet No.		graphic character sets -- Part 1: Latin alphabet No.
	1", ISO/IEC 8859-1:1998, 1998.		1", ISO/IEC 8859-1:1998, 1998.
	[Part2] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,		[Part2] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
	"HTTP/1.1, part 2: Message Semantics",		"HTTP/1.1, part 2: Message Semantics",
	draft-ietf-httpbis-p2-semantics-19 (work in progress),		draft-ietf-httpbis-p2-semantics-latest (work in
	March 2012.		progress), May 2012.
	[Part3] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
	"HTTP/1.1, part 3: Message Payload and Content
	Negotiation", draft-ietf-httpbis-p3-payload-19 (work in
	progress), March 2012.
	[Part6] Fielding, R., Ed., Lafon, Y., Ed., Nottingham, M., Ed.,		[Part6] Fielding, R., Ed., Lafon, Y., Ed., Nottingham, M., 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-19 (work in progress),		draft-ietf-httpbis-p6-cache-latest (work in progress),
	March 2012.		May 2012.
	[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data		[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data
	Format Specification version 3.3", RFC 1950, May 1996.		Format Specification version 3.3", RFC 1950, May 1996.
	[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format		[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format
	Specification version 1.3", RFC 1951, May 1996.		Specification version 1.3", RFC 1951, May 1996.
	[RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and		[RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and
	G. Randers-Pehrson, "GZIP file format specification		G. Randers-Pehrson, "GZIP file format specification
	version 4.3", RFC 1952, May 1996.		version 4.3", RFC 1952, May 1996.
	skipping to change at page 73, line 25		skipping to change at page 73, line 22
	to retry a sequence of requests as long it was idempotent. Remove		to retry a sequence of requests as long it was idempotent. Remove
	requirements about when servers are allowed to close connections		requirements about when servers are allowed to close connections
	prematurely. (Section 6.3.3)		prematurely. (Section 6.3.3)
	Remove requirement to retry requests under certain cirumstances when		Remove requirement to retry requests under certain cirumstances when
	the server prematurely closes the connection. (Section 6.4)		the server prematurely closes the connection. (Section 6.4)
	Change ABNF productions for header fields to only define the field		Change ABNF productions for header fields to only define the field
	value.		value.
	Clarify exactly when close connection options must be sent.		Clarify exactly when close connection options have to be sent.
	(Section 6.1)		(Section 6.1)
	Define the semantics of the "Upgrade" header field in responses other		Define the semantics of the "Upgrade" header field in responses other
	than 101 (this was incorporated from [RFC2817]). (Section 6.5)		than 101 (this was incorporated from [RFC2817]). (Section 6.5)
	A.3. Changes from RFC 2817		A.3. Changes from RFC 2817
	Registration of Upgrade tokens now requires IETF Review (Section 7.6)		Registration of Upgrade tokens now requires IETF Review (Section 7.6)
	Appendix B. Collected ABNF		Appendix B. Collected ABNF
	skipping to change at page 86, line 34		skipping to change at page 86, line 34
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/297>: "Retrying		o <http://tools.ietf.org/wg/httpbis/trac/ticket/297>: "Retrying
	Requests"		Requests"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/318>: "Closing the		o <http://tools.ietf.org/wg/httpbis/trac/ticket/318>: "Closing the
	connection on server error"		connection on server error"
	C.19. Since draft-ietf-httpbis-p1-messaging-17		C.19. Since draft-ietf-httpbis-p1-messaging-17
	Closed issues:		Closed issues:
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/158>: "Proxy-
			Connection and Keep-Alive"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/166>: "Clarify 'User		o <http://tools.ietf.org/wg/httpbis/trac/ticket/166>: "Clarify 'User
	Agent'"		Agent'"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/300>: "Define non-		o <http://tools.ietf.org/wg/httpbis/trac/ticket/300>: "Define non-
	final responses"		final responses"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/323>: "intended		o <http://tools.ietf.org/wg/httpbis/trac/ticket/323>: "intended
	maturity level vs normative references"		maturity level vs normative references"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/324>: "Intermediary		o <http://tools.ietf.org/wg/httpbis/trac/ticket/324>: "Intermediary
	rewriting of queries"		rewriting of queries"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/158>: "Proxy-
	Connection and Keep-Alive"
	C.20. Since draft-ietf-httpbis-p1-messaging-18		C.20. Since draft-ietf-httpbis-p1-messaging-18
	Closed issues:		Closed issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/250>: "message-body		o <http://tools.ietf.org/wg/httpbis/trac/ticket/250>: "message-body
	in CONNECT response"		in CONNECT response"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/302>: "Misplaced		o <http://tools.ietf.org/wg/httpbis/trac/ticket/302>: "Misplaced
	text on connection handling in p2"		text on connection handling in p2"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/335>: "wording of		o <http://tools.ietf.org/wg/httpbis/trac/ticket/335>: "wording of
	line folding rule"		line folding rule"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/343>: "chunk-		o <http://tools.ietf.org/wg/httpbis/trac/ticket/343>: "chunk-
	extensions"		extensions"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/346>: "make IANA		o <http://tools.ietf.org/wg/httpbis/trac/ticket/346>: "make IANA
	policy definitions consistent"		policy definitions consistent"
			C.21. Since draft-ietf-httpbis-p1-messaging-19
			None yet.
	Index		Index
	A		A
	absolute-form (of request-target) 41		absolute-form (of request-target) 41
	accelerator 11		accelerator 11
	application/http Media Type 60		application/http Media Type 60
	asterisk-form (of request-target) 41		asterisk-form (of request-target) 41
	authority-form (of request-target) 41		authority-form (of request-target) 41
	B		B
End of changes. 33 change blocks.
	94 lines changed or deleted		95 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/