Context Navigation

draft-ietf-httpbis-p1-messaging-03.txt @ 682

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

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

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

Context Navigation

source: draft-ietf-httpbis/03/draft-ietf-httpbis-p1-messaging-03.txt @ 682

Download in other formats: