Context Navigation

draft-ietf-httpbis-p1-messaging-04.txt @ 2111

Last change on this file since 2111 was 559, checked in by fielding@…, 12 years ago
remove executable and set eol-style for earlier drafts
Property svn:eol-style set to `native`
File size: 156.3 KB

Rev	Line
[559]	1
	2
	3
	4	Network Working Group R. Fielding, Ed.
	5	Internet-Draft Day Software
	6	Obsoletes: 2616 (if approved) J. Gettys
	7	Intended status: Standards Track One Laptop per Child
	8	Expires: March 2, 2009 J. Mogul
	9	HP
	10	H. Frystyk
	11	Microsoft
	12	L. Masinter
	13	Adobe Systems
	14	P. Leach
	15	Microsoft
	16	T. Berners-Lee
	17	W3C/MIT
	18	Y. Lafon, Ed.
	19	W3C
	20	J. Reschke, Ed.
	21	greenbytes
	22	August 29, 2008
	23
	24
	25	HTTP/1.1, part 1: URIs, Connections, and Message Parsing
	26	draft-ietf-httpbis-p1-messaging-04
	27
	28	Status of this Memo
	29
	30	By submitting this Internet-Draft, each author represents that any
	31	applicable patent or other IPR claims of which he or she is aware
	32	have been or will be disclosed, and any of which he or she becomes
	33	aware will be disclosed, in accordance with Section 6 of BCP 79.
	34
	35	Internet-Drafts are working documents of the Internet Engineering
	36	Task Force (IETF), its areas, and its working groups. Note that
	37	other groups may also distribute working documents as Internet-
	38	Drafts.
	39
	40	Internet-Drafts are draft documents valid for a maximum of six months
	41	and may be updated, replaced, or obsoleted by other documents at any
	42	time. It is inappropriate to use Internet-Drafts as reference
	43	material or to cite them other than as "work in progress."
	44
	45	The list of current Internet-Drafts can be accessed at
	46	http://www.ietf.org/ietf/1id-abstracts.txt.
	47
	48	The list of Internet-Draft Shadow Directories can be accessed at
	49	http://www.ietf.org/shadow.html.
	50
	51	This Internet-Draft will expire on March 2, 2009.
	52
	53
	54
	55	Fielding, et al. Expires March 2, 2009 [Page 1]
	56
	57	Internet-Draft HTTP/1.1, Part 1 August 2008
	58
	59
	60	Abstract
	61
	62	The Hypertext Transfer Protocol (HTTP) is an application-level
	63	protocol for distributed, collaborative, hypermedia information
	64	systems. HTTP has been in use by the World Wide Web global
	65	information initiative since 1990. This document is Part 1 of the
	66	seven-part specification that defines the protocol referred to as
	67	"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 1 provides
	68	an overview of HTTP and its associated terminology, defines the
	69	"http" and "https" Uniform Resource Identifier (URI) schemes, defines
	70	the generic message syntax and parsing requirements for HTTP message
	71	frames, and describes general security concerns for implementations.
	72
	73	Editorial Note (To be removed by RFC Editor)
	74
	75	Discussion of this draft should take place on the HTTPBIS working
	76	group mailing list (ietf-http-wg@w3.org). The current issues list is
	77	at <http://www.tools.ietf.org/wg/httpbis/trac/report/11> and related
	78	documents (including fancy diffs) can be found at
	79	<http://www.tools.ietf.org/wg/httpbis/>.
	80
	81	The changes in this draft are summarized in Appendix D.4.
	82
	83
	84
	85
	86
	87
	88
	89
	90
	91
	92
	93
	94
	95
	96
	97
	98
	99
	100
	101
	102
	103
	104
	105
	106
	107
	108
	109
	110
	111	Fielding, et al. Expires March 2, 2009 [Page 2]
	112
	113	Internet-Draft HTTP/1.1, Part 1 August 2008
	114
	115
	116	Table of Contents
	117
	118	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
	119	1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 5
	120	1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6
	121	1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
	122	1.4. Overall Operation . . . . . . . . . . . . . . . . . . . . 9
	123	2. Notational Conventions and Generic Grammar . . . . . . . . . . 11
	124	2.1. Augmented BNF . . . . . . . . . . . . . . . . . . . . . . 11
	125	2.2. Basic Rules . . . . . . . . . . . . . . . . . . . . . . . 13
	126	2.3. ABNF Rules defined in other Parts of the Specification . . 16
	127	3. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 16
	128	3.1. HTTP Version . . . . . . . . . . . . . . . . . . . . . . . 16
	129	3.2. Uniform Resource Identifiers . . . . . . . . . . . . . . . 17
	130	3.2.1. General Syntax . . . . . . . . . . . . . . . . . . . . 17
	131	3.2.2. http URL . . . . . . . . . . . . . . . . . . . . . . . 18
	132	3.2.3. URI Comparison . . . . . . . . . . . . . . . . . . . . 19
	133	3.3. Date/Time Formats . . . . . . . . . . . . . . . . . . . . 19
	134	3.3.1. Full Date . . . . . . . . . . . . . . . . . . . . . . 19
	135	3.4. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 21
	136	3.4.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 22
	137	3.5. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 24
	138	4. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . . 24
	139	4.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 24
	140	4.2. Message Headers . . . . . . . . . . . . . . . . . . . . . 25
	141	4.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 26
	142	4.4. Message Length . . . . . . . . . . . . . . . . . . . . . . 27
	143	4.5. General Header Fields . . . . . . . . . . . . . . . . . . 28
	144	5. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
	145	5.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . . 29
	146	5.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . . 29
	147	5.1.2. Request-URI . . . . . . . . . . . . . . . . . . . . . 30
	148	5.2. The Resource Identified by a Request . . . . . . . . . . . 31
	149	6. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
	150	6.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 32
	151	6.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 32
	152	7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 33
	153	7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 33
	154	7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 33
	155	7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 34
	156	7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 35
	157	7.1.4. Practical Considerations . . . . . . . . . . . . . . . 35
	158	7.2. Message Transmission Requirements . . . . . . . . . . . . 36
	159	7.2.1. Persistent Connections and Flow Control . . . . . . . 37
	160	7.2.2. Monitoring Connections for Error Status Messages . . . 37
	161	7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 37
	162	7.2.4. Client Behavior if Server Prematurely Closes
	163	Connection . . . . . . . . . . . . . . . . . . . . . . 39
	164
	165
	166
	167	Fielding, et al. Expires March 2, 2009 [Page 3]
	168
	169	Internet-Draft HTTP/1.1, Part 1 August 2008
	170
	171
	172	8. Header Field Definitions . . . . . . . . . . . . . . . . . . . 40
	173	8.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 40
	174	8.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 41
	175	8.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
	176	8.3.1. Clockless Origin Server Operation . . . . . . . . . . 43
	177	8.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
	178	8.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
	179	8.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 45
	180	8.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 45
	181	8.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 46
	182	8.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
	183	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48
	184	9.1. Message Header Registration . . . . . . . . . . . . . . . 48
	185	9.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 49
	186	9.3. Internet Media Type Registrations . . . . . . . . . . . . 49
	187	9.3.1. Internet Media Type message/http . . . . . . . . . . . 49
	188	9.3.2. Internet Media Type application/http . . . . . . . . . 50
	189	10. Security Considerations . . . . . . . . . . . . . . . . . . . 51
	190	10.1. Personal Information . . . . . . . . . . . . . . . . . . . 52
	191	10.2. Abuse of Server Log Information . . . . . . . . . . . . . 52
	192	10.3. Attacks Based On File and Path Names . . . . . . . . . . . 52
	193	10.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 52
	194	10.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 53
	195	10.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 54
	196	11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 54
	197	12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55
	198	12.1. Normative References . . . . . . . . . . . . . . . . . . . 55
	199	12.2. Informative References . . . . . . . . . . . . . . . . . . 56
	200	Appendix A. Tolerant Applications . . . . . . . . . . . . . . . . 59
	201	Appendix B. Conversion of Date Formats . . . . . . . . . . . . . 59
	202	Appendix C. Compatibility with Previous Versions . . . . . . . . 60
	203	C.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 60
	204	C.1.1. Changes to Simplify Multi-homed Web Servers and
	205	Conserve IP Addresses . . . . . . . . . . . . . . . . 60
	206	C.2. Compatibility with HTTP/1.0 Persistent Connections . . . . 61
	207	C.3. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 62
	208	C.4. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 62
	209	Appendix D. Change Log (to be removed by RFC Editor before
	210	publication) . . . . . . . . . . . . . . . . . . . . 63
	211	D.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 63
	212	D.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 63
	213	D.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 64
	214	D.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 65
	215	D.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 66
	216	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
	217	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 70
	218	Intellectual Property and Copyright Statements . . . . . . . . . . 73
	219
	220
	221
	222
	223	Fielding, et al. Expires March 2, 2009 [Page 4]
	224
	225	Internet-Draft HTTP/1.1, Part 1 August 2008
	226
	227
	228	1. Introduction
	229
	230	The Hypertext Transfer Protocol (HTTP) is an application-level
	231	protocol for distributed, collaborative, hypermedia information
	232	systems. HTTP has been in use by the World-Wide Web global
	233	information initiative since 1990. The first version of HTTP,
	234	commonly referred to as HTTP/0.9, was a simple protocol for raw data
	235	transfer across the Internet with only a single method and no
	236	metadata. HTTP/1.0, as defined by [RFC1945], improved the protocol
	237	by allowing messages to be in the format of MIME-like messages,
	238	containing metadata about the data transferred and modifiers on the
	239	request/response semantics. However, HTTP/1.0 did not sufficiently
	240	take into consideration the effects of hierarchical proxies, caching,
	241	the need for persistent connections, or name-based virtual hosts. In
	242	addition, the proliferation of incompletely-implemented applications
	243	calling themselves "HTTP/1.0" necessitated a protocol version change
	244	in order for two communicating applications to determine each other's
	245	true capabilities.
	246
	247	This document is Part 1 of the seven-part specification that defines
	248	the protocol referred to as "HTTP/1.1", obsoleting [RFC2616].
	249	HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent
	250	requirements that enable reliable implementations and adding only
	251	those new features that will either be safely ignored by an HTTP/1.0
	252	recipient or only sent when communicating with a party advertising
	253	compliance with HTTP/1.1. Part 1 defines those aspects of HTTP/1.1
	254	related to overall network operation, message framing, interaction
	255	with transport protocols, and URI schemes.
	256
	257	This document is currently disorganized in order to minimize the
	258	changes between drafts and enable reviewers to see the smaller errata
	259	changes. The next draft will reorganize the sections to better
	260	reflect the content. In particular, the sections will be organized
	261	according to the typical process of deciding when to use HTTP (URI
	262	schemes), overall network operation, connection management, message
	263	framing, and generic message parsing. The current mess reflects how
	264	widely dispersed these topics and associated requirements had become
	265	in [RFC2616].
	266
	267	1.1. Purpose
	268
	269	Practical information systems require more functionality than simple
	270	retrieval, including search, front-end update, and annotation. HTTP
	271	allows an open-ended set of methods and headers that indicate the
	272	purpose of a request [RFC2324]. It builds on the discipline of
	273	reference provided by the Uniform Resource Identifier (URI)
	274	[RFC1630], as a location (URL) [RFC1738] or name (URN) [RFC1737], for
	275	indicating the resource to which a method is to be applied. Messages
	276
	277
	278
	279	Fielding, et al. Expires March 2, 2009 [Page 5]
	280
	281	Internet-Draft HTTP/1.1, Part 1 August 2008
	282
	283
	284	are passed in a format similar to that used by Internet mail
	285	[RFC2822] as defined by the Multipurpose Internet Mail Extensions
	286	(MIME) [RFC2045].
	287
	288	HTTP is also used as a generic protocol for communication between
	289	user agents and proxies/gateways to other Internet systems, including
	290	those supported by the SMTP [RFC2821], NNTP [RFC3977], FTP [RFC959],
	291	Gopher [RFC1436], and WAIS [WAIS] protocols. In this way, HTTP
	292	allows basic hypermedia access to resources available from diverse
	293	applications.
	294
	295	1.2. Requirements
	296
	297	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	298	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	299	document are to be interpreted as described in [RFC2119].
	300
	301	An implementation is not compliant if it fails to satisfy one or more
	302	of the MUST or REQUIRED level requirements for the protocols it
	303	implements. An implementation that satisfies all the MUST or
	304	REQUIRED level and all the SHOULD level requirements for its
	305	protocols is said to be "unconditionally compliant"; one that
	306	satisfies all the MUST level requirements but not all the SHOULD
	307	level requirements for its protocols is said to be "conditionally
	308	compliant."
	309
	310	1.3. Terminology
	311
	312	This specification uses a number of terms to refer to the roles
	313	played by participants in, and objects of, the HTTP communication.
	314
	315	connection
	316
	317	A transport layer virtual circuit established between two programs
	318	for the purpose of communication.
	319
	320	message
	321
	322	The basic unit of HTTP communication, consisting of a structured
	323	sequence of octets matching the syntax defined in Section 4 and
	324	transmitted via the connection.
	325
	326	request
	327
	328	An HTTP request message, as defined in Section 5.
	329
	330	response
	331
	332
	333
	334
	335	Fielding, et al. Expires March 2, 2009 [Page 6]
	336
	337	Internet-Draft HTTP/1.1, Part 1 August 2008
	338
	339
	340	An HTTP response message, as defined in Section 6.
	341
	342	resource
	343
	344	A network data object or service that can be identified by a URI,
	345	as defined in Section 3.2. Resources may be available in multiple
	346	representations (e.g. multiple languages, data formats, size, and
	347	resolutions) or vary in other ways.
	348
	349	entity
	350
	351	The information transferred as the payload of a request or
	352	response. An entity consists of metainformation in the form of
	353	entity-header fields and content in the form of an entity-body, as
	354	described in Section 4 of [Part3].
	355
	356	representation
	357
	358	An entity included with a response that is subject to content
	359	negotiation, as described in Section 5 of [Part3]. There may
	360	exist multiple representations associated with a particular
	361	response status.
	362
	363	content negotiation
	364
	365	The mechanism for selecting the appropriate representation when
	366	servicing a request, as described in Section 5 of [Part3]. The
	367	representation of entities in any response can be negotiated
	368	(including error responses).
	369
	370	variant
	371
	372	A resource may have one, or more than one, representation(s)
	373	associated with it at any given instant. Each of these
	374	representations is termed a `variant'. Use of the term `variant'
	375	does not necessarily imply that the resource is subject to content
	376	negotiation.
	377
	378	client
	379
	380	A program that establishes connections for the purpose of sending
	381	requests.
	382
	383	user agent
	384
	385	The client which initiates a request. These are often browsers,
	386	editors, spiders (web-traversing robots), or other end user tools.
	387
	388
	389
	390
	391	Fielding, et al. Expires March 2, 2009 [Page 7]
	392
	393	Internet-Draft HTTP/1.1, Part 1 August 2008
	394
	395
	396	server
	397
	398	An application program that accepts connections in order to
	399	service requests by sending back responses. Any given program may
	400	be capable of being both a client and a server; our use of these
	401	terms refers only to the role being performed by the program for a
	402	particular connection, rather than to the program's capabilities
	403	in general. Likewise, any server may act as an origin server,
	404	proxy, gateway, or tunnel, switching behavior based on the nature
	405	of each request.
	406
	407	origin server
	408
	409	The server on which a given resource resides or is to be created.
	410
	411	proxy
	412
	413	An intermediary program which acts as both a server and a client
	414	for the purpose of making requests on behalf of other clients.
	415	Requests are serviced internally or by passing them on, with
	416	possible translation, to other servers. A proxy MUST implement
	417	both the client and server requirements of this specification. A
	418	"transparent proxy" is a proxy that does not modify the request or
	419	response beyond what is required for proxy authentication and
	420	identification. A "non-transparent proxy" is a proxy that
	421	modifies the request or response in order to provide some added
	422	service to the user agent, such as group annotation services,
	423	media type transformation, protocol reduction, or anonymity
	424	filtering. Except where either transparent or non-transparent
	425	behavior is explicitly stated, the HTTP proxy requirements apply
	426	to both types of proxies.
	427
	428	gateway
	429
	430	A server which acts as an intermediary for some other server.
	431	Unlike a proxy, a gateway receives requests as if it were the
	432	origin server for the requested resource; the requesting client
	433	may not be aware that it is communicating with a gateway.
	434
	435	tunnel
	436
	437	An intermediary program which is acting as a blind relay between
	438	two connections. Once active, a tunnel is not considered a party
	439	to the HTTP communication, though the tunnel may have been
	440	initiated by an HTTP request. The tunnel ceases to exist when
	441	both ends of the relayed connections are closed.
	442
	443	cache
	444
	445
	446
	447	Fielding, et al. Expires March 2, 2009 [Page 8]
	448
	449	Internet-Draft HTTP/1.1, Part 1 August 2008
	450
	451
	452	A program's local store of response messages and the subsystem
	453	that controls its message storage, retrieval, and deletion. A
	454	cache stores cacheable responses in order to reduce the response
	455	time and network bandwidth consumption on future, equivalent
	456	requests. Any client or server may include a cache, though a
	457	cache cannot be used by a server that is acting as a tunnel.
	458
	459	cacheable
	460
	461	A response is cacheable if a cache is allowed to store a copy of
	462	the response message for use in answering subsequent requests.
	463	The rules for determining the cacheability of HTTP responses are
	464	defined in Section 1 of [Part6]. Even if a resource is cacheable,
	465	there may be additional constraints on whether a cache can use the
	466	cached copy for a particular request.
	467
	468	upstream/downstream
	469
	470	Upstream and downstream describe the flow of a message: all
	471	messages flow from upstream to downstream.
	472
	473	inbound/outbound
	474
	475	Inbound and outbound refer to the request and response paths for
	476	messages: "inbound" means "traveling toward the origin server",
	477	and "outbound" means "traveling toward the user agent"
	478
	479	1.4. Overall Operation
	480
	481	HTTP is a request/response protocol. A client sends a request to the
	482	server in the form of a request method, URI, and protocol version,
	483	followed by a MIME-like message containing request modifiers, client
	484	information, and possible body content over a connection with a
	485	server. The server responds with a status line, including the
	486	message's protocol version and a success or error code, followed by a
	487	MIME-like message containing server information, entity
	488	metainformation, and possible entity-body content. The relationship
	489	between HTTP and MIME is described in Appendix A of [Part3].
	490
	491	Most HTTP communication is initiated by a user agent and consists of
	492	a request to be applied to a resource on some origin server. In the
	493	simplest case, this may be accomplished via a single connection (v)
	494	between the user agent (UA) and the origin server (O).
	495
	496	request chain ------------------------>
	497	UA -------------------v------------------- O
	498	<----------------------- response chain
	499
	500
	501
	502
	503	Fielding, et al. Expires March 2, 2009 [Page 9]
	504
	505	Internet-Draft HTTP/1.1, Part 1 August 2008
	506
	507
	508	A more complicated situation occurs when one or more intermediaries
	509	are present in the request/response chain. There are three common
	510	forms of intermediary: proxy, gateway, and tunnel. A proxy is a
	511	forwarding agent, receiving requests for a URI in its absolute form,
	512	rewriting all or part of the message, and forwarding the reformatted
	513	request toward the server identified by the URI. A gateway is a
	514	receiving agent, acting as a layer above some other server(s) and, if
	515	necessary, translating the requests to the underlying server's
	516	protocol. A tunnel acts as a relay point between two connections
	517	without changing the messages; tunnels are used when the
	518	communication needs to pass through an intermediary (such as a
	519	firewall) even when the intermediary cannot understand the contents
	520	of the messages.
	521
	522	request chain -------------------------------------->
	523	UA -----v----- A -----v----- B -----v----- C -----v----- O
	524	<------------------------------------- response chain
	525
	526	The figure above shows three intermediaries (A, B, and C) between the
	527	user agent and origin server. A request or response message that
	528	travels the whole chain will pass through four separate connections.
	529	This distinction is important because some HTTP communication options
	530	may apply only to the connection with the nearest, non-tunnel
	531	neighbor, only to the end-points of the chain, or to all connections
	532	along the chain. Although the diagram is linear, each participant
	533	may be engaged in multiple, simultaneous communications. For
	534	example, B may be receiving requests from many clients other than A,
	535	and/or forwarding requests to servers other than C, at the same time
	536	that it is handling A's request.
	537
	538	Any party to the communication which is not acting as a tunnel may
	539	employ an internal cache for handling requests. The effect of a
	540	cache is that the request/response chain is shortened if one of the
	541	participants along the chain has a cached response applicable to that
	542	request. The following illustrates the resulting chain if B has a
	543	cached copy of an earlier response from O (via C) for a request which
	544	has not been cached by UA or A.
	545
	546	request chain ---------->
	547	UA -----v----- A -----v----- B - - - - - - C - - - - - - O
	548	<--------- response chain
	549
	550	Not all responses are usefully cacheable, and some requests may
	551	contain modifiers which place special requirements on cache behavior.
	552	HTTP requirements for cache behavior and cacheable responses are
	553	defined in Section 1 of [Part6].
	554
	555	In fact, there are a wide variety of architectures and configurations
	556
	557
	558
	559	Fielding, et al. Expires March 2, 2009 [Page 10]
	560
	561	Internet-Draft HTTP/1.1, Part 1 August 2008
	562
	563
	564	of caches and proxies currently being experimented with or deployed
	565	across the World Wide Web. These systems include national hierarchies
	566	of proxy caches to save transoceanic bandwidth, systems that
	567	broadcast or multicast cache entries, organizations that distribute
	568	subsets of cached data via CD-ROM, and so on. HTTP systems are used
	569	in corporate intranets over high-bandwidth links, and for access via
	570	PDAs with low-power radio links and intermittent connectivity. The
	571	goal of HTTP/1.1 is to support the wide diversity of configurations
	572	already deployed while introducing protocol constructs that meet the
	573	needs of those who build web applications that require high
	574	reliability and, failing that, at least reliable indications of
	575	failure.
	576
	577	HTTP communication usually takes place over TCP/IP connections. The
	578	default port is TCP 80
	579	(<http://www.iana.org/assignments/port-numbers>), but other ports can
	580	be used. This does not preclude HTTP from being implemented on top
	581	of any other protocol on the Internet, or on other networks. HTTP
	582	only presumes a reliable transport; any protocol that provides such
	583	guarantees can be used; the mapping of the HTTP/1.1 request and
	584	response structures onto the transport data units of the protocol in
	585	question is outside the scope of this specification.
	586
	587	In HTTP/1.0, most implementations used a new connection for each
	588	request/response exchange. In HTTP/1.1, a connection may be used for
	589	one or more request/response exchanges, although connections may be
	590	closed for a variety of reasons (see Section 7.1).
	591
	592
	593	2. Notational Conventions and Generic Grammar
	594
	595	2.1. Augmented BNF
	596
	597	All of the mechanisms specified in this document are described in
	598	both prose and an augmented Backus-Naur Form (BNF) similar to that
	599	used by [RFC822ABNF]. Implementors will need to be familiar with the
	600	notation in order to understand this specification. The augmented
	601	BNF includes the following constructs:
	602
	603	name = definition
	604
	605	The name of a rule is simply the name itself (without any
	606	enclosing "<" and ">") and is separated from its definition by the
	607	equal "=" character. White space is only significant in that
	608	indentation of continuation lines is used to indicate a rule
	609	definition that spans more than one line. Certain basic rules are
	610	in uppercase, such as SP, LWS, HTAB, CRLF, DIGIT, ALPHA, etc.
	611	Angle brackets are used within definitions whenever their presence
	612
	613
	614
	615	Fielding, et al. Expires March 2, 2009 [Page 11]
	616
	617	Internet-Draft HTTP/1.1, Part 1 August 2008
	618
	619
	620	will facilitate discerning the use of rule names.
	621
	622	"literal"
	623
	624	Quotation marks surround literal text. Unless stated otherwise,
	625	the text is case-insensitive.
	626
	627	rule1 \| rule2
	628
	629	Elements separated by a bar ("\|") are alternatives, e.g., "yes \|
	630	no" will accept yes or no.
	631
	632	(rule1 rule2)
	633
	634	Elements enclosed in parentheses are treated as a single element.
	635	Thus, "(elem (foo \| bar) elem)" allows the token sequences "elem
	636	foo elem" and "elem bar elem".
	637
	638	*rule
	639
	640	The character "*" preceding an element indicates repetition. The
	641	full form is "<n>*<m>element" indicating at least <n> and at most
	642	<m> occurrences of element. Default values are 0 and infinity so
	643	that "(element)" allows any number, including zero; "1element"
	644	requires at least one; and "1*2element" allows one or two.
	645
	646	[rule]
	647
	648	Square brackets enclose optional elements; "[foo bar]" is
	649	equivalent to "*1(foo bar)".
	650
	651	N rule
	652
	653	Specific repetition: "<n>(element)" is equivalent to
	654	"<n>*<n>(element)"; that is, exactly <n> occurrences of (element).
	655	Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three
	656	alphabetic characters.
	657
	658	#rule
	659
	660	A construct "#" is defined, similar to "*", for defining lists of
	661	elements. The full form is "<n>#<m>element" indicating at least
	662	<n> and at most <m> elements, each separated by one or more commas
	663	(",") and OPTIONAL linear white space (LWS). This makes the usual
	664	form of lists very easy; a rule such as
	665
	666	( LWS element ( LWS "," LWS element ))
	667
	668
	669
	670
	671	Fielding, et al. Expires March 2, 2009 [Page 12]
	672
	673	Internet-Draft HTTP/1.1, Part 1 August 2008
	674
	675
	676	can be shown as
	677
	678	1#element
	679
	680	Wherever this construct is used, null elements are allowed, but do
	681	not contribute to the count of elements present. That is,
	682	"(element), , (element) " is permitted, but counts as only two
	683	elements. Therefore, where at least one element is required, at
	684	least one non-null element MUST be present. Default values are 0
	685	and infinity so that "#element" allows any number, including zero;
	686	"1#element" requires at least one; and "1#2element" allows one or
	687	two.
	688
	689	; comment
	690
	691	A semi-colon, set off some distance to the right of rule text,
	692	starts a comment that continues to the end of line. This is a
	693	simple way of including useful notes in parallel with the
	694	specifications.
	695
	696	implied *LWS
	697
	698	The grammar described by this specification is word-based. Except
	699	where noted otherwise, linear white space (LWS) can be included
	700	between any two adjacent words (token or quoted-string), and
	701	between adjacent words and separators, without changing the
	702	interpretation of a field. At least one delimiter (LWS and/or
	703	separators) MUST exist between any two tokens (for the definition
	704	of "token" below), since they would otherwise be interpreted as a
	705	single token.
	706
	707	2.2. Basic Rules
	708
	709	The following rules are used throughout this specification to
	710	describe basic parsing constructs. The US-ASCII coded character set
	711	is defined by ANSI X3.4-1986 [USASCII].
	712
	713
	714
	715
	716
	717
	718
	719
	720
	721
	722
	723
	724
	725
	726
	727	Fielding, et al. Expires March 2, 2009 [Page 13]
	728
	729	Internet-Draft HTTP/1.1, Part 1 August 2008
	730
	731
	732	OCTET = %x00-FF
	733	; any 8-bit sequence of data
	734	CHAR = %x01-7F
	735	; any US-ASCII character, excluding NUL
	736	ALPHA = %x41-5A \| %x61-7A
	737	; A-Z \| a-z
	738	DIGIT = %x30-39
	739	; any US-ASCII digit "0".."9"
	740	CTL = %x00-1F \| %x7F
	741	; (octets 0 - 31) and DEL (127)
	742	CR = %x0D
	743	; US-ASCII CR, carriage return (13)
	744	LF = %x0A
	745	; US-ASCII LF, linefeed (10)
	746	SP = %x20
	747	; US-ASCII SP, space (32)
	748	HTAB = %x09
	749	; US-ASCII HT, horizontal-tab (9)
	750	DQUOTE = %x22
	751	; US-ASCII double-quote mark (34)
	752
	753	HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all
	754	protocol elements except the entity-body (see Appendix A for tolerant
	755	applications). The end-of-line marker within an entity-body is
	756	defined by its associated media type, as described in Section 3.3 of
	757	[Part3].
	758
	759	CRLF = CR LF
	760
	761	HTTP/1.1 header field values can be folded onto multiple lines if the
	762	continuation line begins with a space or horizontal tab. All linear
	763	white space, including folding, has the same semantics as SP. A
	764	recipient MAY replace any linear white space with a single SP before
	765	interpreting the field value or forwarding the message downstream.
	766
	767	LWS = [CRLF] 1*( SP \| HTAB )
	768
	769	The TEXT rule is only used for descriptive field contents and values
	770	that are not intended to be interpreted by the message parser. Words
	771	of *TEXT MAY contain characters from character sets other than ISO-
	772	8859-1 [ISO-8859-1] only when encoded according to the rules of
	773	[RFC2047].
	774
	775	TEXT = %x20-7E \| %x80-FF \| LWS
	776	; any OCTET except CTLs, but including LWS
	777
	778	A CRLF is allowed in the definition of TEXT only as part of a header
	779	field continuation. It is expected that the folding LWS will be
	780
	781
	782
	783	Fielding, et al. Expires March 2, 2009 [Page 14]
	784
	785	Internet-Draft HTTP/1.1, Part 1 August 2008
	786
	787
	788	replaced with a single SP before interpretation of the TEXT value.
	789
	790	Hexadecimal numeric characters are used in several protocol elements.
	791
	792	HEXDIG = "A" \| "B" \| "C" \| "D" \| "E" \| "F"
	793	\| "a" \| "b" \| "c" \| "d" \| "e" \| "f" \| DIGIT
	794
	795	Many HTTP/1.1 header field values consist of words separated by LWS
	796	or special characters. These special characters MUST be in a quoted
	797	string to be used within a parameter value (as defined in
	798	Section 3.4).
	799
	800	separators = "(" \| ")" \| "<" \| ">" \| "@"
	801	\| "," \| ";" \| ":" \| "\" \| DQUOTE
	802	\| "/" \| "[" \| "]" \| "?" \| "="
	803	\| "{" \| "}" \| SP \| HTAB
	804
	805	tchar = "!" \| "#" \| "$" \| "%" \| "&" \| "'" \| "*"
	806	\| "+" \| "-" \| "." \| "^" \| "_" \| "`" \| "\|" \| "~"
	807	\| DIGIT \| ALPHA
	808	; any CHAR except CTLs or separators
	809
	810	token = 1*tchar
	811
	812	Comments can be included in some HTTP header fields by surrounding
	813	the comment text with parentheses. Comments are only allowed in
	814	fields containing "comment" as part of their field value definition.
	815	In all other fields, parentheses are considered part of the field
	816	value.
	817
	818	comment = "(" *( ctext \| quoted-pair \| comment ) ")"
	819	ctext = <any TEXT excluding "(" and ")">
	820
	821	A string of text is parsed as a single word if it is quoted using
	822	double-quote marks.
	823
	824	quoted-string = ( DQUOTE *(qdtext \| quoted-pair ) DQUOTE )
	825	qdtext = <any TEXT excluding DQUOTE and "\">
	826
	827	The backslash character ("\") MAY be used as a single-character
	828	quoting mechanism only within quoted-string and comment constructs.
	829
	830	quoted-text = %x01-09 \|
	831	%x0B-0C \|
	832	%x0E-FF ; Characters excluding NUL, CR and LF
	833	quoted-pair = "\" quoted-text
	834
	835
	836
	837
	838
	839	Fielding, et al. Expires March 2, 2009 [Page 15]
	840
	841	Internet-Draft HTTP/1.1, Part 1 August 2008
	842
	843
	844	2.3. ABNF Rules defined in other Parts of the Specification
	845
	846	The ABNF rules below are defined in other parts:
	847
	848	request-header = <request-header, defined in [Part2], Section 4>
	849	response-header = <response-header, defined in [Part2], Section 6>
	850
	851
	852	accept-params = <accept-params, defined in [Part3], Section 6.1>
	853	entity-body = <entity-body, defined in [Part3], Section 4.2>
	854	entity-header = <entity-header, defined in [Part3], Section 4.1>
	855
	856
	857	Cache-Control = <Cache-Control, defined in [Part6], Section 16.4>
	858	Pragma = <Pragma, defined in [Part6], Section 16.4>
	859	Warning = <Warning, defined in [Part6], Section 16.6>
	860
	861
	862	3. Protocol Parameters
	863
	864	3.1. HTTP Version
	865
	866	HTTP uses a "<major>.<minor>" numbering scheme to indicate versions
	867	of the protocol. The protocol versioning policy is intended to allow
	868	the sender to indicate the format of a message and its capacity for
	869	understanding further HTTP communication, rather than the features
	870	obtained via that communication. No change is made to the version
	871	number for the addition of message components which do not affect
	872	communication behavior or which only add to extensible field values.
	873	The <minor> number is incremented when the changes made to the
	874	protocol add features which do not change the general message parsing
	875	algorithm, but which may add to the message semantics and imply
	876	additional capabilities of the sender. The <major> number is
	877	incremented when the format of a message within the protocol is
	878	changed. See [RFC2145] for a fuller explanation.
	879
	880	The version of an HTTP message is indicated by an HTTP-Version field
	881	in the first line of the message. HTTP-Version is case-sensitive.
	882
	883	HTTP-Version = HTTP-Prot-Name "/" 1DIGIT "." 1DIGIT
	884	HTTP-Prot-Name = %x48.54.54.50 ; "HTTP", case-sensitive
	885
	886	Note that the major and minor numbers MUST be treated as separate
	887	integers and that each MAY be incremented higher than a single digit.
	888	Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is
	889	lower than HTTP/12.3. Leading zeros MUST be ignored by recipients
	890	and MUST NOT be sent.
	891
	892
	893
	894
	895	Fielding, et al. Expires March 2, 2009 [Page 16]
	896
	897	Internet-Draft HTTP/1.1, Part 1 August 2008
	898
	899
	900	An application that sends a request or response message that includes
	901	HTTP-Version of "HTTP/1.1" MUST be at least conditionally compliant
	902	with this specification. Applications that are at least
	903	conditionally compliant with this specification SHOULD use an HTTP-
	904	Version of "HTTP/1.1" in their messages, and MUST do so for any
	905	message that is not compatible with HTTP/1.0. For more details on
	906	when to send specific HTTP-Version values, see [RFC2145].
	907
	908	The HTTP version of an application is the highest HTTP version for
	909	which the application is at least conditionally compliant.
	910
	911	Proxy and gateway applications need to be careful when forwarding
	912	messages in protocol versions different from that of the application.
	913	Since the protocol version indicates the protocol capability of the
	914	sender, a proxy/gateway MUST NOT send a message with a version
	915	indicator which is greater than its actual version. If a higher
	916	version request is received, the proxy/gateway MUST either downgrade
	917	the request version, or respond with an error, or switch to tunnel
	918	behavior.
	919
	920	Due to interoperability problems with HTTP/1.0 proxies discovered
	921	since the publication of [RFC2068], caching proxies MUST, gateways
	922	MAY, and tunnels MUST NOT upgrade the request to the highest version
	923	they support. The proxy/gateway's response to that request MUST be
	924	in the same major version as the request.
	925
	926	Note: Converting between versions of HTTP may involve modification
	927	of header fields required or forbidden by the versions involved.
	928
	929	3.2. Uniform Resource Identifiers
	930
	931	URIs have been known by many names: WWW addresses, Universal Document
	932	Identifiers, Universal Resource Identifiers [RFC1630], and finally
	933	the combination of Uniform Resource Locators (URL) [RFC1738] and
	934	Names (URN) [RFC1737]. As far as HTTP is concerned, Uniform Resource
	935	Identifiers are simply formatted strings which identify--via name,
	936	location, or any other characteristic--a resource.
	937
	938	3.2.1. General Syntax
	939
	940	URIs in HTTP can be represented in absolute form or relative to some
	941	known base URI [RFC1808], depending upon the context of their use.
	942	The two forms are differentiated by the fact that absolute URIs
	943	always begin with a scheme name followed by a colon. For definitive
	944	information on URL syntax and semantics, see "Uniform Resource
	945	Identifiers (URI): Generic Syntax and Semantics," [RFC2396] (which
	946	replaces [RFC1738] and [RFC1808]). This specification adopts the
	947	definitions of "URI-reference", "absoluteURI", "fragment",
	948
	949
	950
	951	Fielding, et al. Expires March 2, 2009 [Page 17]
	952
	953	Internet-Draft HTTP/1.1, Part 1 August 2008
	954
	955
	956	"relativeURI", "port", "host", "abs_path", "query", and "authority"
	957	from that specification:
	958
	959	absoluteURI = <absoluteURI, defined in [RFC2396], Section 3>
	960	authority = <authority, defined in [RFC2396], Section 3.2>
	961	fragment = <fragment, defined in [RFC2396], Section 4.1>
	962	path-absolute = <abs_path, defined in [RFC2396], Section 3>
	963	port = <port, defined in [RFC2396], Section 3.2.2>
	964	query = <query, defined in [RFC2396], Section 3.4>
	965	relativeURI = <relativeURI, defined in [RFC2396], Section 5>
	966	uri-host = <host, defined in [RFC2396], Section 3.2.2>
	967
	968	HTTP does not place any a priori limit on the length of a URI.
	969	Servers MUST be able to handle the URI of any resource they serve,
	970	and SHOULD be able to handle URIs of unbounded length if they provide
	971	GET-based forms that could generate such URIs. A server SHOULD
	972	return 414 (Request-URI Too Long) status if a URI is longer than the
	973	server can handle (see Section 9.4.15 of [Part2]).
	974
	975	Note: Servers ought to be cautious about depending on URI lengths
	976	above 255 bytes, because some older client or proxy
	977	implementations might not properly support these lengths.
	978
	979	3.2.2. http URL
	980
	981	The "http" scheme is used to locate network resources via the HTTP
	982	protocol. This section defines the scheme-specific syntax and
	983	semantics for http URLs.
	984
	985	http-URL = "http:" "//" uri-host [ ":" port ]
	986	[ path-absolute [ "?" query ]]
	987
	988	If the port is empty or not given, port 80 is assumed. The semantics
	989	are that the identified resource is located at the server listening
	990	for TCP connections on that port of that host, and the Request-URI
	991	for the resource is path-absolute (Section 5.1.2). The use of IP
	992	addresses in URLs SHOULD be avoided whenever possible (see
	993	[RFC1900]). If the path-absolute is not present in the URL, it MUST
	994	be given as "/" when used as a Request-URI for a resource
	995	(Section 5.1.2). If a proxy receives a host name which is not a
	996	fully qualified domain name, it MAY add its domain to the host name
	997	it received. If a proxy receives a fully qualified domain name, the
	998	proxy MUST NOT change the host name.
	999
	1000	Note: the "https" scheme is defined in [RFC2818].
	1001
	1002
	1003
	1004
	1005
	1006
	1007	Fielding, et al. Expires March 2, 2009 [Page 18]
	1008
	1009	Internet-Draft HTTP/1.1, Part 1 August 2008
	1010
	1011
	1012	3.2.3. URI Comparison
	1013
	1014	When comparing two URIs to decide if they match or not, a client
	1015	SHOULD use a case-sensitive octet-by-octet comparison of the entire
	1016	URIs, with these exceptions:
	1017
	1018	o A port that is empty or not given is equivalent to the default
	1019	port for that URI-reference;
	1020
	1021	o Comparisons of host names MUST be case-insensitive;
	1022
	1023	o Comparisons of scheme names MUST be case-insensitive;
	1024
	1025	o An empty path-absolute is equivalent to an path-absolute of "/".
	1026
	1027	Characters other than those in the "reserved" set (see [RFC2396],
	1028	Section 2.2) are equivalent to their ""%" HEXDIG HEXDIG" encoding.
	1029
	1030	For example, the following three URIs are equivalent:
	1031
	1032	http://example.com:80/~smith/home.html
	1033	http://EXAMPLE.com/%7Esmith/home.html
	1034	http://EXAMPLE.com:/%7esmith/home.html
	1035
	1036	3.3. Date/Time Formats
	1037
	1038	3.3.1. Full Date
	1039
	1040	HTTP applications have historically allowed three different formats
	1041	for the representation of date/time stamps:
	1042
	1043	Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123
	1044	Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format
	1045	Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format
	1046
	1047	The first format is preferred as an Internet standard and represents
	1048	a fixed-length subset of that defined by [RFC1123] (an update to
	1049	[RFC822]). The other formats are described here only for
	1050	compatibility with obsolete implementations. HTTP/1.1 clients and
	1051	servers that parse the date value MUST accept all three formats (for
	1052	compatibility with HTTP/1.0), though they MUST only generate the RFC
	1053	1123 format for representing HTTP-date values in header fields. See
	1054	Appendix A for further information.
	1055
	1056	Note: Recipients of date values are encouraged to be robust in
	1057	accepting date values that may have been sent by non-HTTP
	1058	applications, as is sometimes the case when retrieving or posting
	1059	messages via proxies/gateways to SMTP or NNTP.
	1060
	1061
	1062
	1063	Fielding, et al. Expires March 2, 2009 [Page 19]
	1064
	1065	Internet-Draft HTTP/1.1, Part 1 August 2008
	1066
	1067
	1068	All HTTP date/time stamps MUST be represented in Greenwich Mean Time
	1069	(GMT), without exception. For the purposes of HTTP, GMT is exactly
	1070	equal to UTC (Coordinated Universal Time). This is indicated in the
	1071	first two formats by the inclusion of "GMT" as the three-letter
	1072	abbreviation for time zone, and MUST be assumed when reading the
	1073	asctime format. HTTP-date is case sensitive and MUST NOT include
	1074	additional LWS beyond that specifically included as SP in the
	1075	grammar.
	1076
	1077	HTTP-date = rfc1123-date \| obsolete-date
	1078	obsolete-date = rfc850-date \| asctime-date
	1079	rfc1123-date = wkday "," SP date1 SP time SP GMT
	1080	rfc850-date = weekday "," SP date2 SP time SP GMT
	1081	asctime-date = wkday SP date3 SP time SP 4DIGIT
	1082	date1 = 2DIGIT SP month SP 4DIGIT
	1083	; day month year (e.g., 02 Jun 1982)
	1084	date2 = 2DIGIT "-" month "-" 2DIGIT
	1085	; day-month-year (e.g., 02-Jun-82)
	1086	date3 = month SP ( 2DIGIT \| ( SP 1DIGIT ))
	1087	; month day (e.g., Jun 2)
	1088	time = 2DIGIT ":" 2DIGIT ":" 2DIGIT
	1089	; 00:00:00 - 23:59:59
	1090	wkday = s-Mon \| s-Tue \| s-Wed
	1091	\| s-Thu \| s-Fri \| s-Sat \| s-Sun
	1092	weekday = l-Mon \| l-Tue \| l-Wed
	1093	\| l-Thu \| l-Fri \| l-Sat \| l-Sun
	1094	month = s-Jan \| s-Feb \| s-Mar \| s-Apr
	1095	\| s-May \| s-Jun \| s-Jul \| s-Aug
	1096	\| s-Sep \| s-Oct \| s-Nov \| s-Dec
	1097
	1098	GMT = %x47.4D.54 ; "GMT", case-sensitive
	1099
	1100	s-Mon = %x4D.6F.6E ; "Mon", case-sensitive
	1101	s-Tue = %x54.75.65 ; "Tue", case-sensitive
	1102	s-Wed = %x57.65.64 ; "Wed", case-sensitive
	1103	s-Thu = %x54.68.75 ; "Thu", case-sensitive
	1104	s-Fri = %x46.72.69 ; "Fri", case-sensitive
	1105	s-Sat = %x53.61.74 ; "Sat", case-sensitive
	1106	s-Sun = %x53.75.6E ; "Sun", case-sensitive
	1107
	1108	l-Mon = %x4D.6F.6E.64.61.79 ; "Monday", case-sensitive
	1109	l-Tue = %x54.75.65.73.64.61.79 ; "Tuesday", case-sensitive
	1110	l-Wed = %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive
	1111	l-Thu = %x54.68.75.72.73.64.61.79 ; "Thursday", case-sensitive
	1112	l-Fri = %x46.72.69.64.61.79 ; "Friday", case-sensitive
	1113	l-Sat = %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive
	1114	l-Sun = %x53.75.6E.64.61.79 ; "Sunday", case-sensitive
	1115
	1116
	1117
	1118
	1119	Fielding, et al. Expires March 2, 2009 [Page 20]
	1120
	1121	Internet-Draft HTTP/1.1, Part 1 August 2008
	1122
	1123
	1124	s-Jan = %x4A.61.6E ; "Jan", case-sensitive
	1125	s-Feb = %x46.65.62 ; "Feb", case-sensitive
	1126	s-Mar = %x4D.61.72 ; "Mar", case-sensitive
	1127	s-Apr = %x41.70.72 ; "Apr", case-sensitive
	1128	s-May = %x4D.61.79 ; "May", case-sensitive
	1129	s-Jun = %x4A.75.6E ; "Jun", case-sensitive
	1130	s-Jul = %x4A.75.6C ; "Jul", case-sensitive
	1131	s-Aug = %x41.75.67 ; "Aug", case-sensitive
	1132	s-Sep = %x53.65.70 ; "Sep", case-sensitive
	1133	s-Oct = %x4F.63.74 ; "Oct", case-sensitive
	1134	s-Nov = %x4E.6F.76 ; "Nov", case-sensitive
	1135	s-Dec = %x44.65.63 ; "Dec", case-sensitive
	1136
	1137	Note: HTTP requirements for the date/time stamp format apply only to
	1138	their usage within the protocol stream. Clients and servers are not
	1139	required to use these formats for user presentation, request logging,
	1140	etc.
	1141
	1142	3.4. Transfer Codings
	1143
	1144	Transfer-coding values are used to indicate an encoding
	1145	transformation that has been, can be, or may need to be applied to an
	1146	entity-body in order to ensure "safe transport" through the network.
	1147	This differs from a content coding in that the transfer-coding is a
	1148	property of the message, not of the original entity.
	1149
	1150	transfer-coding = "chunked" \| transfer-extension
	1151	transfer-extension = token *( ";" parameter )
	1152
	1153	Parameters are in the form of attribute/value pairs.
	1154
	1155	parameter = attribute "=" value
	1156	attribute = token
	1157	value = token \| quoted-string
	1158
	1159	All transfer-coding values are case-insensitive. HTTP/1.1 uses
	1160	transfer-coding values in the TE header field (Section 8.5) and in
	1161	the Transfer-Encoding header field (Section 8.7).
	1162
	1163	Whenever a transfer-coding is applied to a message-body, the set of
	1164	transfer-codings MUST include "chunked", unless the message indicates
	1165	it is terminated by closing the connection. When the "chunked"
	1166	transfer-coding is used, it MUST be the last transfer-coding applied
	1167	to the message-body. The "chunked" transfer-coding MUST NOT be
	1168	applied more than once to a message-body. These rules allow the
	1169	recipient to determine the transfer-length of the message
	1170	(Section 4.4).
	1171
	1172
	1173
	1174
	1175	Fielding, et al. Expires March 2, 2009 [Page 21]
	1176
	1177	Internet-Draft HTTP/1.1, Part 1 August 2008
	1178
	1179
	1180	Transfer-codings are analogous to the Content-Transfer-Encoding
	1181	values of MIME [RFC2045], which were designed to enable safe
	1182	transport of binary data over a 7-bit transport service. However,
	1183	safe transport has a different focus for an 8bit-clean transfer
	1184	protocol. In HTTP, the only unsafe characteristic of message-bodies
	1185	is the difficulty in determining the exact body length (Section 4.4),
	1186	or the desire to encrypt data over a shared transport.
	1187
	1188	The Internet Assigned Numbers Authority (IANA) acts as a registry for
	1189	transfer-coding value tokens. Initially, the registry contains the
	1190	following tokens: "chunked" (Section 3.4.1), "gzip", "compress", and
	1191	"deflate" (Section 3.2 of [Part3]).
	1192
	1193	New transfer-coding value tokens SHOULD be registered in the same way
	1194	as new content-coding value tokens (Section 3.2 of [Part3]).
	1195
	1196	A server which receives an entity-body with a transfer-coding it does
	1197	not understand SHOULD return 501 (Not Implemented), and close the
	1198	connection. A server MUST NOT send transfer-codings to an HTTP/1.0
	1199	client.
	1200
	1201	3.4.1. Chunked Transfer Coding
	1202
	1203	The chunked encoding modifies the body of a message in order to
	1204	transfer it as a series of chunks, each with its own size indicator,
	1205	followed by an OPTIONAL trailer containing entity-header fields.
	1206	This allows dynamically produced content to be transferred along with
	1207	the information necessary for the recipient to verify that it has
	1208	received the full message.
	1209
	1210	Chunked-Body = *chunk
	1211	last-chunk
	1212	trailer-part
	1213	CRLF
	1214
	1215	chunk = chunk-size [ chunk-extension ] CRLF
	1216	chunk-data CRLF
	1217	chunk-size = 1*HEXDIG
	1218	last-chunk = 1*("0") [ chunk-extension ] CRLF
	1219
	1220	chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
	1221	chunk-ext-name = token
	1222	chunk-ext-val = token \| quoted-string
	1223	chunk-data = 1*OCTET ; a sequence of chunk-size octets
	1224	trailer-part = *(entity-header CRLF)
	1225
	1226	The chunk-size field is a string of hex digits indicating the size of
	1227	the chunk-data in octets. The chunked encoding is ended by any chunk
	1228
	1229
	1230
	1231	Fielding, et al. Expires March 2, 2009 [Page 22]
	1232
	1233	Internet-Draft HTTP/1.1, Part 1 August 2008
	1234
	1235
	1236	whose size is zero, followed by the trailer, which is terminated by
	1237	an empty line.
	1238
	1239	The trailer allows the sender to include additional HTTP header
	1240	fields at the end of the message. The Trailer header field can be
	1241	used to indicate which header fields are included in a trailer (see
	1242	Section 8.6).
	1243
	1244	A server using chunked transfer-coding in a response MUST NOT use the
	1245	trailer for any header fields unless at least one of the following is
	1246	true:
	1247
	1248	1. the request included a TE header field that indicates "trailers"
	1249	is acceptable in the transfer-coding of the response, as
	1250	described in Section 8.5; or,
	1251
	1252	2. the server is the origin server for the response, the trailer
	1253	fields consist entirely of optional metadata, and the recipient
	1254	could use the message (in a manner acceptable to the origin
	1255	server) without receiving this metadata. In other words, the
	1256	origin server is willing to accept the possibility that the
	1257	trailer fields might be silently discarded along the path to the
	1258	client.
	1259
	1260	This requirement prevents an interoperability failure when the
	1261	message is being received by an HTTP/1.1 (or later) proxy and
	1262	forwarded to an HTTP/1.0 recipient. It avoids a situation where
	1263	compliance with the protocol would have necessitated a possibly
	1264	infinite buffer on the proxy.
	1265
	1266	A process for decoding the "chunked" transfer-coding can be
	1267	represented in pseudo-code as:
	1268
	1269	length := 0
	1270	read chunk-size, chunk-extension (if any) and CRLF
	1271	while (chunk-size > 0) {
	1272	read chunk-data and CRLF
	1273	append chunk-data to entity-body
	1274	length := length + chunk-size
	1275	read chunk-size and CRLF
	1276	}
	1277	read entity-header
	1278	while (entity-header not empty) {
	1279	append entity-header to existing header fields
	1280	read entity-header
	1281	}
	1282	Content-Length := length
	1283	Remove "chunked" from Transfer-Encoding
	1284
	1285
	1286
	1287	Fielding, et al. Expires March 2, 2009 [Page 23]
	1288
	1289	Internet-Draft HTTP/1.1, Part 1 August 2008
	1290
	1291
	1292	All HTTP/1.1 applications MUST be able to receive and decode the
	1293	"chunked" transfer-coding, and MUST ignore chunk-extension extensions
	1294	they do not understand.
	1295
	1296	3.5. Product Tokens
	1297
	1298	Product tokens are used to allow communicating applications to
	1299	identify themselves by software name and version. Most fields using
	1300	product tokens also allow sub-products which form a significant part
	1301	of the application to be listed, separated by white space. By
	1302	convention, the products are listed in order of their significance
	1303	for identifying the application.
	1304
	1305	product = token ["/" product-version]
	1306	product-version = token
	1307
	1308	Examples:
	1309
	1310	User-Agent: CERN-LineMode/2.15 libwww/2.17b3
	1311	Server: Apache/0.8.4
	1312
	1313	Product tokens SHOULD be short and to the point. They MUST NOT be
	1314	used for advertising or other non-essential information. Although
	1315	any token character MAY appear in a product-version, this token
	1316	SHOULD only be used for a version identifier (i.e., successive
	1317	versions of the same product SHOULD only differ in the product-
	1318	version portion of the product value).
	1319
	1320
	1321	4. HTTP Message
	1322
	1323	4.1. Message Types
	1324
	1325	HTTP messages consist of requests from client to server and responses
	1326	from server to client.
	1327
	1328	HTTP-message = Request \| Response ; HTTP/1.1 messages
	1329
	1330	Request (Section 5) and Response (Section 6) messages use the generic
	1331	message format of [RFC2822] for transferring entities (the payload of
	1332	the message). Both types of message consist of a start-line, zero or
	1333	more header fields (also known as "headers"), an empty line (i.e., a
	1334	line with nothing preceding the CRLF) indicating the end of the
	1335	header fields, and possibly a message-body.
	1336
	1337
	1338
	1339
	1340
	1341
	1342
	1343	Fielding, et al. Expires March 2, 2009 [Page 24]
	1344
	1345	Internet-Draft HTTP/1.1, Part 1 August 2008
	1346
	1347
	1348	generic-message = start-line
	1349	*(message-header CRLF)
	1350	CRLF
	1351	[ message-body ]
	1352	start-line = Request-Line \| Status-Line
	1353
	1354	In the interest of robustness, servers SHOULD ignore any empty
	1355	line(s) received where a Request-Line is expected. In other words,
	1356	if the server is reading the protocol stream at the beginning of a
	1357	message and receives a CRLF first, it should ignore the CRLF.
	1358
	1359	Certain buggy HTTP/1.0 client implementations generate extra CRLF's
	1360	after a POST request. To restate what is explicitly forbidden by the
	1361	BNF, an HTTP/1.1 client MUST NOT preface or follow a request with an
	1362	extra CRLF.
	1363
	1364	4.2. Message Headers
	1365
	1366	HTTP header fields, which include general-header (Section 4.5),
	1367	request-header (Section 4 of [Part2]), response-header (Section 6 of
	1368	[Part2]), and entity-header (Section 4.1 of [Part3]) fields, follow
	1369	the same generic format as that given in Section 2.1 of [RFC2822].
	1370	Each header field consists of a name followed by a colon (":") and
	1371	the field value. Field names are case-insensitive. The field value
	1372	MAY be preceded by any amount of LWS, though a single SP is
	1373	preferred. Header fields can be extended over multiple lines by
	1374	preceding each extra line with at least one SP or HTAB. Applications
	1375	ought to follow "common form", where one is known or indicated, when
	1376	generating HTTP constructs, since there might exist some
	1377	implementations that fail to accept anything beyond the common forms.
	1378
	1379	message-header = field-name ":" [ field-value ]
	1380	field-name = token
	1381	field-value = *( field-content \| LWS )
	1382	field-content = <field content>
	1383	; the OCTETs making up the field-value
	1384	; and consisting of either *TEXT or combinations
	1385	; of token, separators, and quoted-string
	1386
	1387	The field-content does not include any leading or trailing LWS:
	1388	linear white space occurring before the first non-whitespace
	1389	character of the field-value or after the last non-whitespace
	1390	character of the field-value. Such leading or trailing LWS MAY be
	1391	removed without changing the semantics of the field value. Any LWS
	1392	that occurs between field-content MAY be replaced with a single SP
	1393	before interpreting the field value or forwarding the message
	1394	downstream.
	1395
	1396
	1397
	1398
	1399	Fielding, et al. Expires March 2, 2009 [Page 25]
	1400
	1401	Internet-Draft HTTP/1.1, Part 1 August 2008
	1402
	1403
	1404	The order in which header fields with differing field names are
	1405	received is not significant. However, it is "good practice" to send
	1406	general-header fields first, followed by request-header or response-
	1407	header fields, and ending with the entity-header fields.
	1408
	1409	Multiple message-header fields with the same field-name MAY be
	1410	present in a message if and only if the entire field-value for that
	1411	header field is defined as a comma-separated list [i.e., #(values)].
	1412	It MUST be possible to combine the multiple header fields into one
	1413	"field-name: field-value" pair, without changing the semantics of the
	1414	message, by appending each subsequent field-value to the first, each
	1415	separated by a comma. The order in which header fields with the same
	1416	field-name are received is therefore significant to the
	1417	interpretation of the combined field value, and thus a proxy MUST NOT
	1418	change the order of these field values when a message is forwarded.
	1419
	1420	Note: the "Set-Cookie" header as implemented in practice (as
	1421	opposed to how it is specified in [RFC2109]) can occur multiple
	1422	times, but does not use the list syntax, and thus cannot be
	1423	combined into a single line. (See Appendix A.2.3 of [Kri2001] for
	1424	details.) Also note that the Set-Cookie2 header specified in
	1425	[RFC2965] does not share this problem.
	1426
	1427	4.3. Message Body
	1428
	1429	The message-body (if any) of an HTTP message is used to carry the
	1430	entity-body associated with the request or response. The message-
	1431	body differs from the entity-body only when a transfer-coding has
	1432	been applied, as indicated by the Transfer-Encoding header field
	1433	(Section 8.7).
	1434
	1435	message-body = entity-body
	1436	\| <entity-body encoded as per Transfer-Encoding>
	1437
	1438	Transfer-Encoding MUST be used to indicate any transfer-codings
	1439	applied by an application to ensure safe and proper transfer of the
	1440	message. Transfer-Encoding is a property of the message, not of the
	1441	entity, and thus MAY be added or removed by any application along the
	1442	request/response chain. (However, Section 3.4 places restrictions on
	1443	when certain transfer-codings may be used.)
	1444
	1445	The rules for when a message-body is allowed in a message differ for
	1446	requests and responses.
	1447
	1448	The presence of a message-body in a request is signaled by the
	1449	inclusion of a Content-Length or Transfer-Encoding header field in
	1450	the request's message-headers. A message-body MUST NOT be included
	1451	in a request if the specification of the request method (Section 3 of
	1452
	1453
	1454
	1455	Fielding, et al. Expires March 2, 2009 [Page 26]
	1456
	1457	Internet-Draft HTTP/1.1, Part 1 August 2008
	1458
	1459
	1460	[Part2]) explicitly disallows an entity-body in requests. When a
	1461	request message contains both a message-body of non-zero length and a
	1462	method that does not define any semantics for that request message-
	1463	body, then an origin server SHOULD either ignore the message-body or
	1464	respond with an appropriate error message (e.g., 413). A proxy or
	1465	gateway, when presented the same request, SHOULD either forward the
	1466	request inbound with the message-body or ignore the message-body when
	1467	determining a response.
	1468
	1469	For response messages, whether or not a message-body is included with
	1470	a message is dependent on both the request method and the response
	1471	status code (Section 6.1.1). All responses to the HEAD request
	1472	method MUST NOT include a message-body, even though the presence of
	1473	entity-header fields might lead one to believe they do. All 1xx
	1474	(informational), 204 (No Content), and 304 (Not Modified) responses
	1475	MUST NOT include a message-body. All other responses do include a
	1476	message-body, although it MAY be of zero length.
	1477
	1478	4.4. Message Length
	1479
	1480	The transfer-length of a message is the length of the message-body as
	1481	it appears in the message; that is, after any transfer-codings have
	1482	been applied. When a message-body is included with a message, the
	1483	transfer-length of that body is determined by one of the following
	1484	(in order of precedence):
	1485
	1486	1. Any response message which "MUST NOT" include a message-body
	1487	(such as the 1xx, 204, and 304 responses and any response to a
	1488	HEAD request) is always terminated by the first empty line after
	1489	the header fields, regardless of the entity-header fields present
	1490	in the message.
	1491
	1492	2. If a Transfer-Encoding header field (Section 8.7) is present and
	1493	the "chunked" transfer-coding (Section 3.4) is used, the
	1494	transfer-length is defined by the use of this transfer-coding.
	1495	If a Transfer-Encoding header field is present and the "chunked"
	1496	transfer-coding is not present, the transfer-length is defined by
	1497	the sender closing the connection.
	1498
	1499	3. If a Content-Length header field (Section 8.2) is present, its
	1500	decimal value in OCTETs represents both the entity-length and the
	1501	transfer-length. The Content-Length header field MUST NOT be
	1502	sent if these two lengths are different (i.e., if a Transfer-
	1503	Encoding header field is present). If a message is received with
	1504	both a Transfer-Encoding header field and a Content-Length header
	1505	field, the latter MUST be ignored.
	1506
	1507
	1508
	1509
	1510
	1511	Fielding, et al. Expires March 2, 2009 [Page 27]
	1512
	1513	Internet-Draft HTTP/1.1, Part 1 August 2008
	1514
	1515
	1516	4. If the message uses the media type "multipart/byteranges", and
	1517	the transfer-length is not otherwise specified, then this self-
	1518	delimiting media type defines the transfer-length. This media
	1519	type MUST NOT be used unless the sender knows that the recipient
	1520	can parse it; the presence in a request of a Range header with
	1521	multiple byte-range specifiers from a 1.1 client implies that the
	1522	client can parse multipart/byteranges responses.
	1523
	1524	A range header might be forwarded by a 1.0 proxy that does not
	1525	understand multipart/byteranges; in this case the server MUST
	1526	delimit the message using methods defined in items 1, 3 or 5
	1527	of this section.
	1528
	1529	5. By the server closing the connection. (Closing the connection
	1530	cannot be used to indicate the end of a request body, since that
	1531	would leave no possibility for the server to send back a
	1532	response.)
	1533
	1534	For compatibility with HTTP/1.0 applications, HTTP/1.1 requests
	1535	containing a message-body MUST include a valid Content-Length header
	1536	field unless the server is known to be HTTP/1.1 compliant. If a
	1537	request contains a message-body and a Content-Length is not given,
	1538	the server SHOULD respond with 400 (Bad Request) if it cannot
	1539	determine the length of the message, or with 411 (Length Required) if
	1540	it wishes to insist on receiving a valid Content-Length.
	1541
	1542	All HTTP/1.1 applications that receive entities MUST accept the
	1543	"chunked" transfer-coding (Section 3.4), thus allowing this mechanism
	1544	to be used for messages when the message length cannot be determined
	1545	in advance.
	1546
	1547	Messages MUST NOT include both a Content-Length header field and a
	1548	transfer-coding. If the message does include a transfer-coding, the
	1549	Content-Length MUST be ignored.
	1550
	1551	When a Content-Length is given in a message where a message-body is
	1552	allowed, its field value MUST exactly match the number of OCTETs in
	1553	the message-body. HTTP/1.1 user agents MUST notify the user when an
	1554	invalid length is received and detected.
	1555
	1556	4.5. General Header Fields
	1557
	1558	There are a few header fields which have general applicability for
	1559	both request and response messages, but which do not apply to the
	1560	entity being transferred. These header fields apply only to the
	1561	message being transmitted.
	1562
	1563
	1564
	1565
	1566
	1567	Fielding, et al. Expires March 2, 2009 [Page 28]
	1568
	1569	Internet-Draft HTTP/1.1, Part 1 August 2008
	1570
	1571
	1572	general-header = Cache-Control ; [Part6], Section 16.2
	1573	\| Connection ; Section 8.1
	1574	\| Date ; Section 8.3
	1575	\| Pragma ; [Part6], Section 16.4
	1576	\| Trailer ; Section 8.6
	1577	\| Transfer-Encoding ; Section 8.7
	1578	\| Upgrade ; Section 8.8
	1579	\| Via ; Section 8.9
	1580	\| Warning ; [Part6], Section 16.6
	1581
	1582	General-header field names can be extended reliably only in
	1583	combination with a change in the protocol version. However, new or
	1584	experimental header fields may be given the semantics of general
	1585	header fields if all parties in the communication recognize them to
	1586	be general-header fields. Unrecognized header fields are treated as
	1587	entity-header fields.
	1588
	1589
	1590	5. Request
	1591
	1592	A request message from a client to a server includes, within the
	1593	first line of that message, the method to be applied to the resource,
	1594	the identifier of the resource, and the protocol version in use.
	1595
	1596	Request = Request-Line ; Section 5.1
	1597	*(( general-header ; Section 4.5
	1598	\| request-header ; [Part2], Section 4
	1599	\| entity-header ) CRLF) ; [Part3], Section 4.1
	1600	CRLF
	1601	[ message-body ] ; Section 4.3
	1602
	1603	5.1. Request-Line
	1604
	1605	The Request-Line begins with a method token, followed by the Request-
	1606	URI and the protocol version, and ending with CRLF. The elements are
	1607	separated by SP characters. No CR or LF is allowed except in the
	1608	final CRLF sequence.
	1609
	1610	Request-Line = Method SP Request-URI SP HTTP-Version CRLF
	1611
	1612	5.1.1. Method
	1613
	1614	The Method token indicates the method to be performed on the resource
	1615	identified by the Request-URI. The method is case-sensitive.
	1616
	1617	Method = token
	1618
	1619
	1620
	1621
	1622
	1623	Fielding, et al. Expires March 2, 2009 [Page 29]
	1624
	1625	Internet-Draft HTTP/1.1, Part 1 August 2008
	1626
	1627
	1628	5.1.2. Request-URI
	1629
	1630	The Request-URI is a Uniform Resource Identifier (Section 3.2) and
	1631	identifies the resource upon which to apply the request.
	1632
	1633	Request-URI = "*"
	1634	\| absoluteURI
	1635	\| ( path-absolute [ "?" query ] )
	1636	\| authority
	1637
	1638	The four options for Request-URI are dependent on the nature of the
	1639	request. The asterisk "*" means that the request does not apply to a
	1640	particular resource, but to the server itself, and is only allowed
	1641	when the method used does not necessarily apply to a resource. One
	1642	example would be
	1643
	1644	OPTIONS * HTTP/1.1
	1645
	1646	The absoluteURI form is REQUIRED when the request is being made to a
	1647	proxy. The proxy is requested to forward the request or service it
	1648	from a valid cache, and return the response. Note that the proxy MAY
	1649	forward the request on to another proxy or directly to the server
	1650	specified by the absoluteURI. In order to avoid request loops, a
	1651	proxy MUST be able to recognize all of its server names, including
	1652	any aliases, local variations, and the numeric IP address. An
	1653	example Request-Line would be:
	1654
	1655	GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1
	1656
	1657	To allow for transition to absoluteURIs in all requests in future
	1658	versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI
	1659	form in requests, even though HTTP/1.1 clients will only generate
	1660	them in requests to proxies.
	1661
	1662	The authority form is only used by the CONNECT method (Section 8.9 of
	1663	[Part2]).
	1664
	1665	The most common form of Request-URI is that used to identify a
	1666	resource on an origin server or gateway. In this case the absolute
	1667	path of the URI MUST be transmitted (see Section 3.2.1, path-
	1668	absolute) as the Request-URI, and the network location of the URI
	1669	(authority) MUST be transmitted in a Host header field. For example,
	1670	a client wishing to retrieve the resource above directly from the
	1671	origin server would create a TCP connection to port 80 of the host
	1672	"www.example.org" and send the lines:
	1673
	1674	GET /pub/WWW/TheProject.html HTTP/1.1
	1675	Host: www.example.org
	1676
	1677
	1678
	1679	Fielding, et al. Expires March 2, 2009 [Page 30]
	1680
	1681	Internet-Draft HTTP/1.1, Part 1 August 2008
	1682
	1683
	1684	followed by the remainder of the Request. Note that the absolute
	1685	path cannot be empty; if none is present in the original URI, it MUST
	1686	be given as "/" (the server root).
	1687
	1688	The Request-URI is transmitted in the format specified in
	1689	Section 3.2.1. If the Request-URI is encoded using the "% HEXDIG
	1690	HEXDIG" encoding ([RFC2396], Section 2.4.1), the origin server MUST
	1691	decode the Request-URI in order to properly interpret the request.
	1692	Servers SHOULD respond to invalid Request-URIs with an appropriate
	1693	status code.
	1694
	1695	A transparent proxy MUST NOT rewrite the "path-absolute" part of the
	1696	received Request-URI when forwarding it to the next inbound server,
	1697	except as noted above to replace a null path-absolute with "/".
	1698
	1699	Note: The "no rewrite" rule prevents the proxy from changing the
	1700	meaning of the request when the origin server is improperly using
	1701	a non-reserved URI character for a reserved purpose. Implementors
	1702	should be aware that some pre-HTTP/1.1 proxies have been known to
	1703	rewrite the Request-URI.
	1704
	1705	5.2. The Resource Identified by a Request
	1706
	1707	The exact resource identified by an Internet request is determined by
	1708	examining both the Request-URI and the Host header field.
	1709
	1710	An origin server that does not allow resources to differ by the
	1711	requested host MAY ignore the Host header field value when
	1712	determining the resource identified by an HTTP/1.1 request. (But see
	1713	Appendix C.1.1 for other requirements on Host support in HTTP/1.1.)
	1714
	1715	An origin server that does differentiate resources based on the host
	1716	requested (sometimes referred to as virtual hosts or vanity host
	1717	names) MUST use the following rules for determining the requested
	1718	resource on an HTTP/1.1 request:
	1719
	1720	1. If Request-URI is an absoluteURI, the host is part of the
	1721	Request-URI. Any Host header field value in the request MUST be
	1722	ignored.
	1723
	1724	2. If the Request-URI is not an absoluteURI, and the request
	1725	includes a Host header field, the host is determined by the Host
	1726	header field value.
	1727
	1728	3. If the host as determined by rule 1 or 2 is not a valid host on
	1729	the server, the response MUST be a 400 (Bad Request) error
	1730	message.
	1731
	1732
	1733
	1734
	1735	Fielding, et al. Expires March 2, 2009 [Page 31]
	1736
	1737	Internet-Draft HTTP/1.1, Part 1 August 2008
	1738
	1739
	1740	Recipients of an HTTP/1.0 request that lacks a Host header field MAY
	1741	attempt to use heuristics (e.g., examination of the URI path for
	1742	something unique to a particular host) in order to determine what
	1743	exact resource is being requested.
	1744
	1745
	1746	6. Response
	1747
	1748	After receiving and interpreting a request message, a server responds
	1749	with an HTTP response message.
	1750
	1751	Response = Status-Line ; Section 6.1
	1752	*(( general-header ; Section 4.5
	1753	\| response-header ; [Part2], Section 6
	1754	\| entity-header ) CRLF) ; [Part3], Section 4.1
	1755	CRLF
	1756	[ message-body ] ; Section 4.3
	1757
	1758	6.1. Status-Line
	1759
	1760	The first line of a Response message is the Status-Line, consisting
	1761	of the protocol version followed by a numeric status code and its
	1762	associated textual phrase, with each element separated by SP
	1763	characters. No CR or LF is allowed except in the final CRLF
	1764	sequence.
	1765
	1766	Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
	1767
	1768	6.1.1. Status Code and Reason Phrase
	1769
	1770	The Status-Code element is a 3-digit integer result code of the
	1771	attempt to understand and satisfy the request. These codes are fully
	1772	defined in Section 9 of [Part2]. The Reason Phrase exists for the
	1773	sole purpose of providing a textual description associated with the
	1774	numeric status code, out of deference to earlier Internet application
	1775	protocols that were more frequently used with interactive text
	1776	clients. A client SHOULD ignore the content of the Reason Phrase.
	1777
	1778	The first digit of the Status-Code defines the class of response.
	1779	The last two digits do not have any categorization role. There are 5
	1780	values for the first digit:
	1781
	1782	o 1xx: Informational - Request received, continuing process
	1783
	1784	o 2xx: Success - The action was successfully received, understood,
	1785	and accepted
	1786
	1787
	1788
	1789
	1790
	1791	Fielding, et al. Expires March 2, 2009 [Page 32]
	1792
	1793	Internet-Draft HTTP/1.1, Part 1 August 2008
	1794
	1795
	1796	o 3xx: Redirection - Further action must be taken in order to
	1797	complete the request
	1798
	1799	o 4xx: Client Error - The request contains bad syntax or cannot be
	1800	fulfilled
	1801
	1802	o 5xx: Server Error - The server failed to fulfill an apparently
	1803	valid request
	1804
	1805
	1806	Status-Code = 3DIGIT
	1807	Reason-Phrase = *<TEXT, excluding CR, LF>
	1808
	1809
	1810	7. Connections
	1811
	1812	7.1. Persistent Connections
	1813
	1814	7.1.1. Purpose
	1815
	1816	Prior to persistent connections, a separate TCP connection was
	1817	established to fetch each URL, increasing the load on HTTP servers
	1818	and causing congestion on the Internet. The use of inline images and
	1819	other associated data often require a client to make multiple
	1820	requests of the same server in a short amount of time. Analysis of
	1821	these performance problems and results from a prototype
	1822	implementation are available [Pad1995] [Spe]. Implementation
	1823	experience and measurements of actual HTTP/1.1 (RFC 2068)
	1824	implementations show good results [Nie1997]. Alternatives have also
	1825	been explored, for example, T/TCP [Tou1998].
	1826
	1827	Persistent HTTP connections have a number of advantages:
	1828
	1829	o By opening and closing fewer TCP connections, CPU time is saved in
	1830	routers and hosts (clients, servers, proxies, gateways, tunnels,
	1831	or caches), and memory used for TCP protocol control blocks can be
	1832	saved in hosts.
	1833
	1834	o HTTP requests and responses can be pipelined on a connection.
	1835	Pipelining allows a client to make multiple requests without
	1836	waiting for each response, allowing a single TCP connection to be
	1837	used much more efficiently, with much lower elapsed time.
	1838
	1839	o Network congestion is reduced by reducing the number of packets
	1840	caused by TCP opens, and by allowing TCP sufficient time to
	1841	determine the congestion state of the network.
	1842
	1843
	1844
	1845
	1846
	1847	Fielding, et al. Expires March 2, 2009 [Page 33]
	1848
	1849	Internet-Draft HTTP/1.1, Part 1 August 2008
	1850
	1851
	1852	o Latency on subsequent requests is reduced since there is no time
	1853	spent in TCP's connection opening handshake.
	1854
	1855	o HTTP can evolve more gracefully, since errors can be reported
	1856	without the penalty of closing the TCP connection. Clients using
	1857	future versions of HTTP might optimistically try a new feature,
	1858	but if communicating with an older server, retry with old
	1859	semantics after an error is reported.
	1860
	1861	HTTP implementations SHOULD implement persistent connections.
	1862
	1863	7.1.2. Overall Operation
	1864
	1865	A significant difference between HTTP/1.1 and earlier versions of
	1866	HTTP is that persistent connections are the default behavior of any
	1867	HTTP connection. That is, unless otherwise indicated, the client
	1868	SHOULD assume that the server will maintain a persistent connection,
	1869	even after error responses from the server.
	1870
	1871	Persistent connections provide a mechanism by which a client and a
	1872	server can signal the close of a TCP connection. This signaling
	1873	takes place using the Connection header field (Section 8.1). Once a
	1874	close has been signaled, the client MUST NOT send any more requests
	1875	on that connection.
	1876
	1877	7.1.2.1. Negotiation
	1878
	1879	An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to
	1880	maintain a persistent connection unless a Connection header including
	1881	the connection-token "close" was sent in the request. If the server
	1882	chooses to close the connection immediately after sending the
	1883	response, it SHOULD send a Connection header including the
	1884	connection-token close.
	1885
	1886	An HTTP/1.1 client MAY expect a connection to remain open, but would
	1887	decide to keep it open based on whether the response from a server
	1888	contains a Connection header with the connection-token close. In
	1889	case the client does not want to maintain a connection for more than
	1890	that request, it SHOULD send a Connection header including the
	1891	connection-token close.
	1892
	1893	If either the client or the server sends the close token in the
	1894	Connection header, that request becomes the last one for the
	1895	connection.
	1896
	1897	Clients and servers SHOULD NOT assume that a persistent connection is
	1898	maintained for HTTP versions less than 1.1 unless it is explicitly
	1899	signaled. See Appendix C.2 for more information on backward
	1900
	1901
	1902
	1903	Fielding, et al. Expires March 2, 2009 [Page 34]
	1904
	1905	Internet-Draft HTTP/1.1, Part 1 August 2008
	1906
	1907
	1908	compatibility with HTTP/1.0 clients.
	1909
	1910	In order to remain persistent, all messages on the connection MUST
	1911	have a self-defined message length (i.e., one not defined by closure
	1912	of the connection), as described in Section 4.4.
	1913
	1914	7.1.2.2. Pipelining
	1915
	1916	A client that supports persistent connections MAY "pipeline" its
	1917	requests (i.e., send multiple requests without waiting for each
	1918	response). A server MUST send its responses to those requests in the
	1919	same order that the requests were received.
	1920
	1921	Clients which assume persistent connections and pipeline immediately
	1922	after connection establishment SHOULD be prepared to retry their
	1923	connection if the first pipelined attempt fails. If a client does
	1924	such a retry, it MUST NOT pipeline before it knows the connection is
	1925	persistent. Clients MUST also be prepared to resend their requests
	1926	if the server closes the connection before sending all of the
	1927	corresponding responses.
	1928
	1929	Clients SHOULD NOT pipeline requests using non-idempotent methods or
	1930	non-idempotent sequences of methods (see Section 8.1.2 of [Part2]).
	1931	Otherwise, a premature termination of the transport connection could
	1932	lead to indeterminate results. A client wishing to send a non-
	1933	idempotent request SHOULD wait to send that request until it has
	1934	received the response status for the previous request.
	1935
	1936	7.1.3. Proxy Servers
	1937
	1938	It is especially important that proxies correctly implement the
	1939	properties of the Connection header field as specified in
	1940	Section 8.1.
	1941
	1942	The proxy server MUST signal persistent connections separately with
	1943	its clients and the origin servers (or other proxy servers) that it
	1944	connects to. Each persistent connection applies to only one
	1945	transport link.
	1946
	1947	A proxy server MUST NOT establish a HTTP/1.1 persistent connection
	1948	with an HTTP/1.0 client (but see [RFC2068] for information and
	1949	discussion of the problems with the Keep-Alive header implemented by
	1950	many HTTP/1.0 clients).
	1951
	1952	7.1.4. Practical Considerations
	1953
	1954	Servers will usually have some time-out value beyond which they will
	1955	no longer maintain an inactive connection. Proxy servers might make
	1956
	1957
	1958
	1959	Fielding, et al. Expires March 2, 2009 [Page 35]
	1960
	1961	Internet-Draft HTTP/1.1, Part 1 August 2008
	1962
	1963
	1964	this a higher value since it is likely that the client will be making
	1965	more connections through the same server. The use of persistent
	1966	connections places no requirements on the length (or existence) of
	1967	this time-out for either the client or the server.
	1968
	1969	When a client or server wishes to time-out it SHOULD issue a graceful
	1970	close on the transport connection. Clients and servers SHOULD both
	1971	constantly watch for the other side of the transport close, and
	1972	respond to it as appropriate. If a client or server does not detect
	1973	the other side's close promptly it could cause unnecessary resource
	1974	drain on the network.
	1975
	1976	A client, server, or proxy MAY close the transport connection at any
	1977	time. For example, a client might have started to send a new request
	1978	at the same time that the server has decided to close the "idle"
	1979	connection. From the server's point of view, the connection is being
	1980	closed while it was idle, but from the client's point of view, a
	1981	request is in progress.
	1982
	1983	This means that clients, servers, and proxies MUST be able to recover
	1984	from asynchronous close events. Client software SHOULD reopen the
	1985	transport connection and retransmit the aborted sequence of requests
	1986	without user interaction so long as the request sequence is
	1987	idempotent (see Section 8.1.2 of [Part2]). Non-idempotent methods or
	1988	sequences MUST NOT be automatically retried, although user agents MAY
	1989	offer a human operator the choice of retrying the request(s).
	1990	Confirmation by user-agent software with semantic understanding of
	1991	the application MAY substitute for user confirmation. The automatic
	1992	retry SHOULD NOT be repeated if the second sequence of requests
	1993	fails.
	1994
	1995	Servers SHOULD always respond to at least one request per connection,
	1996	if at all possible. Servers SHOULD NOT close a connection in the
	1997	middle of transmitting a response, unless a network or client failure
	1998	is suspected.
	1999
	2000	Clients that use persistent connections SHOULD limit the number of
	2001	simultaneous connections that they maintain to a given server. A
	2002	single-user client SHOULD NOT maintain more than 2 connections with
	2003	any server or proxy. A proxy SHOULD use up to 2*N connections to
	2004	another server or proxy, where N is the number of simultaneously
	2005	active users. These guidelines are intended to improve HTTP response
	2006	times and avoid congestion.
	2007
	2008	7.2. Message Transmission Requirements
	2009
	2010
	2011
	2012
	2013
	2014
	2015	Fielding, et al. Expires March 2, 2009 [Page 36]
	2016
	2017	Internet-Draft HTTP/1.1, Part 1 August 2008
	2018
	2019
	2020	7.2.1. Persistent Connections and Flow Control
	2021
	2022	HTTP/1.1 servers SHOULD maintain persistent connections and use TCP's
	2023	flow control mechanisms to resolve temporary overloads, rather than
	2024	terminating connections with the expectation that clients will retry.
	2025	The latter technique can exacerbate network congestion.
	2026
	2027	7.2.2. Monitoring Connections for Error Status Messages
	2028
	2029	An HTTP/1.1 (or later) client sending a message-body SHOULD monitor
	2030	the network connection for an error status while it is transmitting
	2031	the request. If the client sees an error status, it SHOULD
	2032	immediately cease transmitting the body. If the body is being sent
	2033	using a "chunked" encoding (Section 3.4), a zero length chunk and
	2034	empty trailer MAY be used to prematurely mark the end of the message.
	2035	If the body was preceded by a Content-Length header, the client MUST
	2036	close the connection.
	2037
	2038	7.2.3. Use of the 100 (Continue) Status
	2039
	2040	The purpose of the 100 (Continue) status (see Section 9.1.1 of
	2041	[Part2]) is to allow a client that is sending a request message with
	2042	a request body to determine if the origin server is willing to accept
	2043	the request (based on the request headers) before the client sends
	2044	the request body. In some cases, it might either be inappropriate or
	2045	highly inefficient for the client to send the body if the server will
	2046	reject the message without looking at the body.
	2047
	2048	Requirements for HTTP/1.1 clients:
	2049
	2050	o If a client will wait for a 100 (Continue) response before sending
	2051	the request body, it MUST send an Expect request-header field
	2052	(Section 10.2 of [Part2]) with the "100-continue" expectation.
	2053
	2054	o A client MUST NOT send an Expect request-header field (Section
	2055	10.2 of [Part2]) with the "100-continue" expectation if it does
	2056	not intend to send a request body.
	2057
	2058	Because of the presence of older implementations, the protocol allows
	2059	ambiguous situations in which a client may send "Expect: 100-
	2060	continue" without receiving either a 417 (Expectation Failed) status
	2061	or a 100 (Continue) status. Therefore, when a client sends this
	2062	header field to an origin server (possibly via a proxy) from which it
	2063	has never seen a 100 (Continue) status, the client SHOULD NOT wait
	2064	for an indefinite period before sending the request body.
	2065
	2066	Requirements for HTTP/1.1 origin servers:
	2067
	2068
	2069
	2070
	2071	Fielding, et al. Expires March 2, 2009 [Page 37]
	2072
	2073	Internet-Draft HTTP/1.1, Part 1 August 2008
	2074
	2075
	2076	o Upon receiving a request which includes an Expect request-header
	2077	field with the "100-continue" expectation, an origin server MUST
	2078	either respond with 100 (Continue) status and continue to read
	2079	from the input stream, or respond with a final status code. The
	2080	origin server MUST NOT wait for the request body before sending
	2081	the 100 (Continue) response. If it responds with a final status
	2082	code, it MAY close the transport connection or it MAY continue to
	2083	read and discard the rest of the request. It MUST NOT perform the
	2084	requested method if it returns a final status code.
	2085
	2086	o An origin server SHOULD NOT send a 100 (Continue) response if the
	2087	request message does not include an Expect request-header field
	2088	with the "100-continue" expectation, and MUST NOT send a 100
	2089	(Continue) response if such a request comes from an HTTP/1.0 (or
	2090	earlier) client. There is an exception to this rule: for
	2091	compatibility with [RFC2068], a server MAY send a 100 (Continue)
	2092	status in response to an HTTP/1.1 PUT or POST request that does
	2093	not include an Expect request-header field with the "100-continue"
	2094	expectation. This exception, the purpose of which is to minimize
	2095	any client processing delays associated with an undeclared wait
	2096	for 100 (Continue) status, applies only to HTTP/1.1 requests, and
	2097	not to requests with any other HTTP-version value.
	2098
	2099	o An origin server MAY omit a 100 (Continue) response if it has
	2100	already received some or all of the request body for the
	2101	corresponding request.
	2102
	2103	o An origin server that sends a 100 (Continue) response MUST
	2104	ultimately send a final status code, once the request body is
	2105	received and processed, unless it terminates the transport
	2106	connection prematurely.
	2107
	2108	o If an origin server receives a request that does not include an
	2109	Expect request-header field with the "100-continue" expectation,
	2110	the request includes a request body, and the server responds with
	2111	a final status code before reading the entire request body from
	2112	the transport connection, then the server SHOULD NOT close the
	2113	transport connection until it has read the entire request, or
	2114	until the client closes the connection. Otherwise, the client
	2115	might not reliably receive the response message. However, this
	2116	requirement is not be construed as preventing a server from
	2117	defending itself against denial-of-service attacks, or from badly
	2118	broken client implementations.
	2119
	2120	Requirements for HTTP/1.1 proxies:
	2121
	2122	o If a proxy receives a request that includes an Expect request-
	2123	header field with the "100-continue" expectation, and the proxy
	2124
	2125
	2126
	2127	Fielding, et al. Expires March 2, 2009 [Page 38]
	2128
	2129	Internet-Draft HTTP/1.1, Part 1 August 2008
	2130
	2131
	2132	either knows that the next-hop server complies with HTTP/1.1 or
	2133	higher, or does not know the HTTP version of the next-hop server,
	2134	it MUST forward the request, including the Expect header field.
	2135
	2136	o If the proxy knows that the version of the next-hop server is
	2137	HTTP/1.0 or lower, it MUST NOT forward the request, and it MUST
	2138	respond with a 417 (Expectation Failed) status.
	2139
	2140	o Proxies SHOULD maintain a cache recording the HTTP version numbers
	2141	received from recently-referenced next-hop servers.
	2142
	2143	o A proxy MUST NOT forward a 100 (Continue) response if the request
	2144	message was received from an HTTP/1.0 (or earlier) client and did
	2145	not include an Expect request-header field with the "100-continue"
	2146	expectation. This requirement overrides the general rule for
	2147	forwarding of 1xx responses (see Section 9.1 of [Part2]).
	2148
	2149	7.2.4. Client Behavior if Server Prematurely Closes Connection
	2150
	2151	If an HTTP/1.1 client sends a request which includes a request body,
	2152	but which does not include an Expect request-header field with the
	2153	"100-continue" expectation, and if the client is not directly
	2154	connected to an HTTP/1.1 origin server, and if the client sees the
	2155	connection close before receiving any status from the server, the
	2156	client SHOULD retry the request. If the client does retry this
	2157	request, it MAY use the following "binary exponential backoff"
	2158	algorithm to be assured of obtaining a reliable response:
	2159
	2160	1. Initiate a new connection to the server
	2161
	2162	2. Transmit the request-headers
	2163
	2164	3. Initialize a variable R to the estimated round-trip time to the
	2165	server (e.g., based on the time it took to establish the
	2166	connection), or to a constant value of 5 seconds if the round-
	2167	trip time is not available.
	2168
	2169	4. Compute T = R * (2**N), where N is the number of previous retries
	2170	of this request.
	2171
	2172	5. Wait either for an error response from the server, or for T
	2173	seconds (whichever comes first)
	2174
	2175	6. If no error response is received, after T seconds transmit the
	2176	body of the request.
	2177
	2178	7. If client sees that the connection is closed prematurely, repeat
	2179	from step 1 until the request is accepted, an error response is
	2180
	2181
	2182
	2183	Fielding, et al. Expires March 2, 2009 [Page 39]
	2184
	2185	Internet-Draft HTTP/1.1, Part 1 August 2008
	2186
	2187
	2188	received, or the user becomes impatient and terminates the retry
	2189	process.
	2190
	2191	If at any point an error status is received, the client
	2192
	2193	o SHOULD NOT continue and
	2194
	2195	o SHOULD close the connection if it has not completed sending the
	2196	request message.
	2197
	2198
	2199	8. Header Field Definitions
	2200
	2201	This section defines the syntax and semantics of HTTP/1.1 header
	2202	fields related to message framing and transport protocols.
	2203
	2204	For entity-header fields, both sender and recipient refer to either
	2205	the client or the server, depending on who sends and who receives the
	2206	entity.
	2207
	2208	8.1. Connection
	2209
	2210	The Connection general-header field allows the sender to specify
	2211	options that are desired for that particular connection and MUST NOT
	2212	be communicated by proxies over further connections.
	2213
	2214	The Connection header has the following grammar:
	2215
	2216	Connection = "Connection" ":" 1#(connection-token)
	2217	connection-token = token
	2218
	2219	HTTP/1.1 proxies MUST parse the Connection header field before a
	2220	message is forwarded and, for each connection-token in this field,
	2221	remove any header field(s) from the message with the same name as the
	2222	connection-token. Connection options are signaled by the presence of
	2223	a connection-token in the Connection header field, not by any
	2224	corresponding additional header field(s), since the additional header
	2225	field may not be sent if there are no parameters associated with that
	2226	connection option.
	2227
	2228	Message headers listed in the Connection header MUST NOT include end-
	2229	to-end headers, such as Cache-Control.
	2230
	2231	HTTP/1.1 defines the "close" connection option for the sender to
	2232	signal that the connection will be closed after completion of the
	2233	response. For example,
	2234
	2235	Connection: close
	2236
	2237
	2238
	2239	Fielding, et al. Expires March 2, 2009 [Page 40]
	2240
	2241	Internet-Draft HTTP/1.1, Part 1 August 2008
	2242
	2243
	2244	in either the request or the response header fields indicates that
	2245	the connection SHOULD NOT be considered `persistent' (Section 7.1)
	2246	after the current request/response is complete.
	2247
	2248	An HTTP/1.1 client that does not support persistent connections MUST
	2249	include the "close" connection option in every request message.
	2250
	2251	An HTTP/1.1 server that does not support persistent connections MUST
	2252	include the "close" connection option in every response message that
	2253	does not have a 1xx (informational) status code.
	2254
	2255	A system receiving an HTTP/1.0 (or lower-version) message that
	2256	includes a Connection header MUST, for each connection-token in this
	2257	field, remove and ignore any header field(s) from the message with
	2258	the same name as the connection-token. This protects against
	2259	mistaken forwarding of such header fields by pre-HTTP/1.1 proxies.
	2260	See Appendix C.2.
	2261
	2262	8.2. Content-Length
	2263
	2264	The Content-Length entity-header field indicates the size of the
	2265	entity-body, in decimal number of OCTETs, sent to the recipient or,
	2266	in the case of the HEAD method, the size of the entity-body that
	2267	would have been sent had the request been a GET.
	2268
	2269	Content-Length = "Content-Length" ":" 1*DIGIT
	2270
	2271	An example is
	2272
	2273	Content-Length: 3495
	2274
	2275	Applications SHOULD use this field to indicate the transfer-length of
	2276	the message-body, unless this is prohibited by the rules in
	2277	Section 4.4.
	2278
	2279	Any Content-Length greater than or equal to zero is a valid value.
	2280	Section 4.4 describes how to determine the length of a message-body
	2281	if a Content-Length is not given.
	2282
	2283	Note that the meaning of this field is significantly different from
	2284	the corresponding definition in MIME, where it is an optional field
	2285	used within the "message/external-body" content-type. In HTTP, it
	2286	SHOULD be sent whenever the message's length can be determined prior
	2287	to being transferred, unless this is prohibited by the rules in
	2288	Section 4.4.
	2289
	2290
	2291
	2292
	2293
	2294
	2295	Fielding, et al. Expires March 2, 2009 [Page 41]
	2296
	2297	Internet-Draft HTTP/1.1, Part 1 August 2008
	2298
	2299
	2300	8.3. Date
	2301
	2302	The Date general-header field represents the date and time at which
	2303	the message was originated, having the same semantics as orig-date in
	2304	Section 3.6.1 of [RFC2822]. The field value is an HTTP-date, as
	2305	described in Section 3.3.1; it MUST be sent in rfc1123-date format.
	2306
	2307	Date = "Date" ":" HTTP-date
	2308
	2309	An example is
	2310
	2311	Date: Tue, 15 Nov 1994 08:12:31 GMT
	2312
	2313	Origin servers MUST include a Date header field in all responses,
	2314	except in these cases:
	2315
	2316	1. If the response status code is 100 (Continue) or 101 (Switching
	2317	Protocols), the response MAY include a Date header field, at the
	2318	server's option.
	2319
	2320	2. If the response status code conveys a server error, e.g. 500
	2321	(Internal Server Error) or 503 (Service Unavailable), and it is
	2322	inconvenient or impossible to generate a valid Date.
	2323
	2324	3. If the server does not have a clock that can provide a reasonable
	2325	approximation of the current time, its responses MUST NOT include
	2326	a Date header field. In this case, the rules in Section 8.3.1
	2327	MUST be followed.
	2328
	2329	A received message that does not have a Date header field MUST be
	2330	assigned one by the recipient if the message will be cached by that
	2331	recipient or gatewayed via a protocol which requires a Date. An HTTP
	2332	implementation without a clock MUST NOT cache responses without
	2333	revalidating them on every use. An HTTP cache, especially a shared
	2334	cache, SHOULD use a mechanism, such as NTP [RFC1305], to synchronize
	2335	its clock with a reliable external standard.
	2336
	2337	Clients SHOULD only send a Date header field in messages that include
	2338	an entity-body, as in the case of the PUT and POST requests, and even
	2339	then it is optional. A client without a clock MUST NOT send a Date
	2340	header field in a request.
	2341
	2342	The HTTP-date sent in a Date header SHOULD NOT represent a date and
	2343	time subsequent to the generation of the message. It SHOULD
	2344	represent the best available approximation of the date and time of
	2345	message generation, unless the implementation has no means of
	2346	generating a reasonably accurate date and time. In theory, the date
	2347	ought to represent the moment just before the entity is generated.
	2348
	2349
	2350
	2351	Fielding, et al. Expires March 2, 2009 [Page 42]
	2352
	2353	Internet-Draft HTTP/1.1, Part 1 August 2008
	2354
	2355
	2356	In practice, the date can be generated at any time during the message
	2357	origination without affecting its semantic value.
	2358
	2359	8.3.1. Clockless Origin Server Operation
	2360
	2361	Some origin server implementations might not have a clock available.
	2362	An origin server without a clock MUST NOT assign Expires or Last-
	2363	Modified values to a response, unless these values were associated
	2364	with the resource by a system or user with a reliable clock. It MAY
	2365	assign an Expires value that is known, at or before server
	2366	configuration time, to be in the past (this allows "pre-expiration"
	2367	of responses without storing separate Expires values for each
	2368	resource).
	2369
	2370	8.4. Host
	2371
	2372	The Host request-header field specifies the Internet host and port
	2373	number of the resource being requested, as obtained from the original
	2374	URI given by the user or referring resource (generally an HTTP URL,
	2375	as described in Section 3.2.2). The Host field value MUST represent
	2376	the naming authority of the origin server or gateway given by the
	2377	original URL. This allows the origin server or gateway to
	2378	differentiate between internally-ambiguous URLs, such as the root "/"
	2379	URL of a server for multiple host names on a single IP address.
	2380
	2381	Host = "Host" ":" uri-host [ ":" port ] ; Section 3.2.2
	2382
	2383	A "host" without any trailing port information implies the default
	2384	port for the service requested (e.g., "80" for an HTTP URL). For
	2385	example, a request on the origin server for
	2386	<http://www.example.org/pub/WWW/> would properly include:
	2387
	2388	GET /pub/WWW/ HTTP/1.1
	2389	Host: www.example.org
	2390
	2391	A client MUST include a Host header field in all HTTP/1.1 request
	2392	messages. If the requested URI does not include an Internet host
	2393	name for the service being requested, then the Host header field MUST
	2394	be given with an empty value. An HTTP/1.1 proxy MUST ensure that any
	2395	request message it forwards does contain an appropriate Host header
	2396	field that identifies the service being requested by the proxy. All
	2397	Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad Request)
	2398	status code to any HTTP/1.1 request message which lacks a Host header
	2399	field.
	2400
	2401	See Sections 5.2 and C.1.1 for other requirements relating to Host.
	2402
	2403
	2404
	2405
	2406
	2407	Fielding, et al. Expires March 2, 2009 [Page 43]
	2408
	2409	Internet-Draft HTTP/1.1, Part 1 August 2008
	2410
	2411
	2412	8.5. TE
	2413
	2414	The TE request-header field indicates what extension transfer-codings
	2415	it is willing to accept in the response and whether or not it is
	2416	willing to accept trailer fields in a chunked transfer-coding. Its
	2417	value may consist of the keyword "trailers" and/or a comma-separated
	2418	list of extension transfer-coding names with optional accept
	2419	parameters (as described in Section 3.4).
	2420
	2421	TE = "TE" ":" #( t-codings )
	2422	t-codings = "trailers" \| ( transfer-extension [ accept-params ] )
	2423
	2424	The presence of the keyword "trailers" indicates that the client is
	2425	willing to accept trailer fields in a chunked transfer-coding, as
	2426	defined in Section 3.4.1. This keyword is reserved for use with
	2427	transfer-coding values even though it does not itself represent a
	2428	transfer-coding.
	2429
	2430	Examples of its use are:
	2431
	2432	TE: deflate
	2433	TE:
	2434	TE: trailers, deflate;q=0.5
	2435
	2436	The TE header field only applies to the immediate connection.
	2437	Therefore, the keyword MUST be supplied within a Connection header
	2438	field (Section 8.1) whenever TE is present in an HTTP/1.1 message.
	2439
	2440	A server tests whether a transfer-coding is acceptable, according to
	2441	a TE field, using these rules:
	2442
	2443	1. The "chunked" transfer-coding is always acceptable. If the
	2444	keyword "trailers" is listed, the client indicates that it is
	2445	willing to accept trailer fields in the chunked response on
	2446	behalf of itself and any downstream clients. The implication is
	2447	that, if given, the client is stating that either all downstream
	2448	clients are willing to accept trailer fields in the forwarded
	2449	response, or that it will attempt to buffer the response on
	2450	behalf of downstream recipients.
	2451
	2452	Note: HTTP/1.1 does not define any means to limit the size of a
	2453	chunked response such that a client can be assured of buffering
	2454	the entire response.
	2455
	2456	2. If the transfer-coding being tested is one of the transfer-
	2457	codings listed in the TE field, then it is acceptable unless it
	2458	is accompanied by a qvalue of 0. (As defined in Section 3.4 of
	2459	[Part3], a qvalue of 0 means "not acceptable.")
	2460
	2461
	2462
	2463	Fielding, et al. Expires March 2, 2009 [Page 44]
	2464
	2465	Internet-Draft HTTP/1.1, Part 1 August 2008
	2466
	2467
	2468	3. If multiple transfer-codings are acceptable, then the acceptable
	2469	transfer-coding with the highest non-zero qvalue is preferred.
	2470	The "chunked" transfer-coding always has a qvalue of 1.
	2471
	2472	If the TE field-value is empty or if no TE field is present, the only
	2473	transfer-coding is "chunked". A message with no transfer-coding is
	2474	always acceptable.
	2475
	2476	8.6. Trailer
	2477
	2478	The Trailer general field value indicates that the given set of
	2479	header fields is present in the trailer of a message encoded with
	2480	chunked transfer-coding.
	2481
	2482	Trailer = "Trailer" ":" 1#field-name
	2483
	2484	An HTTP/1.1 message SHOULD include a Trailer header field in a
	2485	message using chunked transfer-coding with a non-empty trailer.
	2486	Doing so allows the recipient to know which header fields to expect
	2487	in the trailer.
	2488
	2489	If no Trailer header field is present, the trailer SHOULD NOT include
	2490	any header fields. See Section 3.4.1 for restrictions on the use of
	2491	trailer fields in a "chunked" transfer-coding.
	2492
	2493	Message header fields listed in the Trailer header field MUST NOT
	2494	include the following header fields:
	2495
	2496	o Transfer-Encoding
	2497
	2498	o Content-Length
	2499
	2500	o Trailer
	2501
	2502	8.7. Transfer-Encoding
	2503
	2504	The Transfer-Encoding general-header field indicates what (if any)
	2505	type of transformation has been applied to the message body in order
	2506	to safely transfer it between the sender and the recipient. This
	2507	differs from the content-coding in that the transfer-coding is a
	2508	property of the message, not of the entity.
	2509
	2510	Transfer-Encoding = "Transfer-Encoding" ":" 1#transfer-coding
	2511
	2512	Transfer-codings are defined in Section 3.4. An example is:
	2513
	2514	Transfer-Encoding: chunked
	2515
	2516
	2517
	2518
	2519	Fielding, et al. Expires March 2, 2009 [Page 45]
	2520
	2521	Internet-Draft HTTP/1.1, Part 1 August 2008
	2522
	2523
	2524	If multiple encodings have been applied to an entity, the transfer-
	2525	codings MUST be listed in the order in which they were applied.
	2526	Additional information about the encoding parameters MAY be provided
	2527	by other entity-header fields not defined by this specification.
	2528
	2529	Many older HTTP/1.0 applications do not understand the Transfer-
	2530	Encoding header.
	2531
	2532	8.8. Upgrade
	2533
	2534	The Upgrade general-header allows the client to specify what
	2535	additional communication protocols it supports and would like to use
	2536	if the server finds it appropriate to switch protocols. The server
	2537	MUST use the Upgrade header field within a 101 (Switching Protocols)
	2538	response to indicate which protocol(s) are being switched.
	2539
	2540	Upgrade = "Upgrade" ":" 1#product
	2541
	2542	For example,
	2543
	2544	Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
	2545
	2546	The Upgrade header field is intended to provide a simple mechanism
	2547	for transition from HTTP/1.1 to some other, incompatible protocol.
	2548	It does so by allowing the client to advertise its desire to use
	2549	another protocol, such as a later version of HTTP with a higher major
	2550	version number, even though the current request has been made using
	2551	HTTP/1.1. This eases the difficult transition between incompatible
	2552	protocols by allowing the client to initiate a request in the more
	2553	commonly supported protocol while indicating to the server that it
	2554	would like to use a "better" protocol if available (where "better" is
	2555	determined by the server, possibly according to the nature of the
	2556	method and/or resource being requested).
	2557
	2558	The Upgrade header field only applies to switching application-layer
	2559	protocols upon the existing transport-layer connection. Upgrade
	2560	cannot be used to insist on a protocol change; its acceptance and use
	2561	by the server is optional. The capabilities and nature of the
	2562	application-layer communication after the protocol change is entirely
	2563	dependent upon the new protocol chosen, although the first action
	2564	after changing the protocol MUST be a response to the initial HTTP
	2565	request containing the Upgrade header field.
	2566
	2567	The Upgrade header field only applies to the immediate connection.
	2568	Therefore, the upgrade keyword MUST be supplied within a Connection
	2569	header field (Section 8.1) whenever Upgrade is present in an HTTP/1.1
	2570	message.
	2571
	2572
	2573
	2574
	2575	Fielding, et al. Expires March 2, 2009 [Page 46]
	2576
	2577	Internet-Draft HTTP/1.1, Part 1 August 2008
	2578
	2579
	2580	The Upgrade header field cannot be used to indicate a switch to a
	2581	protocol on a different connection. For that purpose, it is more
	2582	appropriate to use a 301, 302, 303, or 305 redirection response.
	2583
	2584	This specification only defines the protocol name "HTTP" for use by
	2585	the family of Hypertext Transfer Protocols, as defined by the HTTP
	2586	version rules of Section 3.1 and future updates to this
	2587	specification. Any token can be used as a protocol name; however, it
	2588	will only be useful if both the client and server associate the name
	2589	with the same protocol.
	2590
	2591	8.9. Via
	2592
	2593	The Via general-header field MUST be used by gateways and proxies to
	2594	indicate the intermediate protocols and recipients between the user
	2595	agent and the server on requests, and between the origin server and
	2596	the client on responses. It is analogous to the "Received" field
	2597	defined in Section 3.6.7 of [RFC2822] and is intended to be used for
	2598	tracking message forwards, avoiding request loops, and identifying
	2599	the protocol capabilities of all senders along the request/response
	2600	chain.
	2601
	2602	Via = "Via" ":" 1#( received-protocol received-by [ comment ] )
	2603	received-protocol = [ protocol-name "/" ] protocol-version
	2604	protocol-name = token
	2605	protocol-version = token
	2606	received-by = ( uri-host [ ":" port ] ) \| pseudonym
	2607	pseudonym = token
	2608
	2609	The received-protocol indicates the protocol version of the message
	2610	received by the server or client along each segment of the request/
	2611	response chain. The received-protocol version is appended to the Via
	2612	field value when the message is forwarded so that information about
	2613	the protocol capabilities of upstream applications remains visible to
	2614	all recipients.
	2615
	2616	The protocol-name is optional if and only if it would be "HTTP". The
	2617	received-by field is normally the host and optional port number of a
	2618	recipient server or client that subsequently forwarded the message.
	2619	However, if the real host is considered to be sensitive information,
	2620	it MAY be replaced by a pseudonym. If the port is not given, it MAY
	2621	be assumed to be the default port of the received-protocol.
	2622
	2623	Multiple Via field values represents each proxy or gateway that has
	2624	forwarded the message. Each recipient MUST append its information
	2625	such that the end result is ordered according to the sequence of
	2626	forwarding applications.
	2627
	2628
	2629
	2630
	2631	Fielding, et al. Expires March 2, 2009 [Page 47]
	2632
	2633	Internet-Draft HTTP/1.1, Part 1 August 2008
	2634
	2635
	2636	Comments MAY be used in the Via header field to identify the software
	2637	of the recipient proxy or gateway, analogous to the User-Agent and
	2638	Server header fields. However, all comments in the Via field are
	2639	optional and MAY be removed by any recipient prior to forwarding the
	2640	message.
	2641
	2642	For example, a request message could be sent from an HTTP/1.0 user
	2643	agent to an internal proxy code-named "fred", which uses HTTP/1.1 to
	2644	forward the request to a public proxy at p.example.net, which
	2645	completes the request by forwarding it to the origin server at
	2646	www.example.com. The request received by www.example.com would then
	2647	have the following Via header field:
	2648
	2649	Via: 1.0 fred, 1.1 p.example.net (Apache/1.1)
	2650
	2651	Proxies and gateways used as a portal through a network firewall
	2652	SHOULD NOT, by default, forward the names and ports of hosts within
	2653	the firewall region. This information SHOULD only be propagated if
	2654	explicitly enabled. If not enabled, the received-by host of any host
	2655	behind the firewall SHOULD be replaced by an appropriate pseudonym
	2656	for that host.
	2657
	2658	For organizations that have strong privacy requirements for hiding
	2659	internal structures, a proxy MAY combine an ordered subsequence of
	2660	Via header field entries with identical received-protocol values into
	2661	a single such entry. For example,
	2662
	2663	Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
	2664
	2665	could be collapsed to
	2666
	2667	Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
	2668
	2669	Applications SHOULD NOT combine multiple entries unless they are all
	2670	under the same organizational control and the hosts have already been
	2671	replaced by pseudonyms. Applications MUST NOT combine entries which
	2672	have different received-protocol values.
	2673
	2674
	2675	9. IANA Considerations
	2676
	2677	9.1. Message Header Registration
	2678
	2679	The Message Header Registry located at <http://www.iana.org/
	2680	assignments/message-headers/message-header-index.html> should be
	2681	updated with the permanent registrations below (see [RFC3864]):
	2682
	2683
	2684
	2685
	2686
	2687	Fielding, et al. Expires March 2, 2009 [Page 48]
	2688
	2689	Internet-Draft HTTP/1.1, Part 1 August 2008
	2690
	2691
	2692	+-------------------+----------+----------+-------------+
	2693	\| Header Field Name \| Protocol \| Status \| Reference \|
	2694	+-------------------+----------+----------+-------------+
	2695	\| Connection \| http \| standard \| Section 8.1 \|
	2696	\| Content-Length \| http \| standard \| Section 8.2 \|
	2697	\| Date \| http \| standard \| Section 8.3 \|
	2698	\| Host \| http \| standard \| Section 8.4 \|
	2699	\| TE \| http \| standard \| Section 8.5 \|
	2700	\| Trailer \| http \| standard \| Section 8.6 \|
	2701	\| Transfer-Encoding \| http \| standard \| Section 8.7 \|
	2702	\| Upgrade \| http \| standard \| Section 8.8 \|
	2703	\| Via \| http \| standard \| Section 8.9 \|
	2704	+-------------------+----------+----------+-------------+
	2705
	2706	The change controller is: "IETF (iesg@ietf.org) - Internet
	2707	Engineering Task Force".
	2708
	2709	9.2. URI Scheme Registration
	2710
	2711	The entry for the "http" URI Scheme in the registry located at
	2712	<http://www.iana.org/assignments/uri-schemes.html> should be updated
	2713	to point to Section 3.2.2 of this document (see [RFC4395]).
	2714
	2715	9.3. Internet Media Type Registrations
	2716
	2717	This document serves as the specification for the Internet media
	2718	types "message/http" and "application/http". The following is to be
	2719	registered with IANA (see [RFC4288]).
	2720
	2721	9.3.1. Internet Media Type message/http
	2722
	2723	The message/http type can be used to enclose a single HTTP request or
	2724	response message, provided that it obeys the MIME restrictions for
	2725	all "message" types regarding line length and encodings.
	2726
	2727	Type name: message
	2728
	2729	Subtype name: http
	2730
	2731	Required parameters: none
	2732
	2733	Optional parameters: version, msgtype
	2734
	2735	version: The HTTP-Version number of the enclosed message (e.g.,
	2736	"1.1"). If not present, the version can be determined from the
	2737	first line of the body.
	2738
	2739
	2740
	2741
	2742
	2743	Fielding, et al. Expires March 2, 2009 [Page 49]
	2744
	2745	Internet-Draft HTTP/1.1, Part 1 August 2008
	2746
	2747
	2748	msgtype: The message type -- "request" or "response". If not
	2749	present, the type can be determined from the first line of the
	2750	body.
	2751
	2752	Encoding considerations: only "7bit", "8bit", or "binary" are
	2753	permitted
	2754
	2755	Security considerations: none
	2756
	2757	Interoperability considerations: none
	2758
	2759	Published specification: This specification (see Section 9.3.1).
	2760
	2761	Applications that use this media type:
	2762
	2763	Additional information:
	2764
	2765	Magic number(s): none
	2766
	2767	File extension(s): none
	2768
	2769	Macintosh file type code(s): none
	2770
	2771	Person and email address to contact for further information: See
	2772	Authors Section.
	2773
	2774	Intended usage: COMMON
	2775
	2776	Restrictions on usage: none
	2777
	2778	Author/Change controller: IESG
	2779
	2780	9.3.2. Internet Media Type application/http
	2781
	2782	The application/http type can be used to enclose a pipeline of one or
	2783	more HTTP request or response messages (not intermixed).
	2784
	2785	Type name: application
	2786
	2787	Subtype name: http
	2788
	2789	Required parameters: none
	2790
	2791	Optional parameters: version, msgtype
	2792
	2793
	2794
	2795
	2796
	2797
	2798
	2799	Fielding, et al. Expires March 2, 2009 [Page 50]
	2800
	2801	Internet-Draft HTTP/1.1, Part 1 August 2008
	2802
	2803
	2804	version: The HTTP-Version number of the enclosed messages (e.g.,
	2805	"1.1"). If not present, the version can be determined from the
	2806	first line of the body.
	2807
	2808	msgtype: The message type -- "request" or "response". If not
	2809	present, the type can be determined from the first line of the
	2810	body.
	2811
	2812	Encoding considerations: HTTP messages enclosed by this type are in
	2813	"binary" format; use of an appropriate Content-Transfer-Encoding
	2814	is required when transmitted via E-mail.
	2815
	2816	Security considerations: none
	2817
	2818	Interoperability considerations: none
	2819
	2820	Published specification: This specification (see Section 9.3.2).
	2821
	2822	Applications that use this media type:
	2823
	2824	Additional information:
	2825
	2826	Magic number(s): none
	2827
	2828	File extension(s): none
	2829
	2830	Macintosh file type code(s): none
	2831
	2832	Person and email address to contact for further information: See
	2833	Authors Section.
	2834
	2835	Intended usage: COMMON
	2836
	2837	Restrictions on usage: none
	2838
	2839	Author/Change controller: IESG
	2840
	2841
	2842	10. Security Considerations
	2843
	2844	This section is meant to inform application developers, information
	2845	providers, and users of the security limitations in HTTP/1.1 as
	2846	described by this document. The discussion does not include
	2847	definitive solutions to the problems revealed, though it does make
	2848	some suggestions for reducing security risks.
	2849
	2850
	2851
	2852
	2853
	2854
	2855	Fielding, et al. Expires March 2, 2009 [Page 51]
	2856
	2857	Internet-Draft HTTP/1.1, Part 1 August 2008
	2858
	2859
	2860	10.1. Personal Information
	2861
	2862	HTTP clients are often privy to large amounts of personal information
	2863	(e.g. the user's name, location, mail address, passwords, encryption
	2864	keys, etc.), and SHOULD be very careful to prevent unintentional
	2865	leakage of this information. We very strongly recommend that a
	2866	convenient interface be provided for the user to control
	2867	dissemination of such information, and that designers and
	2868	implementors be particularly careful in this area. History shows
	2869	that errors in this area often create serious security and/or privacy
	2870	problems and generate highly adverse publicity for the implementor's
	2871	company.
	2872
	2873	10.2. Abuse of Server Log Information
	2874
	2875	A server is in the position to save personal data about a user's
	2876	requests which might identify their reading patterns or subjects of
	2877	interest. This information is clearly confidential in nature and its
	2878	handling can be constrained by law in certain countries. People
	2879	using HTTP to provide data are responsible for ensuring that such
	2880	material is not distributed without the permission of any individuals
	2881	that are identifiable by the published results.
	2882
	2883	10.3. Attacks Based On File and Path Names
	2884
	2885	Implementations of HTTP origin servers SHOULD be careful to restrict
	2886	the documents returned by HTTP requests to be only those that were
	2887	intended by the server administrators. If an HTTP server translates
	2888	HTTP URIs directly into file system calls, the server MUST take
	2889	special care not to serve files that were not intended to be
	2890	delivered to HTTP clients. For example, UNIX, Microsoft Windows, and
	2891	other operating systems use ".." as a path component to indicate a
	2892	directory level above the current one. On such a system, an HTTP
	2893	server MUST disallow any such construct in the Request-URI if it
	2894	would otherwise allow access to a resource outside those intended to
	2895	be accessible via the HTTP server. Similarly, files intended for
	2896	reference only internally to the server (such as access control
	2897	files, configuration files, and script code) MUST be protected from
	2898	inappropriate retrieval, since they might contain sensitive
	2899	information. Experience has shown that minor bugs in such HTTP
	2900	server implementations have turned into security risks.
	2901
	2902	10.4. DNS Spoofing
	2903
	2904	Clients using HTTP rely heavily on the Domain Name Service, and are
	2905	thus generally prone to security attacks based on the deliberate mis-
	2906	association of IP addresses and DNS names. Clients need to be
	2907	cautious in assuming the continuing validity of an IP number/DNS name
	2908
	2909
	2910
	2911	Fielding, et al. Expires March 2, 2009 [Page 52]
	2912
	2913	Internet-Draft HTTP/1.1, Part 1 August 2008
	2914
	2915
	2916	association.
	2917
	2918	In particular, HTTP clients SHOULD rely on their name resolver for
	2919	confirmation of an IP number/DNS name association, rather than
	2920	caching the result of previous host name lookups. Many platforms
	2921	already can cache host name lookups locally when appropriate, and
	2922	they SHOULD be configured to do so. It is proper for these lookups
	2923	to be cached, however, only when the TTL (Time To Live) information
	2924	reported by the name server makes it likely that the cached
	2925	information will remain useful.
	2926
	2927	If HTTP clients cache the results of host name lookups in order to
	2928	achieve a performance improvement, they MUST observe the TTL
	2929	information reported by DNS.
	2930
	2931	If HTTP clients do not observe this rule, they could be spoofed when
	2932	a previously-accessed server's IP address changes. As network
	2933	renumbering is expected to become increasingly common [RFC1900], the
	2934	possibility of this form of attack will grow. Observing this
	2935	requirement thus reduces this potential security vulnerability.
	2936
	2937	This requirement also improves the load-balancing behavior of clients
	2938	for replicated servers using the same DNS name and reduces the
	2939	likelihood of a user's experiencing failure in accessing sites which
	2940	use that strategy.
	2941
	2942	10.5. Proxies and Caching
	2943
	2944	By their very nature, HTTP proxies are men-in-the-middle, and
	2945	represent an opportunity for man-in-the-middle attacks. Compromise
	2946	of the systems on which the proxies run can result in serious
	2947	security and privacy problems. Proxies have access to security-
	2948	related information, personal information about individual users and
	2949	organizations, and proprietary information belonging to users and
	2950	content providers. A compromised proxy, or a proxy implemented or
	2951	configured without regard to security and privacy considerations,
	2952	might be used in the commission of a wide range of potential attacks.
	2953
	2954	Proxy operators should protect the systems on which proxies run as
	2955	they would protect any system that contains or transports sensitive
	2956	information. In particular, log information gathered at proxies
	2957	often contains highly sensitive personal information, and/or
	2958	information about organizations. Log information should be carefully
	2959	guarded, and appropriate guidelines for use developed and followed.
	2960	(Section 10.2).
	2961
	2962	Proxy implementors should consider the privacy and security
	2963	implications of their design and coding decisions, and of the
	2964
	2965
	2966
	2967	Fielding, et al. Expires March 2, 2009 [Page 53]
	2968
	2969	Internet-Draft HTTP/1.1, Part 1 August 2008
	2970
	2971
	2972	configuration options they provide to proxy operators (especially the
	2973	default configuration).
	2974
	2975	Users of a proxy need to be aware that they are no trustworthier than
	2976	the people who run the proxy; HTTP itself cannot solve this problem.
	2977
	2978	The judicious use of cryptography, when appropriate, may suffice to
	2979	protect against a broad range of security and privacy attacks. Such
	2980	cryptography is beyond the scope of the HTTP/1.1 specification.
	2981
	2982	10.6. Denial of Service Attacks on Proxies
	2983
	2984	They exist. They are hard to defend against. Research continues.
	2985	Beware.
	2986
	2987
	2988	11. Acknowledgments
	2989
	2990	This specification makes heavy use of the augmented BNF and generic
	2991	constructs defined by David H. Crocker for [RFC822ABNF]. Similarly,
	2992	it reuses many of the definitions provided by Nathaniel Borenstein
	2993	and Ned Freed for MIME [RFC2045]. We hope that their inclusion in
	2994	this specification will help reduce past confusion over the
	2995	relationship between HTTP and Internet mail message formats.
	2996
	2997	HTTP has evolved considerably over the years. It has benefited from
	2998	a large and active developer community--the many people who have
	2999	participated on the www-talk mailing list--and it is that community
	3000	which has been most responsible for the success of HTTP and of the
	3001	World-Wide Web in general. Marc Andreessen, Robert Cailliau, Daniel
	3002	W. Connolly, Bob Denny, John Franks, Jean-Francois Groff, Phillip M.
	3003	Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob McCool, Lou Montulli,
	3004	Dave Raggett, Tony Sanders, and Marc VanHeyningen deserve special
	3005	recognition for their efforts in defining early aspects of the
	3006	protocol.
	3007
	3008	This document has benefited greatly from the comments of all those
	3009	participating in the HTTP-WG. In addition to those already
	3010	mentioned, the following individuals have contributed to this
	3011	specification:
	3012
	3013	Gary Adams, Harald Tveit Alvestrand, Keith Ball, Brian Behlendorf,
	3014	Paul Burchard, Maurizio Codogno, Mike Cowlishaw, Roman Czyborra,
	3015	Michael A. Dolan, Daniel DuBois, David J. Fiander, Alan Freier, Marc
	3016	Hedlund, Greg Herlihy, Koen Holtman, Alex Hopmann, Bob Jernigan, Shel
	3017	Kaphan, Rohit Khare, John Klensin, Martijn Koster, Alexei Kosut,
	3018	David M. Kristol, Daniel LaLiberte, Ben Laurie, Paul J. Leach, Albert
	3019	Lunde, John C. Mallery, Jean-Philippe Martin-Flatin, Mitra, David
	3020
	3021
	3022
	3023	Fielding, et al. Expires March 2, 2009 [Page 54]
	3024
	3025	Internet-Draft HTTP/1.1, Part 1 August 2008
	3026
	3027
	3028	Morris, Gavin Nicol, Ross Patterson, Bill Perry, Jeffrey Perry, Scott
	3029	Powers, Owen Rees, Luigi Rizzo, David Robinson, Marc Salomon, Rich
	3030	Salz, Allan M. Schiffman, Jim Seidman, Chuck Shotton, Eric W. Sink,
	3031	Simon E. Spero, Richard N. Taylor, Robert S. Thau, Bill (BearHeart)
	3032	Weinman, Francois Yergeau, Mary Ellen Zurko, Josh Cohen.
	3033
	3034	Thanks to the "cave men" of Palo Alto. You know who you are.
	3035
	3036	Jim Gettys (the editor of [RFC2616]) wishes particularly to thank Roy
	3037	Fielding, the editor of [RFC2068], along with John Klensin, Jeff
	3038	Mogul, Paul Leach, Dave Kristol, Koen Holtman, John Franks, Josh
	3039	Cohen, Alex Hopmann, Scott Lawrence, and Larry Masinter for their
	3040	help. And thanks go particularly to Jeff Mogul and Scott Lawrence
	3041	for performing the "MUST/MAY/SHOULD" audit.
	3042
	3043	The Apache Group, Anselm Baird-Smith, author of Jigsaw, and Henrik
	3044	Frystyk implemented RFC 2068 early, and we wish to thank them for the
	3045	discovery of many of the problems that this document attempts to
	3046	rectify.
	3047
	3048
	3049	12. References
	3050
	3051	12.1. Normative References
	3052
	3053	[ISO-8859-1]
	3054	International Organization for Standardization,
	3055	"Information technology -- 8-bit single-byte coded graphic
	3056	character sets -- Part 1: Latin alphabet No. 1", ISO/
	3057	IEC 8859-1:1998, 1998.
	3058
	3059	[Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	3060	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
	3061	and J. Reschke, Ed., "HTTP/1.1, part 2: Message
	3062	Semantics", draft-ietf-httpbis-p2-semantics-04 (work in
	3063	progress), August 2008.
	3064
	3065	[Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	3066	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
	3067	and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload
	3068	and Content Negotiation", draft-ietf-httpbis-p3-payload-04
	3069	(work in progress), August 2008.
	3070
	3071	[Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	3072	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
	3073	and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and
	3074	Partial Responses", draft-ietf-httpbis-p5-range-04 (work
	3075	in progress), August 2008.
	3076
	3077
	3078
	3079	Fielding, et al. Expires March 2, 2009 [Page 55]
	3080
	3081	Internet-Draft HTTP/1.1, Part 1 August 2008
	3082
	3083
	3084	[Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	3085	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
	3086	and J. Reschke, Ed., "HTTP/1.1, part 6: Caching",
	3087	draft-ietf-httpbis-p6-cache-04 (work in progress),
	3088	August 2008.
	3089
	3090	[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
	3091	Extensions (MIME) Part One: Format of Internet Message
	3092	Bodies", RFC 2045, November 1996.
	3093
	3094	[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
	3095	Part Three: Message Header Extensions for Non-ASCII Text",
	3096	RFC 2047, November 1996.
	3097
	3098	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	3099	Requirement Levels", BCP 14, RFC 2119, March 1997.
	3100
	3101	[RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
	3102	Resource Identifiers (URI): Generic Syntax", RFC 2396,
	3103	August 1998.
	3104
	3105	[RFC822ABNF]
	3106	Crocker, D., "Standard for the format of ARPA Internet
	3107	text messages", STD 11, RFC 822, August 1982.
	3108
	3109	[USASCII] American National Standards Institute, "Coded Character
	3110	Set -- 7-bit American Standard Code for Information
	3111	Interchange", ANSI X3.4, 1986.
	3112
	3113	12.2. Informative References
	3114
	3115	[Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and
	3116	Politics", ACM Transactions on Internet Technology Vol. 1,
	3117	#2, November 2001, <http://arxiv.org/abs/cs.SE/0105018>.
	3118
	3119	[Nie1997] Nielsen, H., Gettys, J., Prud'hommeaux, E., Lie, H., and
	3120	C. Lilley, "Network Performance Effects of HTTP/1.1, CSS1,
	3121	and PNG", ACM Proceedings of the ACM SIGCOMM '97
	3122	conference on Applications, technologies, architectures,
	3123	and protocols for computer communication SIGCOMM '97,
	3124	September 1997,
	3125	<http://doi.acm.org/10.1145/263105.263157>.
	3126
	3127	[Pad1995] Padmanabhan, V. and J. Mogul, "Improving HTTP Latency",
	3128	Computer Networks and ISDN Systems v. 28, pp. 25-35,
	3129	December 1995,
	3130	<http://portal.acm.org/citation.cfm?id=219094>.
	3131
	3132
	3133
	3134
	3135	Fielding, et al. Expires March 2, 2009 [Page 56]
	3136
	3137	Internet-Draft HTTP/1.1, Part 1 August 2008
	3138
	3139
	3140	[RFC1123] Braden, R., "Requirements for Internet Hosts - Application
	3141	and Support", STD 3, RFC 1123, October 1989.
	3142
	3143	[RFC1305] Mills, D., "Network Time Protocol (Version 3)
	3144	Specification, Implementation", RFC 1305, March 1992.
	3145
	3146	[RFC1436] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D.,
	3147	Torrey, D., and B. Alberti, "The Internet Gopher Protocol
	3148	(a distributed document search and retrieval protocol)",
	3149	RFC 1436, March 1993.
	3150
	3151	[RFC1630] Berners-Lee, T., "Universal Resource Identifiers in WWW: A
	3152	Unifying Syntax for the Expression of Names and Addresses
	3153	of Objects on the Network as used in the World-Wide Web",
	3154	RFC 1630, June 1994.
	3155
	3156	[RFC1737] Masinter, L. and K. Sollins, "Functional Requirements for
	3157	Uniform Resource Names", RFC 1737, December 1994.
	3158
	3159	[RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
	3160	Resource Locators (URL)", RFC 1738, December 1994.
	3161
	3162	[RFC1808] Fielding, R., "Relative Uniform Resource Locators",
	3163	RFC 1808, June 1995.
	3164
	3165	[RFC1900] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work",
	3166	RFC 1900, February 1996.
	3167
	3168	[RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext
	3169	Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
	3170
	3171	[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.
	3172	Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
	3173	RFC 2068, January 1997.
	3174
	3175	[RFC2109] Kristol, D. and L. Montulli, "HTTP State Management
	3176	Mechanism", RFC 2109, February 1997.
	3177
	3178	[RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, "Use
	3179	and Interpretation of HTTP Version Numbers", RFC 2145,
	3180	May 1997.
	3181
	3182	[RFC2324] Masinter, L., "Hyper Text Coffee Pot Control Protocol
	3183	(HTCPCP/1.0)", RFC 2324, April 1998.
	3184
	3185	[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
	3186	Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
	3187	Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
	3188
	3189
	3190
	3191	Fielding, et al. Expires March 2, 2009 [Page 57]
	3192
	3193	Internet-Draft HTTP/1.1, Part 1 August 2008
	3194
	3195
	3196	[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
	3197
	3198	[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
	3199	April 2001.
	3200
	3201	[RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
	3202	April 2001.
	3203
	3204	[RFC2965] Kristol, D. and L. Montulli, "HTTP State Management
	3205	Mechanism", RFC 2965, October 2000.
	3206
	3207	[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
	3208	Procedures for Message Header Fields", BCP 90, RFC 3864,
	3209	September 2004.
	3210
	3211	[RFC3977] Feather, C., "Network News Transfer Protocol (NNTP)",
	3212	RFC 3977, October 2006.
	3213
	3214	[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
	3215	Registration Procedures", BCP 13, RFC 4288, December 2005.
	3216
	3217	[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
	3218	Registration Procedures for New URI Schemes", BCP 115,
	3219	RFC 4395, February 2006.
	3220
	3221	[RFC822] Crocker, D., "Standard for the format of ARPA Internet
	3222	text messages", STD 11, RFC 822, August 1982.
	3223
	3224	[RFC959] Postel, J. and J. Reynolds, "File Transfer Protocol",
	3225	STD 9, RFC 959, October 1985.
	3226
	3227	[Spe] Spero, S., "Analysis of HTTP Performance Problems",
	3228	<http://sunsite.unc.edu/mdma-release/http-prob.html>.
	3229
	3230	[Tou1998] Touch, J., Heidemann, J., and K. Obraczka, "Analysis of
	3231	HTTP Performance", ISI Research Report ISI/RR-98-463,
	3232	Aug 1998, <http://www.isi.edu/touch/pubs/http-perf96/>.
	3233
	3234	(original report dated Aug. 1996)
	3235
	3236	[WAIS] Davis, F., Kahle, B., Morris, H., Salem, J., Shen, T.,
	3237	Wang, R., Sui, J., and M. Grinbaum, "WAIS Interface
	3238	Protocol Prototype Functional Specification (v1.5)",
	3239	Thinking Machines Corporation , April 1990.
	3240
	3241
	3242
	3243
	3244
	3245
	3246
	3247	Fielding, et al. Expires March 2, 2009 [Page 58]
	3248
	3249	Internet-Draft HTTP/1.1, Part 1 August 2008
	3250
	3251
	3252	Appendix A. Tolerant Applications
	3253
	3254	Although this document specifies the requirements for the generation
	3255	of HTTP/1.1 messages, not all applications will be correct in their
	3256	implementation. We therefore recommend that operational applications
	3257	be tolerant of deviations whenever those deviations can be
	3258	interpreted unambiguously.
	3259
	3260	Clients SHOULD be tolerant in parsing the Status-Line and servers
	3261	tolerant when parsing the Request-Line. In particular, they SHOULD
	3262	accept any amount of SP or HTAB characters between fields, even
	3263	though only a single SP is required.
	3264
	3265	The line terminator for message-header fields is the sequence CRLF.
	3266	However, we recommend that applications, when parsing such headers,
	3267	recognize a single LF as a line terminator and ignore the leading CR.
	3268
	3269	The character set of an entity-body SHOULD be labeled as the lowest
	3270	common denominator of the character codes used within that body, with
	3271	the exception that not labeling the entity is preferred over labeling
	3272	the entity with the labels US-ASCII or ISO-8859-1. See [Part3].
	3273
	3274	Additional rules for requirements on parsing and encoding of dates
	3275	and other potential problems with date encodings include:
	3276
	3277	o HTTP/1.1 clients and caches SHOULD assume that an RFC-850 date
	3278	which appears to be more than 50 years in the future is in fact in
	3279	the past (this helps solve the "year 2000" problem).
	3280
	3281	o An HTTP/1.1 implementation MAY internally represent a parsed
	3282	Expires date as earlier than the proper value, but MUST NOT
	3283	internally represent a parsed Expires date as later than the
	3284	proper value.
	3285
	3286	o All expiration-related calculations MUST be done in GMT. The
	3287	local time zone MUST NOT influence the calculation or comparison
	3288	of an age or expiration time.
	3289
	3290	o If an HTTP header incorrectly carries a date value with a time
	3291	zone other than GMT, it MUST be converted into GMT using the most
	3292	conservative possible conversion.
	3293
	3294
	3295	Appendix B. Conversion of Date Formats
	3296
	3297	HTTP/1.1 uses a restricted set of date formats (Section 3.3.1) to
	3298	simplify the process of date comparison. Proxies and gateways from
	3299	other protocols SHOULD ensure that any Date header field present in a
	3300
	3301
	3302
	3303	Fielding, et al. Expires March 2, 2009 [Page 59]
	3304
	3305	Internet-Draft HTTP/1.1, Part 1 August 2008
	3306
	3307
	3308	message conforms to one of the HTTP/1.1 formats and rewrite the date
	3309	if necessary.
	3310
	3311
	3312	Appendix C. Compatibility with Previous Versions
	3313
	3314	It is beyond the scope of a protocol specification to mandate
	3315	compliance with previous versions. HTTP/1.1 was deliberately
	3316	designed, however, to make supporting previous versions easy. It is
	3317	worth noting that, at the time of composing this specification
	3318	(1996), we would expect commercial HTTP/1.1 servers to:
	3319
	3320	o recognize the format of the Request-Line for HTTP/0.9, 1.0, and
	3321	1.1 requests;
	3322
	3323	o understand any valid request in the format of HTTP/0.9, 1.0, or
	3324	1.1;
	3325
	3326	o respond appropriately with a message in the same major version
	3327	used by the client.
	3328
	3329	And we would expect HTTP/1.1 clients to:
	3330
	3331	o recognize the format of the Status-Line for HTTP/1.0 and 1.1
	3332	responses;
	3333
	3334	o understand any valid response in the format of HTTP/0.9, 1.0, or
	3335	1.1.
	3336
	3337	For most implementations of HTTP/1.0, each connection is established
	3338	by the client prior to the request and closed by the server after
	3339	sending the response. Some implementations implement the Keep-Alive
	3340	version of persistent connections described in Section 19.7.1 of
	3341	[RFC2068].
	3342
	3343	C.1. Changes from HTTP/1.0
	3344
	3345	This section summarizes major differences between versions HTTP/1.0
	3346	and HTTP/1.1.
	3347
	3348	C.1.1. Changes to Simplify Multi-homed Web Servers and Conserve IP
	3349	Addresses
	3350
	3351	The requirements that clients and servers support the Host request-
	3352	header, report an error if the Host request-header (Section 8.4) is
	3353	missing from an HTTP/1.1 request, and accept absolute URIs
	3354	(Section 5.1.2) are among the most important changes defined by this
	3355	specification.
	3356
	3357
	3358
	3359	Fielding, et al. Expires March 2, 2009 [Page 60]
	3360
	3361	Internet-Draft HTTP/1.1, Part 1 August 2008
	3362
	3363
	3364	Older HTTP/1.0 clients assumed a one-to-one relationship of IP
	3365	addresses and servers; there was no other established mechanism for
	3366	distinguishing the intended server of a request than the IP address
	3367	to which that request was directed. The changes outlined above will
	3368	allow the Internet, once older HTTP clients are no longer common, to
	3369	support multiple Web sites from a single IP address, greatly
	3370	simplifying large operational Web servers, where allocation of many
	3371	IP addresses to a single host has created serious problems. The
	3372	Internet will also be able to recover the IP addresses that have been
	3373	allocated for the sole purpose of allowing special-purpose domain
	3374	names to be used in root-level HTTP URLs. Given the rate of growth
	3375	of the Web, and the number of servers already deployed, it is
	3376	extremely important that all implementations of HTTP (including
	3377	updates to existing HTTP/1.0 applications) correctly implement these
	3378	requirements:
	3379
	3380	o Both clients and servers MUST support the Host request-header.
	3381
	3382	o A client that sends an HTTP/1.1 request MUST send a Host header.
	3383
	3384	o Servers MUST report a 400 (Bad Request) error if an HTTP/1.1
	3385	request does not include a Host request-header.
	3386
	3387	o Servers MUST accept absolute URIs.
	3388
	3389	C.2. Compatibility with HTTP/1.0 Persistent Connections
	3390
	3391	Some clients and servers might wish to be compatible with some
	3392	previous implementations of persistent connections in HTTP/1.0
	3393	clients and servers. Persistent connections in HTTP/1.0 are
	3394	explicitly negotiated as they are not the default behavior. HTTP/1.0
	3395	experimental implementations of persistent connections are faulty,
	3396	and the new facilities in HTTP/1.1 are designed to rectify these
	3397	problems. The problem was that some existing 1.0 clients may be
	3398	sending Keep-Alive to a proxy server that doesn't understand
	3399	Connection, which would then erroneously forward it to the next
	3400	inbound server, which would establish the Keep-Alive connection and
	3401	result in a hung HTTP/1.0 proxy waiting for the close on the
	3402	response. The result is that HTTP/1.0 clients must be prevented from
	3403	using Keep-Alive when talking to proxies.
	3404
	3405	However, talking to proxies is the most important use of persistent
	3406	connections, so that prohibition is clearly unacceptable. Therefore,
	3407	we need some other mechanism for indicating a persistent connection
	3408	is desired, which is safe to use even when talking to an old proxy
	3409	that ignores Connection. Persistent connections are the default for
	3410	HTTP/1.1 messages; we introduce a new keyword (Connection: close) for
	3411	declaring non-persistence. See Section 8.1.
	3412
	3413
	3414
	3415	Fielding, et al. Expires March 2, 2009 [Page 61]
	3416
	3417	Internet-Draft HTTP/1.1, Part 1 August 2008
	3418
	3419
	3420	The original HTTP/1.0 form of persistent connections (the Connection:
	3421	Keep-Alive and Keep-Alive header) is documented in [RFC2068].
	3422
	3423	C.3. Changes from RFC 2068
	3424
	3425	This specification has been carefully audited to correct and
	3426	disambiguate key word usage; RFC 2068 had many problems in respect to
	3427	the conventions laid out in [RFC2119].
	3428
	3429	Transfer-coding and message lengths all interact in ways that
	3430	required fixing exactly when chunked encoding is used (to allow for
	3431	transfer encoding that may not be self delimiting); it was important
	3432	to straighten out exactly how message lengths are computed.
	3433	(Sections 3.4, 4.4, 8.2, see also [Part3], [Part5] and [Part6])
	3434
	3435	The use and interpretation of HTTP version numbers has been clarified
	3436	by [RFC2145]. Require proxies to upgrade requests to highest
	3437	protocol version they support to deal with problems discovered in
	3438	HTTP/1.0 implementations (Section 3.1)
	3439
	3440	Transfer-coding had significant problems, particularly with
	3441	interactions with chunked encoding. The solution is that transfer-
	3442	codings become as full fledged as content-codings. This involves
	3443	adding an IANA registry for transfer-codings (separate from content
	3444	codings), a new header field (TE) and enabling trailer headers in the
	3445	future. Transfer encoding is a major performance benefit, so it was
	3446	worth fixing [Nie1997]. TE also solves another, obscure, downward
	3447	interoperability problem that could have occurred due to interactions
	3448	between authentication trailers, chunked encoding and HTTP/1.0
	3449	clients.(Section 3.4, 3.4.1, and 8.5)
	3450
	3451	C.4. Changes from RFC 2616
	3452
	3453	The CHAR rule does not allow the NUL character anymore (this affects
	3454	the comment and quoted-string rules). Furthermore, the quoted-pair
	3455	rule does not allow escaping NUL, CR or LF anymore. (Section 2.2)
	3456
	3457	Clarify that HTTP-Version is case sensitive. (Section 3.1)
	3458
	3459	Remove reference to non-existant identity transfer-coding value
	3460	tokens. (Sections 3.4 and 4.4)
	3461
	3462	Clarification that the chunk length does not include the count of the
	3463	octets in the chunk header and trailer. (Section 3.4.1)
	3464
	3465	Fix BNF to add query, as the abs_path production in Section 3 of
	3466	[RFC2396] doesn't define it. (Section 5.1.2)
	3467
	3468
	3469
	3470
	3471	Fielding, et al. Expires March 2, 2009 [Page 62]
	3472
	3473	Internet-Draft HTTP/1.1, Part 1 August 2008
	3474
	3475
	3476	Clarify exactly when close connection options must be sent.
	3477	(Section 8.1)
	3478
	3479
	3480	Appendix D. Change Log (to be removed by RFC Editor before publication)
	3481
	3482	D.1. Since RFC2616
	3483
	3484	Extracted relevant partitions from [RFC2616].
	3485
	3486	D.2. Since draft-ietf-httpbis-p1-messaging-00
	3487
	3488	Closed issues:
	3489
	3490	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/1>: "HTTP
	3491	Version should be case sensitive"
	3492	(<http://purl.org/NET/http-errata#verscase>)
	3493
	3494	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/2>: "'unsafe'
	3495	characters" (<http://purl.org/NET/http-errata#unsafe-uri>)
	3496
	3497	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/3>: "Chunk Size
	3498	Definition" (<http://purl.org/NET/http-errata#chunk-size>)
	3499
	3500	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/4>: "Message
	3501	Length" (<http://purl.org/NET/http-errata#msg-len-chars>)
	3502
	3503	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/8>: "Media Type
	3504	Registrations" (<http://purl.org/NET/http-errata#media-reg>)
	3505
	3506	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/11>: "URI
	3507	includes query" (<http://purl.org/NET/http-errata#uriquery>)
	3508
	3509	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/15>: "No close
	3510	on 1xx responses" (<http://purl.org/NET/http-errata#noclose1xx>)
	3511
	3512	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/16>: "Remove
	3513	'identity' token references"
	3514	(<http://purl.org/NET/http-errata#identity>)
	3515
	3516	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/26>: "Import
	3517	query BNF"
	3518
	3519	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/31>: "qdtext
	3520	BNF"
	3521
	3522	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative
	3523	and Informative references"
	3524
	3525
	3526
	3527	Fielding, et al. Expires March 2, 2009 [Page 63]
	3528
	3529	Internet-Draft HTTP/1.1, Part 1 August 2008
	3530
	3531
	3532	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/42>: "RFC2606
	3533	Compliance"
	3534
	3535	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/45>: "RFC977
	3536	reference"
	3537
	3538	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/46>: "RFC1700
	3539	references"
	3540
	3541	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/47>:
	3542	"inconsistency in date format explanation"
	3543
	3544	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/48>: "Date
	3545	reference typo"
	3546
	3547	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/65>:
	3548	"Informative references"
	3549
	3550	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/66>:
	3551	"ISO-8859-1 Reference"
	3552
	3553	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/86>: "Normative
	3554	up-to-date references"
	3555
	3556	Other changes:
	3557
	3558	o Update media type registrations to use RFC4288 template.
	3559
	3560	o Use names of RFC4234 core rules DQUOTE and HTAB, fix broken ABNF
	3561	for chunk-data (work in progress on
	3562	<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36>)
	3563
	3564	D.3. Since draft-ietf-httpbis-p1-messaging-01
	3565
	3566	Closed issues:
	3567
	3568	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/19>: "Bodies on
	3569	GET (and other) requests"
	3570
	3571	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/55>: "Updating
	3572	to RFC4288"
	3573
	3574	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/57>: "Status
	3575	Code and Reason Phrase"
	3576
	3577	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/82>: "rel_path
	3578	not used"
	3579
	3580
	3581
	3582
	3583	Fielding, et al. Expires March 2, 2009 [Page 64]
	3584
	3585	Internet-Draft HTTP/1.1, Part 1 August 2008
	3586
	3587
	3588	Ongoing work on ABNF conversion
	3589	(<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36>):
	3590
	3591	o Get rid of duplicate BNF rule names ("host" -> "uri-host",
	3592	"trailer" -> "trailer-part").
	3593
	3594	o Avoid underscore character in rule names ("http_URL" -> "http-
	3595	URL", "abs_path" -> "path-absolute").
	3596
	3597	o Add rules for terms imported from URI spec ("absoluteURI",
	3598	"authority", "path-absolute", "port", "query", "relativeURI",
	3599	"host) -- these will have to be updated when switching over to
	3600	RFC3986.
	3601
	3602	o Synchronize core rules with RFC5234 (this includes a change to
	3603	CHAR which now excludes NUL).
	3604
	3605	o Get rid of prose rules that span multiple lines.
	3606
	3607	o Get rid of unused rules LOALPHA and UPALPHA.
	3608
	3609	o Move "Product Tokens" section (back) into Part 1, as "token" is
	3610	used in the definition of the Upgrade header.
	3611
	3612	o Add explicit references to BNF syntax and rules imported from
	3613	other parts of the specification.
	3614
	3615	o Rewrite prose rule "token" in terms of "tchar", rewrite prose rule
	3616	"TEXT".
	3617
	3618	D.4. Since draft-ietf-httpbis-p1-messaging-02
	3619
	3620	Closed issues:
	3621
	3622	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/51>: "HTTP-date
	3623	vs. rfc1123-date"
	3624
	3625	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/64>: "WS in
	3626	quoted-pair"
	3627
	3628	Ongoing work on IANA Message Header Registration
	3629	(<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/40>):
	3630
	3631	o Reference RFC 3984, and update header registrations for headers
	3632	defined in this document.
	3633
	3634	Ongoing work on ABNF conversion
	3635	(<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36>):
	3636
	3637
	3638
	3639	Fielding, et al. Expires March 2, 2009 [Page 65]
	3640
	3641	Internet-Draft HTTP/1.1, Part 1 August 2008
	3642
	3643
	3644	o Replace string literals when the string really is case-sensitive
	3645	(HTTP-Version).
	3646
	3647	D.5. Since draft-ietf-httpbis-p1-messaging-03
	3648
	3649	Closed issues:
	3650
	3651	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/28>:
	3652	"Connection closing"
	3653
	3654	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/97>: "Move
	3655	registrations and registry information to IANA Considerations"
	3656
	3657	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/120>: "need new
	3658	URL for PAD1995 reference"
	3659
	3660	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/127>: "IANA
	3661	Considerations: update HTTP URI scheme registration"
	3662
	3663	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/128>: "Cite
	3664	HTTPS URI scheme definition"
	3665
	3666	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/129>: "List-
	3667	type headers vs Set-Cookie"
	3668
	3669	Ongoing work on ABNF conversion
	3670	(<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36>):
	3671
	3672	o Replace string literals when the string really is case-sensitive
	3673	(HTTP-Date).
	3674
	3675	o Replace HEX by HEXDIG for future consistence with RFC 5234's core
	3676	rules.
	3677
	3678
	3679	Index
	3680
	3681	A
	3682	application/http Media Type 50
	3683
	3684	C
	3685	cache 8
	3686	cacheable 9
	3687	client 7
	3688	connection 6
	3689	Connection header 40
	3690	content negotiation 7
	3691	Content-Length header 41
	3692
	3693
	3694
	3695	Fielding, et al. Expires March 2, 2009 [Page 66]
	3696
	3697	Internet-Draft HTTP/1.1, Part 1 August 2008
	3698
	3699
	3700	D
	3701	Date header 42
	3702	downstream 9
	3703
	3704	E
	3705	entity 7
	3706
	3707	G
	3708	gateway 8
	3709	Grammar
	3710	absoluteURI 18
	3711	ALPHA 14
	3712	asctime-date 20
	3713	attribute 21
	3714	authority 18
	3715	CHAR 14
	3716	chunk 22
	3717	chunk-data 22
	3718	chunk-ext-name 22
	3719	chunk-ext-val 22
	3720	chunk-extension 22
	3721	chunk-size 22
	3722	Chunked-Body 22
	3723	comment 15
	3724	Connection 40
	3725	connection-token 40
	3726	Content-Length 41
	3727	CR 14
	3728	CRLF 14
	3729	ctext 15
	3730	CTL 14
	3731	Date 42
	3732	date1 20
	3733	date2 20
	3734	date3 20
	3735	DIGIT 14
	3736	DQUOTE 14
	3737	extension-code 33
	3738	extension-method 29
	3739	field-content 25
	3740	field-name 25
	3741	field-value 25
	3742	general-header 29
	3743	generic-message 25
	3744	HEXDIG 15
	3745	Host 43
	3746	HTAB 14
	3747	HTTP-date 20
	3748
	3749
	3750
	3751	Fielding, et al. Expires March 2, 2009 [Page 67]
	3752
	3753	Internet-Draft HTTP/1.1, Part 1 August 2008
	3754
	3755
	3756	HTTP-message 24
	3757	HTTP-Prot-Name 16
	3758	http-URL 18
	3759	HTTP-Version 16
	3760	last-chunk 22
	3761	LF 14
	3762	LWS 14
	3763	message-body 26
	3764	message-header 25
	3765	Method 29
	3766	month 20
	3767	obsolete-date 20
	3768	OCTET 14
	3769	parameter 21
	3770	path-absolute 18
	3771	port 18
	3772	product 24
	3773	product-version 24
	3774	protocol-name 47
	3775	protocol-version 47
	3776	pseudonym 47
	3777	qdtext 15
	3778	query 18
	3779	quoted-pair 15
	3780	quoted-string 15
	3781	quoted-text 15
	3782	Reason-Phrase 33
	3783	received-by 47
	3784	received-protocol 47
	3785	relativeURI 18
	3786	Request 29
	3787	Request-Line 29
	3788	Request-URI 30
	3789	Response 32
	3790	rfc850-date 20
	3791	rfc1123-date 20
	3792	separators 15
	3793	SP 14
	3794	start-line 25
	3795	Status-Code 33
	3796	Status-Line 32
	3797	t-codings 44
	3798	tchar 15
	3799	TE 44
	3800	TEXT 14
	3801	time 20
	3802	token 15
	3803	Trailer 45
	3804
	3805
	3806
	3807	Fielding, et al. Expires March 2, 2009 [Page 68]
	3808
	3809	Internet-Draft HTTP/1.1, Part 1 August 2008
	3810
	3811
	3812	trailer-part 22
	3813	transfer-coding 21
	3814	Transfer-Encoding 45
	3815	transfer-extension 21
	3816	Upgrade 46
	3817	uri-host 18
	3818	value 21
	3819	Via 47
	3820	weekday 20
	3821	wkday 20
	3822
	3823	H
	3824	Headers
	3825	Connection 40
	3826	Content-Length 41
	3827	Date 42
	3828	Host 43
	3829	TE 44
	3830	Trailer 45
	3831	Transfer-Encoding 45
	3832	Upgrade 46
	3833	Via 47
	3834	Host header 43
	3835	http URI scheme 18
	3836	https URI scheme 18
	3837
	3838	I
	3839	implied *LWS 13
	3840	inbound 9
	3841
	3842	M
	3843	Media Type
	3844	application/http 50
	3845	message/http 49
	3846	message 6
	3847	message/http Media Type 49
	3848
	3849	O
	3850	origin server 8
	3851	outbound 9
	3852
	3853	P
	3854	proxy 8
	3855
	3856	R
	3857	representation 7
	3858	request 6
	3859	resource 7
	3860
	3861
	3862
	3863	Fielding, et al. Expires March 2, 2009 [Page 69]
	3864
	3865	Internet-Draft HTTP/1.1, Part 1 August 2008
	3866
	3867
	3868	response 6
	3869
	3870	S
	3871	server 8
	3872
	3873	T
	3874	TE header 44
	3875	Trailer header 45
	3876	Transfer-Encoding header 45
	3877	tunnel 8
	3878
	3879	U
	3880	Upgrade header 46
	3881	upstream 9
	3882	URI scheme
	3883	http 18
	3884	https 18
	3885	user agent 7
	3886
	3887	V
	3888	variant 7
	3889	Via header 47
	3890
	3891
	3892	Authors' Addresses
	3893
	3894	Roy T. Fielding (editor)
	3895	Day Software
	3896	23 Corporate Plaza DR, Suite 280
	3897	Newport Beach, CA 92660
	3898	USA
	3899
	3900	Phone: +1-949-706-5300
	3901	Fax: +1-949-706-5305
	3902	Email: fielding@gbiv.com
	3903	URI: http://roy.gbiv.com/
	3904
	3905
	3906	Jim Gettys
	3907	One Laptop per Child
	3908	21 Oak Knoll Road
	3909	Carlisle, MA 01741
	3910	USA
	3911
	3912	Email: jg@laptop.org
	3913	URI: http://www.laptop.org/
	3914
	3915
	3916
	3917
	3918
	3919	Fielding, et al. Expires March 2, 2009 [Page 70]
	3920
	3921	Internet-Draft HTTP/1.1, Part 1 August 2008
	3922
	3923
	3924	Jeffrey C. Mogul
	3925	Hewlett-Packard Company
	3926	HP Labs, Large Scale Systems Group
	3927	1501 Page Mill Road, MS 1177
	3928	Palo Alto, CA 94304
	3929	USA
	3930
	3931	Email: JeffMogul@acm.org
	3932
	3933
	3934	Henrik Frystyk Nielsen
	3935	Microsoft Corporation
	3936	1 Microsoft Way
	3937	Redmond, WA 98052
	3938	USA
	3939
	3940	Email: henrikn@microsoft.com
	3941
	3942
	3943	Larry Masinter
	3944	Adobe Systems, Incorporated
	3945	345 Park Ave
	3946	San Jose, CA 95110
	3947	USA
	3948
	3949	Email: LMM@acm.org
	3950	URI: http://larry.masinter.net/
	3951
	3952
	3953	Paul J. Leach
	3954	Microsoft Corporation
	3955	1 Microsoft Way
	3956	Redmond, WA 98052
	3957
	3958	Email: paulle@microsoft.com
	3959
	3960
	3961	Tim Berners-Lee
	3962	World Wide Web Consortium
	3963	MIT Computer Science and Artificial Intelligence Laboratory
	3964	The Stata Center, Building 32
	3965	32 Vassar Street
	3966	Cambridge, MA 02139
	3967	USA
	3968
	3969	Email: timbl@w3.org
	3970	URI: http://www.w3.org/People/Berners-Lee/
	3971
	3972
	3973
	3974
	3975	Fielding, et al. Expires March 2, 2009 [Page 71]
	3976
	3977	Internet-Draft HTTP/1.1, Part 1 August 2008
	3978
	3979
	3980	Yves Lafon (editor)
	3981	World Wide Web Consortium
	3982	W3C / ERCIM
	3983	2004, rte des Lucioles
	3984	Sophia-Antipolis, AM 06902
	3985	France
	3986
	3987	Email: ylafon@w3.org
	3988	URI: http://www.raubacapeu.net/people/yves/
	3989
	3990
	3991	Julian F. Reschke (editor)
	3992	greenbytes GmbH
	3993	Hafenweg 16
	3994	Muenster, NW 48155
	3995	Germany
	3996
	3997	Phone: +49 251 2807760
	3998	Fax: +49 251 2807761
	3999	Email: julian.reschke@greenbytes.de
	4000	URI: http://greenbytes.de/tech/webdav/
	4001
	4002
	4003
	4004
	4005
	4006
	4007
	4008
	4009
	4010
	4011
	4012
	4013
	4014
	4015
	4016
	4017
	4018
	4019
	4020
	4021
	4022
	4023
	4024
	4025
	4026
	4027
	4028
	4029
	4030
	4031	Fielding, et al. Expires March 2, 2009 [Page 72]
	4032
	4033	Internet-Draft HTTP/1.1, Part 1 August 2008
	4034
	4035
	4036	Full Copyright Statement
	4037
	4038	Copyright (C) The IETF Trust (2008).
	4039
	4040	This document is subject to the rights, licenses and restrictions
	4041	contained in BCP 78, and except as set forth therein, the authors
	4042	retain all their rights.
	4043
	4044	This document and the information contained herein are provided on an
	4045	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	4046	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
	4047	THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
	4048	OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
	4049	THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	4050	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	4051
	4052
	4053	Intellectual Property
	4054
	4055	The IETF takes no position regarding the validity or scope of any
	4056	Intellectual Property Rights or other rights that might be claimed to
	4057	pertain to the implementation or use of the technology described in
	4058	this document or the extent to which any license under such rights
	4059	might or might not be available; nor does it represent that it has
	4060	made any independent effort to identify any such rights. Information
	4061	on the procedures with respect to rights in RFC documents can be
	4062	found in BCP 78 and BCP 79.
	4063
	4064	Copies of IPR disclosures made to the IETF Secretariat and any
	4065	assurances of licenses to be made available, or the result of an
	4066	attempt made to obtain a general license or permission for the use of
	4067	such proprietary rights by implementers or users of this
	4068	specification can be obtained from the IETF on-line IPR repository at
	4069	http://www.ietf.org/ipr.
	4070
	4071	The IETF invites any interested party to bring to its attention any
	4072	copyrights, patents or patent applications, or other proprietary
	4073	rights that may cover technology that may be required to implement
	4074	this standard. Please address the information to the IETF at
	4075	ietf-ipr@ietf.org.
	4076
	4077
	4078
	4079
	4080
	4081
	4082
	4083
	4084
	4085
	4086
	4087	Fielding, et al. Expires March 2, 2009 [Page 73]
	4088

Note: See TracBrowser for help on using the repository browser.

Context Navigation

source: draft-ietf-httpbis/04/draft-ietf-httpbis-p1-messaging-04.txt @ 2111

Download in other formats: