p1-messaging-orig.txt		draft-fielding-http-p1-messaging-00.txt
	Network Working Group R. Fielding		Network Working Group R. Fielding, Ed.
	Internet-Draft UC Irvine		Internet-Draft Day Software
	Obsoletes: 2068, 2616, 2617 J. Gettys		Obsoletes: 2068, 2616, 2617 J. Gettys
	(if approved) Compaq/W3C		(if approved) J. Mogul
	Intended status: Standards Track J. Mogul		Intended status: Standards Track HP
	Expires: March 4, 2008 Compaq		Expires: May 14, 2008 H. Frystyk
	H. Frystyk		Microsoft
	W3C/MIT
	L. Masinter		L. Masinter
	Xerox		Adobe Systems
	P. Leach		P. Leach
	Microsoft		Microsoft
	T. Berners-Lee		T. Berners-Lee
	W3C/MIT		W3C/MIT
	September 2007		November 11, 2007
	HTTP/1.1, part 1: URIs, Connections, and Message Framing		HTTP/1.1, part 1: URIs, Connections, and Message Parsing
	draft-fielding-http-p1-messaging-00		draft-fielding-http-p1-messaging-00
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	skipping to change at page 1, line 45		skipping to change at page 1, line 44
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on March 4, 2008.		This Internet-Draft will expire on May 14, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	The Hypertext Transfer Protocol (HTTP) is an application-level		The Hypertext Transfer Protocol (HTTP) is an application-level
	protocol for distributed, collaborative, hypermedia information		protocol for distributed, collaborative, hypermedia information
	systems. HTTP has been in use by the World Wide Web global		systems. HTTP has been in use by the World Wide Web global
	skipping to change at page 2, line 49		skipping to change at page 2, line 49
	4. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . . 21		4. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . . 21
	4.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 21		4.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 21
	4.2. Message Headers . . . . . . . . . . . . . . . . . . . . . 22		4.2. Message Headers . . . . . . . . . . . . . . . . . . . . . 22
	4.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 23		4.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 23
	4.4. Message Length . . . . . . . . . . . . . . . . . . . . . . 24		4.4. Message Length . . . . . . . . . . . . . . . . . . . . . . 24
	4.5. General Header Fields . . . . . . . . . . . . . . . . . . 25		4.5. General Header Fields . . . . . . . . . . . . . . . . . . 25
	5. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 25		5. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
	5.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . . 26		5.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . . 26
	5.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . . 26		5.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . . 26
	5.1.2. Request-URI . . . . . . . . . . . . . . . . . . . . . 26		5.1.2. Request-URI . . . . . . . . . . . . . . . . . . . . . 26
	5.2. The Resource Identified by a Request . . . . . . . . . . . 27		5.2. The Resource Identified by a Request . . . . . . . . . . . 28
	6. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 28		6. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
	6.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 28		6.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 29
	6.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 29		6.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 29
	7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 29		7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 29
	7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 29		7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 30
	7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 29		7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 30
	7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 30		7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 30
	7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 32		7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 32
	7.1.4. Practical Considerations . . . . . . . . . . . . . . . 32		7.1.4. Practical Considerations . . . . . . . . . . . . . . . 32
	7.2. Message Transmission Requirements . . . . . . . . . . . . 33		7.2. Message Transmission Requirements . . . . . . . . . . . . 33
	7.2.1. Persistent Connections and Flow Control . . . . . . . 33		7.2.1. Persistent Connections and Flow Control . . . . . . . 33
	7.2.2. Monitoring Connections for Error Status Messages . . . 33		7.2.2. Monitoring Connections for Error Status Messages . . . 33
	7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 33		7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 34
	7.2.4. Client Behavior if Server Prematurely Closes		7.2.4. Client Behavior if Server Prematurely Closes
	Connection . . . . . . . . . . . . . . . . . . . . . . 35		Connection . . . . . . . . . . . . . . . . . . . . . . 36
	8. Header Field Definitions . . . . . . . . . . . . . . . . . . . 36		8. Header Field Definitions . . . . . . . . . . . . . . . . . . . 36
	8.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 36		8.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 37
	8.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 37		8.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 38
	8.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 38		8.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
	8.3.1. Clockless Origin Server Operation . . . . . . . . . . 39		8.3.1. Clockless Origin Server Operation . . . . . . . . . . 39
	8.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 39		8.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
	8.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40		8.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
	8.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 41		8.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 41
	8.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 42		8.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 42
	8.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 42		8.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 42
	8.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 43		8.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 45		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45
	9.1. Personal Information . . . . . . . . . . . . . . . . . . . 45		10. Security Considerations . . . . . . . . . . . . . . . . . . . 45
	9.2. Abuse of Server Log Information . . . . . . . . . . . . . 45		10.1. Personal Information . . . . . . . . . . . . . . . . . . . 45
	9.3. Attacks Based On File and Path Names . . . . . . . . . . . 45		10.2. Abuse of Server Log Information . . . . . . . . . . . . . 45
	9.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 46		10.3. Attacks Based On File and Path Names . . . . . . . . . . . 46
	9.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 46		10.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 46
	9.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 47		10.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 47
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 47		10.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 47
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 48		11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 48
			12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 49
	Appendix A. Internet Media Type message/http and		Appendix A. Internet Media Type message/http and
	application/http . . . . . . . . . . . . . . . . . . 51		application/http . . . . . . . . . . . . . . . . . . 52
	Appendix B. Tolerant Applications . . . . . . . . . . . . . . . . 52		Appendix B. Tolerant Applications . . . . . . . . . . . . . . . . 53
	Appendix C. Conversion of Date Formats . . . . . . . . . . . . . 53		Appendix C. Conversion of Date Formats . . . . . . . . . . . . . 54
	Appendix D. Compatibility with Previous Versions . . . . . . . . 53		Appendix D. Compatibility with Previous Versions . . . . . . . . 54
	D.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 54		D.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 55
	D.1.1. Changes to Simplify Multi-homed Web Servers and		D.1.1. Changes to Simplify Multi-homed Web Servers and
	Conserve IP Addresses . . . . . . . . . . . . . . . . 54		Conserve IP Addresses . . . . . . . . . . . . . . . . 55
	D.2. Compatibility with HTTP/1.0 Persistent Connections . . . . 55		D.2. Compatibility with HTTP/1.0 Persistent Connections . . . . 56
	D.3. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 55		D.3. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 56
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56		Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 59		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 60
	Intellectual Property and Copyright Statements . . . . . . . . . . 62		Intellectual Property and Copyright Statements . . . . . . . . . . 63
	1. Introduction		1. Introduction
	This document will define aspects of HTTP related to overall network		This document will define aspects of HTTP related to overall network
	operation, message framing, interaction with transport protocols, and		operation, message framing, interaction with transport protocols, and
	URI schemes. Right now it only includes the extracted relevant		URI schemes. Right now it only includes the extracted relevant
	sections of [RFC2616] and [RFC2617].		sections of [RFC2616] and [RFC2617].
	1.1. Purpose		1.1. Purpose
	skipping to change at page 4, line 48		skipping to change at page 4, line 48
	purpose of a request [RFC2324]. It builds on the discipline of		purpose of a request [RFC2324]. It builds on the discipline of
	reference provided by the Uniform Resource Identifier (URI)		reference provided by the Uniform Resource Identifier (URI)
	[RFC1630], as a location (URL) [RFC1738] or name (URN) [RFC1737], for		[RFC1630], as a location (URL) [RFC1738] or name (URN) [RFC1737], for
	indicating the resource to which a method is to be applied. Messages		indicating the resource to which a method is to be applied. Messages
	are passed in a format similar to that used by Internet mail [RFC822]		are passed in a format similar to that used by Internet mail [RFC822]
	as defined by the Multipurpose Internet Mail Extensions (MIME)		as defined by the Multipurpose Internet Mail Extensions (MIME)
	[RFC2045].		[RFC2045].
	HTTP is also used as a generic protocol for communication between		HTTP is also used as a generic protocol for communication between
	user agents and proxies/gateways to other Internet systems, including		user agents and proxies/gateways to other Internet systems, including
	those supported by the SMTP [RFC821], NNTP [RFC977], FTP [RFC959],		those supported by the SMTP [RFC821], NNTP [RFC3977], FTP [RFC959],
	Gopher [RFC1436], and WAIS [WAIS] protocols. In this way, HTTP		Gopher [RFC1436], and WAIS [WAIS] protocols. In this way, HTTP
	allows basic hypermedia access to resources available from diverse		allows basic hypermedia access to resources available from diverse
	applications.		applications.
	1.2. Requirements		1.2. Requirements
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	skipping to change at page 6, line 26		skipping to change at page 6, line 26
	The mechanism for selecting the appropriate representation when		The mechanism for selecting the appropriate representation when
	servicing a request, as described in [Part 3]. The representation		servicing a request, as described in [Part 3]. The representation
	of entities in any response can be negotiated (including error		of entities in any response can be negotiated (including error
	responses).		responses).
	variant		variant
	A resource may have one, or more than one, representation(s)		A resource may have one, or more than one, representation(s)
	associated with it at any given instant. Each of these		associated with it at any given instant. Each of these
	representations is termed a `varriant'. Use of the term `variant'		representations is termed a `variant'. Use of the term `variant'
	does not necessarily imply that the resource is subject to content		does not necessarily imply that the resource is subject to content
	negotiation.		negotiation.
	client		client
	A program that establishes connections for the purpose of sending		A program that establishes connections for the purpose of sending
	requests.		requests.
	user agent		user agent
	skipping to change at page 14, line 26		skipping to change at page 14, line 26
	number for the addition of message components which do not affect		number for the addition of message components which do not affect
	communication behavior or which only add to extensible field values.		communication behavior or which only add to extensible field values.
	The <minor> number is incremented when the changes made to the		The <minor> number is incremented when the changes made to the
	protocol add features which do not change the general message parsing		protocol add features which do not change the general message parsing
	algorithm, but which may add to the message semantics and imply		algorithm, but which may add to the message semantics and imply
	additional capabilities of the sender. The <major> number is		additional capabilities of the sender. The <major> number is
	incremented when the format of a message within the protocol is		incremented when the format of a message within the protocol is
	changed. See RFC 2145 [RFC2145] for a fuller explanation.		changed. See RFC 2145 [RFC2145] for a fuller explanation.
	The version of an HTTP message is indicated by an HTTP-Version field		The version of an HTTP message is indicated by an HTTP-Version field
	in the first line of the message.		in the first line of the message. HTTP-Version is case-sensitive.
	HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT		HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT
	Note that the major and minor numbers MUST be treated as separate		Note that the major and minor numbers MUST be treated as separate
	integers and that each MAY be incremented higher than a single digit.		integers and that each MAY be incremented higher than a single digit.
	Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is		Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is
	lower than HTTP/12.3. Leading zeros MUST be ignored by recipients		lower than HTTP/12.3. Leading zeros MUST be ignored by recipients
	and MUST NOT be sent.		and MUST NOT be sent.
	An application that sends a request or response message that includes		An application that sends a request or response message that includes
	skipping to change at page 16, line 40		skipping to change at page 16, line 40
	o A port that is empty or not given is equivalent to the default		o A port that is empty or not given is equivalent to the default
	port for that URI-reference;		port for that URI-reference;
	o Comparisons of host names MUST be case-insensitive;		o Comparisons of host names MUST be case-insensitive;
	o Comparisons of scheme names MUST be case-insensitive;		o Comparisons of scheme names MUST be case-insensitive;
	o An empty abs_path is equivalent to an abs_path of "/".		o An empty abs_path is equivalent to an abs_path of "/".
	Characters other than those in the "reserved" and "unsafe" sets (see		Characters other than those in the "reserved" set (see RFC 2396
	RFC 2396 [RFC2396]) are equivalent to their ""%" HEX HEX" encoding.		[RFC2396]) are equivalent to their ""%" HEX HEX" encoding.
	For example, the following three URIs are equivalent:		For example, the following three URIs are equivalent:
	http://abc.com:80/~smith/home.html		http://abc.com:80/~smith/home.html
	http://ABC.com/%7Esmith/home.html		http://ABC.com/%7Esmith/home.html
	http://ABC.com:/%7esmith/home.html		http://ABC.com:/%7esmith/home.html
	3.3. Date/Time Formats		3.3. Date/Time Formats
	3.3.1. Full Date		3.3.1. Full Date
	HTTP applications have historically allowed three different formats		HTTP applications have historically allowed three different formats
	for the representation of date/time stamps:		for the representation of date/time stamps:
	Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123		Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123
	Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036		Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format
	Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format		Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format
	The first format is preferred as an Internet standard and represents		The first format is preferred as an Internet standard and represents
	a fixed-length subset of that defined by RFC 1123 [RFC1123] (an		a fixed-length subset of that defined by RFC 1123 [RFC1123] (an
	update to RFC 822 [RFC822]). The second format is in common use, but		update to RFC 822 [RFC822]). The other formats are described here
	is based on the obsolete RFC 850 [RFC1036] date format and lacks a		only for compatibility with obsolete implementations. HTTP/1.1
	four-digit year. HTTP/1.1 clients and servers that parse the date		clients and servers that parse the date value MUST accept all three
	value MUST accept all three formats (for compatibility with		formats (for compatibility with HTTP/1.0), though they MUST only
	HTTP/1.0), though they MUST only generate the RFC 1123 format for		generate the RFC 1123 format for representing HTTP-date values in
	representing HTTP-date values in header fields. See Appendix B for		header fields. See Appendix B for further information.
	further information.
	Note: Recipients of date values are encouraged to be robust in		Note: Recipients of date values are encouraged to be robust in
	accepting date values that may have been sent by non-HTTP		accepting date values that may have been sent by non-HTTP
	applications, as is sometimes the case when retrieving or posting		applications, as is sometimes the case when retrieving or posting
	messages via proxies/gateways to SMTP or NNTP.		messages via proxies/gateways to SMTP or NNTP.
	All HTTP date/time stamps MUST be represented in Greenwich Mean Time		All HTTP date/time stamps MUST be represented in Greenwich Mean Time
	(GMT), without exception. For the purposes of HTTP, GMT is exactly		(GMT), without exception. For the purposes of HTTP, GMT is exactly
	equal to UTC (Coordinated Universal Time). This is indicated in the		equal to UTC (Coordinated Universal Time). This is indicated in the
	first two formats by the inclusion of "GMT" as the three-letter		first two formats by the inclusion of "GMT" as the three-letter
	skipping to change at page 19, line 20		skipping to change at page 19, line 20
	Transfer-codings are analogous to the Content-Transfer-Encoding		Transfer-codings are analogous to the Content-Transfer-Encoding
	values of MIME [RFC2045], which were designed to enable safe		values of MIME [RFC2045], which were designed to enable safe
	transport of binary data over a 7-bit transport service. However,		transport of binary data over a 7-bit transport service. However,
	safe transport has a different focus for an 8bit-clean transfer		safe transport has a different focus for an 8bit-clean transfer
	protocol. In HTTP, the only unsafe characteristic of message-bodies		protocol. In HTTP, the only unsafe characteristic of message-bodies
	is the difficulty in determining the exact body length (Section 4.4),		is the difficulty in determining the exact body length (Section 4.4),
	or the desire to encrypt data over a shared transport.		or the desire to encrypt data over a shared transport.
	The Internet Assigned Numbers Authority (IANA) acts as a registry for		The Internet Assigned Numbers Authority (IANA) acts as a registry for
	transfer-coding value tokens. Initially, the registry contains the		transfer-coding value tokens. Initially, the registry contains the
	following tokens: "chunked" (Section 3.4.1), "identity" (section		following tokens: "chunked" (Section 3.4.1), "gzip" ([Part 3]),
	3.6.2), "gzip" ([Part 3]), "compress" ([Part 3]), and "deflate"		"compress" ([Part 3]), and "deflate" ([Part 3]).
	([Part 3]).
	New transfer-coding value tokens SHOULD be registered in the same way		New transfer-coding value tokens SHOULD be registered in the same way
	as new content-coding value tokens ([Part 3]).		as new content-coding value tokens ([Part 3]).
	A server which receives an entity-body with a transfer-coding it does		A server which receives an entity-body with a transfer-coding it does
	not understand SHOULD return 501 (Unimplemented), and close the		not understand SHOULD return 501 (Unimplemented), and close the
	connection. A server MUST NOT send transfer-codings to an HTTP/1.0		connection. A server MUST NOT send transfer-codings to an HTTP/1.0
	client.		client.
	3.4.1. Chunked Transfer Coding		3.4.1. Chunked Transfer Coding
	skipping to change at page 20, line 22		skipping to change at page 20, line 22
	chunk-size = 1*HEX		chunk-size = 1*HEX
	last-chunk = 1*("0") [ chunk-extension ] CRLF		last-chunk = 1*("0") [ chunk-extension ] CRLF
	chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] )		chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
	chunk-ext-name = token		chunk-ext-name = token
	chunk-ext-val = token | quoted-string		chunk-ext-val = token | quoted-string
	chunk-data = chunk-size(OCTET)		chunk-data = chunk-size(OCTET)
	trailer = *(entity-header CRLF)		trailer = *(entity-header CRLF)
	The chunk-size field is a string of hex digits indicating the size of		The chunk-size field is a string of hex digits indicating the size of
	the chunk. The chunked encoding is ended by any chunk whose size is		the chunk-data in octets. The chunked encoding is ended by any chunk
	zero, followed by the trailer, which is terminated by an empty line.		whose size is zero, followed by the trailer, which is terminated by
			an empty line.
	The trailer allows the sender to include additional HTTP header		The trailer allows the sender to include additional HTTP header
	fields at the end of the message. The Trailer header field can be		fields at the end of the message. The Trailer header field can be
	used to indicate which header fields are included in a trailer (see		used to indicate which header fields are included in a trailer (see
	Section 8.6).		Section 8.6).
	A server using chunked transfer-coding in a response MUST NOT use the		A server using chunked transfer-coding in a response MUST NOT use the
	trailer for any header fields unless at least one of the following is		trailer for any header fields unless at least one of the following is
	true:		true:
	skipping to change at page 24, line 19		skipping to change at page 24, line 19
	been applied. When a message-body is included with a message, the		been applied. When a message-body is included with a message, the
	transfer-length of that body is determined by one of the following		transfer-length of that body is determined by one of the following
	(in order of precedence):		(in order of precedence):
	1. Any response message which "MUST NOT" include a message-body		1. Any response message which "MUST NOT" include a message-body
	(such as the 1xx, 204, and 304 responses and any response to a		(such as the 1xx, 204, and 304 responses and any response to a
	HEAD request) is always terminated by the first empty line after		HEAD request) is always terminated by the first empty line after
	the header fields, regardless of the entity-header fields present		the header fields, regardless of the entity-header fields present
	in the message.		in the message.
	2. If a Transfer-Encoding header field (Section 8.7) is present and		2. If a Transfer-Encoding header field (Section 8.7) is present,
	has any value other than "identity", then the transfer-length is		then the transfer-length is defined by use of the "chunked"
	defined by use of the "chunked" transfer-coding (Section 3.4),		transfer-coding (Section 3.4), unless the message is terminated
	unless the message is terminated by closing the connection.		by closing the connection.
	3. If a Content-Length header field (Section 8.2) is present, its		3. If a Content-Length header field (Section 8.2) is present, its
	decimal value in OCTETs represents both the entity-length and the		decimal value in OCTETs represents both the entity-length and the
	transfer-length. The Content-Length header field MUST NOT be		transfer-length. The Content-Length header field MUST NOT be
	sent if these two lengths are different (i.e., if a Transfer-		sent if these two lengths are different (i.e., if a Transfer-
	Encoding header field is present). If a message is received with		Encoding header field is present). If a message is received with
	both a Transfer-Encoding header field and a Content-Length header		both a Transfer-Encoding header field and a Content-Length header
	field, the latter MUST be ignored.		field, the latter MUST be ignored.
	4. If the message uses the media type "multipart/byteranges", and		4. If the message uses the media type "multipart/byteranges", and
	the ransfer-length is not otherwise specified, then this self-		the transfer-length is not otherwise specified, then this self-
	elimiting media type defines the transfer-length. This media		delimiting media type defines the transfer-length. This media
	type UST NOT be used unless the sender knows that the recipient		type MUST NOT be used unless the sender knows that the recipient
	can arse it; the presence in a request of a Range header with		can parse it; the presence in a request of a Range header with
	ultiple byte-range specifiers from a 1.1 client implies that the		multiple byte-range specifiers from a 1.1 client implies that the
	lient can parse multipart/byteranges responses.		client can parse multipart/byteranges responses.
	A range header might be forwarded by a 1.0 proxy that does not		A range header might be forwarded by a 1.0 proxy that does not
	understand multipart/byteranges; in this case the server MUST		understand multipart/byteranges; in this case the server MUST
	delimit the message using methods defined in items 1, 3 or 5		delimit the message using methods defined in items 1, 3 or 5
	of this section.		of this section.
	5. By the server closing the connection. (Closing the connection		5. By the server closing the connection. (Closing the connection
	cannot be used to indicate the end of a request body, since that		cannot be used to indicate the end of a request body, since that
	would leave no possibility for the server to send back a		would leave no possibility for the server to send back a
	response.)		response.)
	skipping to change at page 25, line 15		skipping to change at page 25, line 15
	the server SHOULD respond with 400 (bad request) if it cannot		the server SHOULD respond with 400 (bad request) if it cannot
	determine the length of the message, or with 411 (length required) if		determine the length of the message, or with 411 (length required) if
	it wishes to insist on receiving a valid Content-Length.		it wishes to insist on receiving a valid Content-Length.
	All HTTP/1.1 applications that receive entities MUST accept the		All HTTP/1.1 applications that receive entities MUST accept the
	"chunked" transfer-coding (Section 3.4), thus allowing this mechanism		"chunked" transfer-coding (Section 3.4), thus allowing this mechanism
	to be used for messages when the message length cannot be determined		to be used for messages when the message length cannot be determined
	in advance.		in advance.
	Messages MUST NOT include both a Content-Length header field and a		Messages MUST NOT include both a Content-Length header field and a
	non-identity transfer-coding. If the message does include a non-		transfer-coding. If the message does include a transfer-coding, the
	identity transfer-coding, the Content-Length MUST be ignored.		Content-Length MUST be ignored.
	When a Content-Length is given in a message where a message-body is		When a Content-Length is given in a message where a message-body is
	allowed, its field value MUST exactly match the number of OCTETs in		allowed, its field value MUST exactly match the number of OCTETs in
	the message-body. HTTP/1.1 user agents MUST notify the user when an		the message-body. HTTP/1.1 user agents MUST notify the user when an
	invalid length is received and detected.		invalid length is received and detected.
	4.5. General Header Fields		4.5. General Header Fields
	There are a few header fields which have general applicability for		There are a few header fields which have general applicability for
	both request and response messages, but which do not apply to the		both request and response messages, but which do not apply to the
	skipping to change at page 26, line 34		skipping to change at page 26, line 34
	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 = token		Method = token
	5.1.2. Request-URI		5.1.2. Request-URI
	The Request-URI is a Uniform Resource Identifier (Section 3.2) and		The Request-URI is a Uniform Resource Identifier (Section 3.2) and
	identifies the resource upon which to apply the request.		identifies the resource upon which to apply the request.
	Request-URI = "*" | absoluteURI | abs_path | authority		Request-URI = "*"
			| absoluteURI
			| ( abs_path [ "?" query ] )
			| authority
	The four options for Request-URI are dependent on the nature of the		The four options for Request-URI are dependent on the nature of the
	request. The asterisk "*" means that the request does not apply to a		request. The asterisk "*" means that the request does not apply to a
	particular resource, but to the server itself, and is only allowed		particular resource, but to the server itself, and is only allowed
	when the method used does not necessarily apply to a resource. One		when the method used does not necessarily apply to a resource. One
	example would be		example would be
	OPTIONS * HTTP/1.1		OPTIONS * HTTP/1.1
	The absoluteURI form is REQUIRED when the request is being made to a		The absoluteURI form is REQUIRED when the request is being made to a
	skipping to change at page 37, line 25		skipping to change at page 37, line 38
	HTTP/1.1 defines the "close" connection option for the sender to		HTTP/1.1 defines the "close" connection option for the sender to
	signal that the connection will be closed after completion of the		signal that the connection will be closed after completion of the
	response. For example,		response. For example,
	Connection: close		Connection: close
	in either the request or the response header fields indicates that		in either the request or the response header fields indicates that
	the connection SHOULD NOT be considered `persistent' (Section 7.1)		the connection SHOULD NOT be considered `persistent' (Section 7.1)
	after the current request/response is complete.		after the current request/response is complete.
	HTTP/1.1 applications that do not support persistent connections MUST		An HTTP/1.1 client that does not support persistent connections MUST
	include the "close" connection option in every message.		include the "close" connection option in every request message.
			An HTTP/1.1 server that does not support persistent connections MUST
			include the "close" connection option in every response message that
			does not have a 1xx (informational) status code.
	A system receiving an HTTP/1.0 (or lower-version) message that		A system receiving an HTTP/1.0 (or lower-version) message that
	includes a Connection header MUST, for each connection-token in this		includes a Connection header MUST, for each connection-token in this
	field, remove and ignore any header field(s) from the message with		field, remove and ignore any header field(s) from the message with
	the same name as the connection-token. This protects against		the same name as the connection-token. This protects against
	mistaken forwarding of such header fields by pre-HTTP/1.1 proxies.		mistaken forwarding of such header fields by pre-HTTP/1.1 proxies.
	See Appendix D.2.		See Appendix D.2.
	8.2. Content-Length		8.2. Content-Length
	skipping to change at page 38, line 21		skipping to change at page 38, line 38
	used within the "message/external-body" content-type. In HTTP, it		used within the "message/external-body" content-type. In HTTP, it
	SHOULD be sent whenever the message's length can be determined prior		SHOULD be sent whenever the message's length can be determined prior
	to being transferred, unless this is prohibited by the rules in		to being transferred, unless this is prohibited by the rules in
	Section 4.4.		Section 4.4.
	8.3. Date		8.3. Date
	The Date general-header field represents the date and time at which		The Date general-header field represents the date and time at which
	the message was originated, having the same semantics as orig-date in		the message was originated, having the same semantics as orig-date in
	RFC 822. The field value is an HTTP-date, as described in		RFC 822. The field value is an HTTP-date, as described in
	Section 3.3.1; it MUST be sent in RFC 1123 [RFC1123]-date format.		Section 3.3.1; it MUST be sent in rfc1123-date format.
	Date = "Date" ":" HTTP-date		Date = "Date" ":" HTTP-date
	An example is		An example is
	Date: Tue, 15 Nov 1994 08:12:31 GMT		Date: Tue, 15 Nov 1994 08:12:31 GMT
	Origin servers MUST include a Date header field in all responses,		Origin servers MUST include a Date header field in all responses,
	except in these cases:		except in these cases:
	skipping to change at page 45, line 6		skipping to change at page 45, line 21
	could be collapsed to		could be collapsed to
	Via: 1.0 ricky, 1.1 mertz, 1.0 lucy		Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
	Applications SHOULD NOT combine multiple entries unless they are all		Applications SHOULD NOT combine multiple entries unless they are all
	under the same organizational control and the hosts have already been		under the same organizational control and the hosts have already been
	replaced by pseudonyms. Applications MUST NOT combine entries which		replaced by pseudonyms. Applications MUST NOT combine entries which
	have different received-protocol values.		have different received-protocol values.
	9. Security Considerations		9. IANA Considerations
			TBD.
			10. 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.
	9.1. Personal Information		10.1. Personal Information
	HTTP clients are often privy to large amounts of personal information		HTTP clients are often privy to large amounts of personal information
	(e.g. the user's name, location, mail address, passwords, encryption		(e.g. the user's name, location, mail address, passwords, encryption
	keys, etc.), and SHOULD be very careful to prevent unintentional		keys, etc.), and SHOULD be very careful to prevent unintentional
	leakage of this information via the HTTP protocol to other sources.		leakage of this information via the HTTP protocol to other sources.
	We very strongly recommend that a convenient interface be provided		We very strongly recommend that a convenient interface be provided
	for the user to control dissemination of such information, and that		for the user to control dissemination of such information, and that
	designers and implementors be particularly careful in this area.		designers and implementors be particularly careful in this area.
	History shows that errors in this area often create serious security		History shows that errors in this area often create serious security
	and/or privacy problems and generate highly adverse publicity for the		and/or privacy problems and generate highly adverse publicity for the
	implementor's company.		implementor's company.
	9.2. Abuse of Server Log Information		10.2. Abuse of Server Log Information
	A server is in the position to save personal data about a user's		A server is in the position to save personal data about a user's
	requests which might identify their reading patterns or subjects of		requests which might identify their reading patterns or subjects of
	interest. This information is clearly confidential in nature and its		interest. This information is clearly confidential in nature and its
	handling can be constrained by law in certain countries. People		handling can be constrained by law in certain countries. People
	using the HTTP protocol to provide data are responsible for ensuring		using the HTTP protocol to provide data are responsible for ensuring
	that such material is not distributed without the permission of any		that such material is not distributed without the permission of any
	individuals that are identifiable by the published results.		individuals that are identifiable by the published results.
	9.3. Attacks Based On File and Path Names		10.3. Attacks Based On File and Path Names
	Implementations of HTTP origin servers SHOULD be careful to restrict		Implementations of HTTP origin servers SHOULD be careful to restrict
	the documents returned by HTTP requests to be only those that were		the documents returned by HTTP requests to be only those that were
	intended by the server administrators. If an HTTP server translates		intended by the server administrators. If an HTTP server translates
	HTTP URIs directly into file system calls, the server MUST take		HTTP URIs directly into file system calls, the server MUST take
	special care not to serve files that were not intended to be		special care not to serve files that were not intended to be
	delivered to HTTP clients. For example, UNIX, Microsoft Windows, and		delivered to HTTP clients. For example, UNIX, Microsoft Windows, and
	other operating systems use ".." as a path component to indicate a		other operating systems use ".." as a path component to indicate a
	directory level above the current one. On such a system, an HTTP		directory level above the current one. On such a system, an HTTP
	server MUST disallow any such construct in the Request-URI if it		server MUST disallow any such construct in the Request-URI if it
	would otherwise allow access to a resource outside those intended to		would otherwise allow access to a resource outside those intended to
	be accessible via the HTTP server. Similarly, files intended for		be accessible via the HTTP server. Similarly, files intended for
	reference only internally to the server (such as access control		reference only internally to the server (such as access control
	files, configuration files, and script code) MUST be protected from		files, configuration files, and script code) MUST be protected from
	inappropriate retrieval, since they might contain sensitive		inappropriate retrieval, since they might contain sensitive
	information. Experience has shown that minor bugs in such HTTP		information. Experience has shown that minor bugs in such HTTP
	server implementations have turned into security risks.		server implementations have turned into security risks.
	9.4. DNS Spoofing		10.4. DNS Spoofing
	Clients using HTTP rely heavily on the Domain Name Service, and are		Clients using HTTP rely heavily on the Domain Name Service, and are
	thus generally prone to security attacks based on the deliberate mis-		thus generally prone to security attacks based on the deliberate mis-
	association of IP addresses and DNS names. Clients need to be		association of IP addresses and DNS names. Clients need to be
	cautious in assuming the continuing validity of an IP number/DNS name		cautious in assuming the continuing validity of an IP number/DNS name
	association.		association.
	In particular, HTTP clients SHOULD rely on their name resolver for		In particular, HTTP clients SHOULD rely on their name resolver for
	confirmation of an IP number/DNS name association, rather than		confirmation of an IP number/DNS name association, rather than
	caching the result of previous host name lookups. Many platforms		caching the result of previous host name lookups. Many platforms
	skipping to change at page 46, line 41		skipping to change at page 47, line 12
	a previously-accessed server's IP address changes. As network		a previously-accessed server's IP address changes. As network
	renumbering is expected to become increasingly common [RFC1900], the		renumbering is expected to become increasingly common [RFC1900], the
	possibility of this form of attack will grow. Observing this		possibility of this form of attack will grow. Observing this
	requirement thus reduces this potential security vulnerability.		requirement thus reduces this potential security vulnerability.
	This requirement also improves the load-balancing behavior of clients		This requirement also improves the load-balancing behavior of clients
	for replicated servers using the same DNS name and reduces the		for replicated servers using the same DNS name and reduces the
	likelihood of a user's experiencing failure in accessing sites which		likelihood of a user's experiencing failure in accessing sites which
	use that strategy.		use that strategy.
	9.5. Proxies and Caching		10.5. Proxies and Caching
	By their very nature, HTTP proxies are men-in-the-middle, and		By their very nature, HTTP proxies are men-in-the-middle, and
	represent an opportunity for man-in-the-middle attacks. Compromise		represent an opportunity for man-in-the-middle attacks. Compromise
	of the systems on which the proxies run can result in serious		of the systems on which the proxies run can result in serious
	security and privacy problems. Proxies have access to security-		security and privacy problems. Proxies have access to security-
	related information, personal information about individual users and		related information, personal information about individual users and
	organizations, and proprietary information belonging to users and		organizations, and proprietary information belonging to users and
	content providers. A compromised proxy, or a proxy implemented or		content providers. A compromised proxy, or a proxy implemented or
	configured without regard to security and privacy considerations,		configured without regard to security and privacy considerations,
	might be used in the commission of a wide range of potential attacks.		might be used in the commission of a wide range of potential attacks.
	Proxy operators should protect the systems on which proxies run as		Proxy operators should protect the systems on which proxies run as
	they would protect any system that contains or transports sensitive		they would protect any system that contains or transports sensitive
	information. In particular, log information gathered at proxies		information. In particular, log information gathered at proxies
	often contains highly sensitive personal information, and/or		often contains highly sensitive personal information, and/or
	information about organizations. Log information should be carefully		information about organizations. Log information should be carefully
	guarded, and appropriate guidelines for use developed and followed.		guarded, and appropriate guidelines for use developed and followed.
	(Section 9.2).		(Section 10.2).
	Proxy implementors should consider the privacy and security		Proxy implementors should consider the privacy and security
	implications of their design and coding decisions, and of the		implications of their design and coding decisions, and of the
	configuration options they provide to proxy operators (especially the		configuration options they provide to proxy operators (especially the
	default configuration).		default configuration).
	Users of a proxy need to be aware that they are no trustworthier than		Users of a proxy need to be aware that they are no trustworthier than
	the people who run the proxy; HTTP itself cannot solve this problem.		the people who run the proxy; HTTP itself cannot solve this problem.
	The judicious use of cryptography, when appropriate, may suffice to		The judicious use of cryptography, when appropriate, may suffice to
	protect against a broad range of security and privacy attacks. Such		protect against a broad range of security and privacy attacks. Such
	cryptography is beyond the scope of the HTTP/1.1 specification.		cryptography is beyond the scope of the HTTP/1.1 specification.
	9.6. Denial of Service Attacks on Proxies		10.6. Denial of Service Attacks on Proxies
	They exist. They are hard to defend against. Research continues.		They exist. They are hard to defend against. Research continues.
	Beware.		Beware.
	10. Acknowledgments		11. Acknowledgments
	This specification makes heavy use of the augmented BNF and generic		This specification makes heavy use of the augmented BNF and generic
	constructs defined by David H. Crocker for RFC 822 [RFC822].		constructs defined by David H. Crocker for RFC 822 [RFC822].
	Similarly, it reuses many of the definitions provided by Nathaniel		Similarly, it reuses many of the definitions provided by Nathaniel
	Borenstein and Ned Freed for MIME [RFC2045]. We hope that their		Borenstein and Ned Freed for MIME [RFC2045]. We hope that their
	inclusion in this specification will help reduce past confusion over		inclusion in this specification will help reduce past confusion over
	the relationship between HTTP and Internet mail message formats.		the relationship between HTTP and Internet mail message formats.
	The HTTP protocol has evolved considerably over the years. It has		The HTTP protocol has evolved considerably over the years. It has
	benefited from a large and active developer community--the many		benefited from a large and active developer community--the many
	skipping to change at page 48, line 36		skipping to change at page 49, line 34
	Martijn Koster Simon E. Spero		Martijn Koster Simon E. Spero
	Alexei Kosut Richard N. Taylor		Alexei Kosut Richard N. Taylor
	David M. Kristol Robert S. Thau		David M. Kristol Robert S. Thau
	Daniel LaLiberte Bill (BearHeart) Weinman		Daniel LaLiberte Bill (BearHeart) Weinman
	Ben Laurie Francois Yergeau		Ben Laurie Francois Yergeau
	Paul J. Leach Mary Ellen Zurko		Paul J. Leach Mary Ellen Zurko
	Daniel DuBois Josh Cohen		Daniel DuBois Josh Cohen
	Based on an XML translation of RFC 2616 by Julian Reschke.		Based on an XML translation of RFC 2616 by Julian Reschke.
	11. References		12. References
	[ISO-8859]		[ISO-8859]
	International Organization for Standardization,		International Organization for Standardization,
	"Information technology - 8-bit single byte coded graphic		"Information technology - 8-bit single byte coded graphic
	- character sets", 1987-1990.		- character sets", 1987-1990.
	Part 1: Latin alphabet No. 1, ISO-8859-1:1987. Part 2:		Part 1: Latin alphabet No. 1, ISO-8859-1:1987. Part 2:
	Latin alphabet No. 2, ISO-8859-2, 1987. Part 3: Latin		Latin alphabet No. 2, ISO-8859-2, 1987. Part 3: Latin
	alphabet No. 3, ISO-8859-3, 1988. Part 4: Latin alphabet		alphabet No. 3, ISO-8859-3, 1988. Part 4: Latin alphabet
	No. 4, ISO-8859-4, 1988. Part 5: Latin/Cyrillic alphabet,		No. 4, ISO-8859-4, 1988. Part 5: Latin/Cyrillic alphabet,
	skipping to change at page 49, line 19		skipping to change at page 50, line 16
	[Pad1995] Padmanabhan, V. and J. Mogul, "Improving HTTP Latency",		[Pad1995] Padmanabhan, V. and J. Mogul, "Improving HTTP Latency",
	Computer Networks and ISDN Systems v. 28, pp. 25-35,		Computer Networks and ISDN Systems v. 28, pp. 25-35,
	Dec 1995.		Dec 1995.
	Slightly revised version of paper in Proc. 2nd		Slightly revised version of paper in Proc. 2nd
	International WWW Conference '94: Mosaic and the Web, Oct.		International WWW Conference '94: Mosaic and the Web, Oct.
	1994, which is available at <http://www.ncsa.uiuc.edu/SDG/		1994, which is available at <http://www.ncsa.uiuc.edu/SDG/
	IT94/Proceedings/DDay/mogul/HTTPLatency.html>.		IT94/Proceedings/DDay/mogul/HTTPLatency.html>.
	[RFC1036] Horton, M. and R. Adams, "Standard for interchange of
	USENET messages", RFC 1036, December 1987.
	[RFC1123] Braden, R., "Requirements for Internet Hosts - Application		[RFC1123] Braden, R., "Requirements for Internet Hosts - Application
	and Support", STD 3, RFC 1123, October 1989.		and Support", STD 3, RFC 1123, October 1989.
	[RFC1305] Mills, D., "Network Time Protocol (Version 3)		[RFC1305] Mills, D., "Network Time Protocol (Version 3)
	Specification, Implementation", RFC 1305, March 1992.		Specification, Implementation", RFC 1305, March 1992.
	[RFC1436] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D.,		[RFC1436] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D.,
	Torrey, D., and B. Alberti, "The Internet Gopher Protocol		Torrey, D., and B. Alberti, "The Internet Gopher Protocol
	(a distributed document search and retrieval protocol)",		(a distributed document search and retrieval protocol)",
	RFC 1436, March 1993.		RFC 1436, March 1993.
	[RFC1590] Postel, J., "Media Type Registration Procedure", RFC 1590,
	November 1996.
	[RFC1630] Berners-Lee, T., "Universal Resource Identifiers in WWW: A		[RFC1630] Berners-Lee, T., "Universal Resource Identifiers in WWW: A
	Unifying Syntax for the Expression of Names and Addresses		Unifying Syntax for the Expression of Names and Addresses
	of Objects on the Network as used in the World-Wide Web",		of Objects on the Network as used in the World-Wide Web",
	RFC 1630, June 1994.		RFC 1630, June 1994.
	[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2,		[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2,
	RFC 1700, October 1994.		RFC 1700, October 1994.
	[RFC1737] Masinter, L. and K. Sollins, "Functional Requirements for		[RFC1737] Masinter, L. and K. Sollins, "Functional Requirements for
	Uniform Resource Names", RFC 1737, December 1994.		Uniform Resource Names", RFC 1737, December 1994.
	skipping to change at page 50, line 46		skipping to change at page 51, line 37
	[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,		[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext		Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
	Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.		Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
	[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,		[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
	Leach, P., Luotonen, A., and L. Stewart, "HTTP		Leach, P., Luotonen, A., and L. Stewart, "HTTP
	Authentication: Basic and Digest Access Authentication",		Authentication: Basic and Digest Access Authentication",
	RFC 2617, June 1999.		RFC 2617, June 1999.
			[RFC3977] Feather, C., "Network News Transfer Protocol (NNTP)",
			October 2006.
			[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
			Registration Procedures", BCP 13, RFC 4288, December 2005.
	[RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10,		[RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10,
	RFC 821, August 1982.		RFC 821, August 1982.
	[RFC822] Crocker, D., "Standard for the format of ARPA Internet		[RFC822] Crocker, D., "Standard for the format of ARPA Internet
	text messages", STD 11, RFC 822, August 1982.		text messages", STD 11, RFC 822, August 1982.
	[RFC959] Postel, J. and J. Reynolds, "File Transfer Protocol",		[RFC959] Postel, J. and J. Reynolds, "File Transfer Protocol",
	STD 9, RFC 959, October 1985.		STD 9, RFC 959, October 1985.
	[RFC977] Kantor, B. and P. Lapsley, "Network News Transfer
	Protocol", RFC 977, February 1986.
	[Spe] Spero, S., "Analysis of HTTP Performance Problems",		[Spe] Spero, S., "Analysis of HTTP Performance Problems",
	<http://sunsite.unc.edu/mdma-release/http-prob.html>.		<http://sunsite.unc.edu/mdma-release/http-prob.html>.
	[Tou1998] Touch, J., Heidemann, J., and K. Obraczka, "Analysis of		[Tou1998] Touch, J., Heidemann, J., and K. Obraczka, "Analysis of
	HTTP Performance", ISI Research Report ISI/RR-98-463		HTTP Performance", ISI Research Report ISI/RR-98-463
	(original report dated Aug.1996), Aug 1998,		(original report dated Aug.1996), Aug 1998,
	<http://www.isi.edu/touch/pubs/http-perf96/>.		<http://www.isi.edu/touch/pubs/http-perf96/>.
	[USASCII] American National Standards Institute, "Coded Character		[USASCII] American National Standards Institute, "Coded Character
	Set -- 7-bit American Standard Code for Information		Set -- 7-bit American Standard Code for Information
	skipping to change at page 51, line 35		skipping to change at page 52, line 31
	Appendix A. Internet Media Type message/http and application/http		Appendix A. Internet Media Type message/http and application/http
	In addition to defining the HTTP/1.1 protocol, this document serves		In addition to defining the HTTP/1.1 protocol, this document serves
	as the specification for the Internet media type "message/http" and		as the specification for the Internet media type "message/http" and
	"application/http". The message/http type can be used to enclose a		"application/http". The message/http type can be used to enclose a
	single HTTP request or response message, provided that it obeys the		single HTTP request or response message, provided that it obeys the
	MIME restrictions for all "message" types regarding line length and		MIME restrictions for all "message" types regarding line length and
	encodings. The application/http type can be used to enclose a		encodings. The application/http type can be used to enclose a
	pipeline of one or more HTTP request or response messages (not		pipeline of one or more HTTP request or response messages (not
	intermixed). The following is to be registered with IANA [RFC1590].		intermixed). The following is to be registered with IANA [RFC4288].
	Media Type name: message		Media Type name: message
	Media subtype name: http		Media subtype name: http
	Required parameters: none		Required parameters: none
	Optional parameters: version, msgtype		Optional parameters: version, msgtype
	version: The HTTP-Version number of the enclosed message (e.g.,		version: The HTTP-Version number of the enclosed message (e.g.,
	skipping to change at page 56, line 26		skipping to change at page 57, line 20
	codings), a new header field (TE) and enabling trailer headers in the		codings), a new header field (TE) and enabling trailer headers in the
	future. Transfer encoding is a major performance benefit, so it was		future. Transfer encoding is a major performance benefit, so it was
	worth fixing [Nie1997]. TE also solves another, obscure, downward		worth fixing [Nie1997]. TE also solves another, obscure, downward
	interoperability problem that could have occurred due to interactions		interoperability problem that could have occurred due to interactions
	between authentication trailers, chunked encoding and HTTP/1.0		between authentication trailers, chunked encoding and HTTP/1.0
	clients.(Section 3.4, 3.4.1, and 8.5)		clients.(Section 3.4, 3.4.1, and 8.5)
	Index		Index
	A		A
	application/http Media Type 51		application/http Media Type 52
	C		C
	cache 7		cache 7
	cacheable 7		cacheable 7
	client 6		client 6
	connection 5		connection 5
	Connection header 36		Connection header 37
	content negotiation 6		content negotiation 6
	Content-Length header 37		Content-Length header 38
	D		D
	Date header 38		Date header 38
	downstream 8		downstream 8
	E		E
	entity 5		entity 5
	G		G
	gateway 7		gateway 7
	skipping to change at page 57, line 11		skipping to change at page 58, line 6
	attribute 18		attribute 18
	CHAR 12		CHAR 12
	chunk 20		chunk 20
	chunk-data 20		chunk-data 20
	chunk-ext-name 20		chunk-ext-name 20
	chunk-ext-val 20		chunk-ext-val 20
	chunk-extension 20		chunk-extension 20
	chunk-size 20		chunk-size 20
	Chunked-Body 20		Chunked-Body 20
	comment 13		comment 13
	Connection 36		Connection 37
	connection-token 36		connection-token 37
	Content-Length 37		Content-Length 38
	CR 12		CR 12
	CRLF 12		CRLF 12
	ctext 13		ctext 13
	CTL 12		CTL 12
	Date 38		Date 38
	date1 18		date1 18
	date2 18		date2 18
	date3 18		date3 18
	DIGIT 12		DIGIT 12
	extension-code 29		extension-code 29
	extension-method 26		extension-method 26
	field-content 22		field-content 22
	field-name 22		field-name 22
	field-value 22		field-value 22
	general-header 25		general-header 25
	generic-message 21		generic-message 21
	HEX 13		HEX 13
	Host 39		Host 40
	HT 12		HT 12
	HTTP-date 18		HTTP-date 18
	HTTP-message 21		HTTP-message 21
	HTTP-Version 14		HTTP-Version 14
	http_URL 16		http_URL 16
	last-chunk 20		last-chunk 20
	LF 12		LF 12
	LOALPHA 12		LOALPHA 12
	LWS 13		LWS 13
	message-body 23		message-body 23
	message-header 22		message-header 22
	Method 26		Method 26
	month 18		month 18
	OCTET 12		OCTET 12
	parameter 18		parameter 18
	protocol-name 43		protocol-name 44
	protocol-version 43		protocol-version 44
	pseudonym 43		pseudonym 44
	qdtext 13		qdtext 13
	quoted-pair 14		quoted-pair 14
	quoted-string 13		quoted-string 13
	Reason-Phrase 29		Reason-Phrase 29
	received-by 43		received-by 44
	received-protocol 43		received-protocol 44
	Request 26		Request 26
	Request-Line 26		Request-Line 26
	Request-URI 26		Request-URI 26
	Response 28		Response 28
	rfc850-date 18		rfc850-date 18
	rfc1123-date 18		rfc1123-date 18
	separators 13		separators 13
	SP 12		SP 12
	start-line 21		start-line 21
	Status-Code 29		Status-Code 29
	Status-Line 28		Status-Line 29
	t-codings 40		t-codings 40
	TE 40		TE 40
	TEXT 13		TEXT 13
	time 18		time 18
	token 13		token 13
	Trailer 41		Trailer 41
	trailer 20		trailer 20
	transfer-coding 18		transfer-coding 18
	Transfer-Encoding 42		Transfer-Encoding 42
	transfer-extension 18		transfer-extension 18
	UPALPHA 12		UPALPHA 12
	Upgrade 42		Upgrade 42
	value 18		value 18
	Via 43		Via 44
	weekday 18		weekday 18
	wkday 18		wkday 18
	H		H
	Headers		Headers
	Connection 36		Connection 37
	Content-Length 37		Content-Length 38
	Date 38		Date 38
	Host 39		Host 39
	TE 40		TE 40
	Trailer 41		Trailer 41
	Transfer-Encoding 42		Transfer-Encoding 42
	Upgrade 42		Upgrade 42
	Via 43		Via 43
	Host header 39		Host header 39
	I		I
	skipping to change at page 59, line 4		skipping to change at page 59, line 46
	Host 39		Host 39
	TE 40		TE 40
	Trailer 41		Trailer 41
	Transfer-Encoding 42		Transfer-Encoding 42
	Upgrade 42		Upgrade 42
	Via 43		Via 43
	Host header 39		Host header 39
	I		I
	inbound 8		inbound 8
	M		M
	Media Type		Media Type
	application/http 51		application/http 52
	message/http 51		message/http 52
	message 5		message 5
	message/http Media Type 51		message/http Media Type 52
	O		O
	origin server 6		origin server 6
	outbound 8		outbound 8
	P		P
	proxy 7		proxy 7
	R		R
	representation 6		representation 6
	skipping to change at page 60, line 7		skipping to change at page 60, line 39
	Upgrade header 42		Upgrade header 42
	upstream 8		upstream 8
	user agent 6		user agent 6
	V		V
	variant 6		variant 6
	Via header 43		Via header 43
	Authors' Addresses		Authors' Addresses
	Roy T. Fielding		Roy T. Fielding (editor)
	Department of Information and Computer Science		Day Software
	University of California, Irvine		23 Corporate Plaza DR, Suite 280
	Irvine, CA 92697-3425		Newport Beach, CA 92660
			USA
	Fax: +1(949)824-1715
	Email: fielding@ics.uci.edu
			Phone: +1-949-706-5300
			Fax: +1-949-706-5305
			Email: fielding@gbiv.com
			URI: http://roy.gbiv.com/
	James Gettys		James Gettys
	World Wide Web Consortium		Hewlett-Packard Company
	MIT Laboratory for Computer Science, NE43-356		HP Labs, Cambridge Research Laboratory
	545 Technology Square		One Cambridge Center
	Cambridge, MA 02139		Cambridge, MA 02138
			USA
	Fax: +1(617)258-8682		Email: Jim.Gettys@hp.com
	Email: jg@w3.org
	Jeffrey C. Mogul		Jeffrey C. Mogul
	Compaq Computer Corporation		Hewlett-Packard Company
	Western Research Laboratory		HP Labs, Large Scale Systems Group
	250 University Avenue		1501 Page Mill Road, MS 1177
	Palo Alto, CA 94305		Palo Alto, CA 94304
			USA
	Email: mogul@wrl.dec.com		Email: JeffMogul@acm.org
	Henrik Frystyk Nielsen		Henrik Frystyk Nielsen
	World Wide Web Consortium		Microsoft Corporation
	MIT Laboratory for Computer Science, NE43-356		1 Microsoft Way
	545 Technology Square		Redmond, WA 98052
	Cambridge, MA 02139		USA
	Fax: +1(617)258-8682		Email: henrikn@microsoft.com
	Email: frystyk@w3.org
	Larry Masinter		Larry Masinter
	Xerox Corporation		Adobe Systems, Incorporated
	MIT Laboratory for Computer Science, NE43-356		345 Park Ave
	3333 Coyote Hill Road		San Jose, CA 95110
	Palo Alto, CA 94034		USA
			Email: LMM@acm.org
			URI: http://larry.masinter.net/
	Email: masinter@parc.xerox.com
	Paul J. Leach		Paul J. Leach
	Microsoft Corporation		Microsoft Corporation
	1 Microsoft Way		1 Microsoft Way
	Redmond, WA 98052		Redmond, WA 98052
	Email: paulle@microsoft.com		Email: paulle@microsoft.com
	Tim Berners-Lee		Tim Berners-Lee
	World Wide Web Consortium		World Wide Web Consortium
	MIT Laboratory for Computer Science, NE43-356		MIT Laboratory for Computer Science
	545 Technology Square		545 Technology Square
	Cambridge, MA 02139		Cambridge, MA 02139
			USA
	Fax: +1(617)258-8682		Fax: +1 (617) 258 8682
	Email: timbl@w3.org		Email: timbl@w3.org
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
End of changes. 71 change blocks.
	144 lines changed or deleted		156 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/