Context Navigation

draft-ietf-httpbis-p2-semantics-19.txt @ 1596

Last change on this file since 1596 was 1596, checked in by fielding@…, 11 years ago
remove executable bit
Property svn:eol-style set to `native`
File size: 150.6 KB

Line
1
2
3
4	HTTPbis Working Group R. Fielding, Ed.
5	Internet-Draft Adobe
6	Obsoletes: 2616 (if approved) Y. Lafon, Ed.
7	Updates: 2817 (if approved) W3C
8	Intended status: Standards Track J. Reschke, Ed.
9	Expires: September 13, 2012 greenbytes
10	March 12, 2012
11
12
13	HTTP/1.1, part 2: Message Semantics
14	draft-ietf-httpbis-p2-semantics-19
15
16	Abstract
17
18	The Hypertext Transfer Protocol (HTTP) is an application-level
19	protocol for distributed, collaborative, hypertext information
20	systems. HTTP has been in use by the World Wide Web global
21	information initiative since 1990. This document is Part 2 of the
22	seven-part specification that defines the protocol referred to as
23	"HTTP/1.1" and, taken together, obsoletes RFC 2616.
24
25	Part 2 defines the semantics of HTTP messages as expressed by request
26	methods, request header fields, response status codes, and response
27	header fields.
28
29	Editorial Note (To be removed by RFC Editor)
30
31	Discussion of this draft should take place on the HTTPBIS working
32	group mailing list (ietf-http-wg@w3.org), which is archived at
33	<http://lists.w3.org/Archives/Public/ietf-http-wg/>.
34
35	The current issues list is at
36	<http://tools.ietf.org/wg/httpbis/trac/report/3> and related
37	documents (including fancy diffs) can be found at
38	<http://tools.ietf.org/wg/httpbis/>.
39
40	The changes in this draft are summarized in Appendix C.20.
41
42	Status of This Memo
43
44	This Internet-Draft is submitted in full conformance with the
45	provisions of BCP 78 and BCP 79.
46
47	Internet-Drafts are working documents of the Internet Engineering
48	Task Force (IETF). Note that other groups may also distribute
49	working documents as Internet-Drafts. The list of current Internet-
50	Drafts is at http://datatracker.ietf.org/drafts/current/.
51
52
53
54
55	Fielding, et al. Expires September 13, 2012 [Page 1]
56
57	Internet-Draft HTTP/1.1, Part 2 March 2012
58
59
60	Internet-Drafts are draft documents valid for a maximum of six months
61	and may be updated, replaced, or obsoleted by other documents at any
62	time. It is inappropriate to use Internet-Drafts as reference
63	material or to cite them other than as "work in progress."
64
65	This Internet-Draft will expire on September 13, 2012.
66
67	Copyright Notice
68
69	Copyright (c) 2012 IETF Trust and the persons identified as the
70	document authors. All rights reserved.
71
72	This document is subject to BCP 78 and the IETF Trust's Legal
73	Provisions Relating to IETF Documents
74	(http://trustee.ietf.org/license-info) in effect on the date of
75	publication of this document. Please review these documents
76	carefully, as they describe your rights and restrictions with respect
77	to this document. Code Components extracted from this document must
78	include Simplified BSD License text as described in Section 4.e of
79	the Trust Legal Provisions and are provided without warranty as
80	described in the Simplified BSD License.
81
82	This document may contain material from IETF Documents or IETF
83	Contributions published or made publicly available before November
84	10, 2008. The person(s) controlling the copyright in some of this
85	material may not have granted the IETF Trust the right to allow
86	modifications of such material outside the IETF Standards Process.
87	Without obtaining an adequate license from the person(s) controlling
88	the copyright in such materials, this document may not be modified
89	outside the IETF Standards Process, and derivative works of it may
90	not be created outside the IETF Standards Process, except to format
91	it for publication as an RFC or to translate it into languages other
92	than English.
93
94	Table of Contents
95
96	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
97	1.1. Conformance and Error Handling . . . . . . . . . . . . . 6
98	1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7
99	1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 7
100	1.2.2. ABNF Rules defined in other Parts of the
101	Specification . . . . . . . . . . . . . . . . . . . . 7
102	2. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
103	2.1. Overview of Methods . . . . . . . . . . . . . . . . . . . 8
104	2.2. Method Registry . . . . . . . . . . . . . . . . . . . . . 8
105	2.2.1. Considerations for New Methods . . . . . . . . . . . . 9
106	3. Header Fields . . . . . . . . . . . . . . . . . . . . . . . . 9
107	3.1. Considerations for Creating Header Fields . . . . . . . . 9
108
109
110
111	Fielding, et al. Expires September 13, 2012 [Page 2]
112
113	Internet-Draft HTTP/1.1, Part 2 March 2012
114
115
116	3.2. Request Header Fields . . . . . . . . . . . . . . . . . . 11
117	3.3. Response Header Fields . . . . . . . . . . . . . . . . . 12
118	4. Status Code and Reason Phrase . . . . . . . . . . . . . . . . 12
119	4.1. Overview of Status Codes . . . . . . . . . . . . . . . . 13
120	4.2. Status Code Registry . . . . . . . . . . . . . . . . . . 15
121	4.2.1. Considerations for New Status Codes . . . . . . . . . 15
122	5. Representation . . . . . . . . . . . . . . . . . . . . . . . . 16
123	5.1. Identifying the Resource Associated with a
124	Representation . . . . . . . . . . . . . . . . . . . . . 16
125	6. Method Definitions . . . . . . . . . . . . . . . . . . . . . . 17
126	6.1. Safe and Idempotent Methods . . . . . . . . . . . . . . . 17
127	6.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . 17
128	6.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . . 17
129	6.2. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 18
130	6.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
131	6.4. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . 19
132	6.5. POST . . . . . . . . . . . . . . . . . . . . . . . . . . 20
133	6.6. PUT . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
134	6.7. DELETE . . . . . . . . . . . . . . . . . . . . . . . . . 23
135	6.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . . . 23
136	6.9. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . . 24
137	7. Status Code Definitions . . . . . . . . . . . . . . . . . . . 25
138	7.1. Informational 1xx . . . . . . . . . . . . . . . . . . . . 26
139	7.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 26
140	7.1.2. 101 Switching Protocols . . . . . . . . . . . . . . . 27
141	7.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . 27
142	7.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 27
143	7.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 27
144	7.2.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 28
145	7.2.4. 203 Non-Authoritative Information . . . . . . . . . . 28
146	7.2.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 28
147	7.2.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 29
148	7.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 29
149	7.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 31
150	7.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 31
151	7.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 32
152	7.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 32
153	7.3.5. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 33
154	7.3.6. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 33
155	7.3.7. 307 Temporary Redirect . . . . . . . . . . . . . . . . 33
156	7.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 33
157	7.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 33
158	7.4.2. 402 Payment Required . . . . . . . . . . . . . . . . . 33
159	7.4.3. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 33
160	7.4.4. 404 Not Found . . . . . . . . . . . . . . . . . . . . 34
161	7.4.5. 405 Method Not Allowed . . . . . . . . . . . . . . . . 34
162	7.4.6. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 34
163	7.4.7. 408 Request Timeout . . . . . . . . . . . . . . . . . 35
164
165
166
167	Fielding, et al. Expires September 13, 2012 [Page 3]
168
169	Internet-Draft HTTP/1.1, Part 2 March 2012
170
171
172	7.4.8. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 35
173	7.4.9. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 35
174	7.4.10. 411 Length Required . . . . . . . . . . . . . . . . . 36
175	7.4.11. 413 Request Representation Too Large . . . . . . . . . 36
176	7.4.12. 414 URI Too Long . . . . . . . . . . . . . . . . . . . 36
177	7.4.13. 415 Unsupported Media Type . . . . . . . . . . . . . . 36
178	7.4.14. 417 Expectation Failed . . . . . . . . . . . . . . . . 36
179	7.4.15. 426 Upgrade Required . . . . . . . . . . . . . . . . . 37
180	7.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 37
181	7.5.1. 500 Internal Server Error . . . . . . . . . . . . . . 37
182	7.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 37
183	7.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 37
184	7.5.4. 503 Service Unavailable . . . . . . . . . . . . . . . 38
185	7.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 38
186	7.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 38
187	8. Date/Time Formats . . . . . . . . . . . . . . . . . . . . . . 38
188	9. Product Tokens . . . . . . . . . . . . . . . . . . . . . . . . 41
189	10. Header Field Definitions . . . . . . . . . . . . . . . . . . . 42
190	10.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . . . 42
191	10.2. Date . . . . . . . . . . . . . . . . . . . . . . . . . . 42
192	10.3. Expect . . . . . . . . . . . . . . . . . . . . . . . . . 43
193	10.4. From . . . . . . . . . . . . . . . . . . . . . . . . . . 44
194	10.5. Location . . . . . . . . . . . . . . . . . . . . . . . . 45
195	10.6. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . 46
196	10.7. Referer . . . . . . . . . . . . . . . . . . . . . . . . . 46
197	10.8. Retry-After . . . . . . . . . . . . . . . . . . . . . . . 47
198	10.9. Server . . . . . . . . . . . . . . . . . . . . . . . . . 47
199	10.10. User-Agent . . . . . . . . . . . . . . . . . . . . . . . 48
200	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49
201	11.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 49
202	11.2. Status Code Registry . . . . . . . . . . . . . . . . . . 49
203	11.3. Header Field Registration . . . . . . . . . . . . . . . . 50
204	12. Security Considerations . . . . . . . . . . . . . . . . . . . 51
205	12.1. Transfer of Sensitive Information . . . . . . . . . . . . 51
206	12.2. Encoding Sensitive Information in URIs . . . . . . . . . 52
207	12.3. Location Header Fields: Spoofing and Information
208	Leakage . . . . . . . . . . . . . . . . . . . . . . . . . 53
209	12.4. Security Considerations for CONNECT . . . . . . . . . . . 53
210	13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53
211	14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53
212	14.1. Normative References . . . . . . . . . . . . . . . . . . 53
213	14.2. Informative References . . . . . . . . . . . . . . . . . 54
214	Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 55
215	Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 56
216	Appendix C. Change Log (to be removed by RFC Editor before
217	publication) . . . . . . . . . . . . . . . . . . . . 59
218	C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . 59
219	C.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . 59
220
221
222
223	Fielding, et al. Expires September 13, 2012 [Page 4]
224
225	Internet-Draft HTTP/1.1, Part 2 March 2012
226
227
228	C.3. Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . 60
229	C.4. Since draft-ietf-httpbis-p2-semantics-02 . . . . . . . . 60
230	C.5. Since draft-ietf-httpbis-p2-semantics-03 . . . . . . . . 61
231	C.6. Since draft-ietf-httpbis-p2-semantics-04 . . . . . . . . 61
232	C.7. Since draft-ietf-httpbis-p2-semantics-05 . . . . . . . . 62
233	C.8. Since draft-ietf-httpbis-p2-semantics-06 . . . . . . . . 62
234	C.9. Since draft-ietf-httpbis-p2-semantics-07 . . . . . . . . 62
235	C.10. Since draft-ietf-httpbis-p2-semantics-08 . . . . . . . . 63
236	C.11. Since draft-ietf-httpbis-p2-semantics-09 . . . . . . . . 63
237	C.12. Since draft-ietf-httpbis-p2-semantics-10 . . . . . . . . 63
238	C.13. Since draft-ietf-httpbis-p2-semantics-11 . . . . . . . . 64
239	C.14. Since draft-ietf-httpbis-p2-semantics-12 . . . . . . . . 64
240	C.15. Since draft-ietf-httpbis-p2-semantics-13 . . . . . . . . 66
241	C.16. Since draft-ietf-httpbis-p2-semantics-14 . . . . . . . . 66
242	C.17. Since draft-ietf-httpbis-p2-semantics-15 . . . . . . . . 66
243	C.18. Since draft-ietf-httpbis-p2-semantics-16 . . . . . . . . 66
244	C.19. Since draft-ietf-httpbis-p2-semantics-17 . . . . . . . . 67
245	C.20. Since draft-ietf-httpbis-p2-semantics-18 . . . . . . . . 67
246	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279	Fielding, et al. Expires September 13, 2012 [Page 5]
280
281	Internet-Draft HTTP/1.1, Part 2 March 2012
282
283
284	1. Introduction
285
286	This document defines HTTP/1.1 request and response semantics. Each
287	HTTP message, as defined in [Part1], is in the form of either a
288	request or a response. An HTTP server listens on a connection for
289	HTTP requests and responds to each request, in the order received on
290	that connection, with one or more HTTP response messages. This
291	document defines the commonly agreed upon semantics of the HTTP
292	uniform interface, the intentions defined by each request method, and
293	the various response messages that might be expected as a result of
294	applying that method to the target resource.
295
296	This document is currently disorganized in order to minimize the
297	changes between drafts and enable reviewers to see the smaller errata
298	changes. A future draft will reorganize the sections to better
299	reflect the content. In particular, the sections will be ordered
300	according to the typical processing of an HTTP request message (after
301	message parsing): resource mapping, methods, request modifying header
302	fields, response status, status modifying header fields, and resource
303	metadata. The current mess reflects how widely dispersed these
304	topics and associated requirements had become in [RFC2616].
305
306	1.1. Conformance and Error Handling
307
308	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
309	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
310	document are to be interpreted as described in [RFC2119].
311
312	This document defines conformance criteria for several roles in HTTP
313	communication, including Senders, Recipients, Clients, Servers, User-
314	Agents, Origin Servers, Intermediaries, Proxies and Gateways. See
315	Section 2 of [Part1] for definitions of these terms.
316
317	An implementation is considered conformant if it complies with all of
318	the requirements associated with its role(s). Note that SHOULD-level
319	requirements are relevant here, unless one of the documented
320	exceptions is applicable.
321
322	This document also uses ABNF to define valid protocol elements
323	(Section 1.2). In addition to the prose requirements placed upon
324	them, Senders MUST NOT generate protocol elements that are invalid.
325
326	Unless noted otherwise, Recipients MAY take steps to recover a usable
327	protocol element from an invalid construct. However, HTTP does not
328	define specific error handling mechanisms, except in cases where it
329	has direct impact on security. This is because different uses of the
330	protocol require different error handling strategies; for example, a
331	Web browser may wish to transparently recover from a response where
332
333
334
335	Fielding, et al. Expires September 13, 2012 [Page 6]
336
337	Internet-Draft HTTP/1.1, Part 2 March 2012
338
339
340	the Location header field doesn't parse according to the ABNF,
341	whereby in a systems control protocol using HTTP, this type of error
342	recovery could lead to dangerous consequences.
343
344	1.2. Syntax Notation
345
346	This specification uses the Augmented Backus-Naur Form (ABNF)
347	notation of [RFC5234] with the list rule extension defined in Section
348	1.2 of [Part1]. Appendix B shows the collected ABNF with the list
349	rule expanded.
350
351	The following core rules are included by reference, as defined in
352	[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
353	(CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
354	HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line
355	feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any
356	visible US-ASCII character).
357
358	1.2.1. Core Rules
359
360	The core rules below are defined in [Part1]:
361
362	BWS = <BWS, defined in [Part1], Section 3.2.1>
363	OWS = <OWS, defined in [Part1], Section 3.2.1>
364	RWS = <RWS, defined in [Part1], Section 3.2.1>
365	obs-text = <obs-text, defined in [Part1], Section 3.2.4>
366	quoted-string = <quoted-string, defined in [Part1], Section 3.2.4>
367	token = <token, defined in [Part1], Section 3.2.4>
368
369	1.2.2. ABNF Rules defined in other Parts of the Specification
370
371	The ABNF rules below are defined in other parts:
372
373	absolute-URI = <absolute-URI, defined in [Part1], Section 2.7>
374	comment = <comment, defined in [Part1], Section 3.2.4>
375	partial-URI = <partial-URI, defined in [Part1], Section 2.7>
376	URI-reference = <URI-reference, defined in [Part1], Section 2.7>
377
378	2. Method
379
380	The method token indicates the request method to be performed on the
381	target resource (Section 5.5 of [Part1]). The method is case-
382	sensitive.
383
384	method = token
385
386	The list of methods allowed by a resource can be specified in an
387	Allow header field (Section 10.1). The status code of the response
388
389
390
391	Fielding, et al. Expires September 13, 2012 [Page 7]
392
393	Internet-Draft HTTP/1.1, Part 2 March 2012
394
395
396	always notifies the client whether a method is currently allowed on a
397	resource, since the set of allowed methods can change dynamically.
398	An origin server SHOULD respond with the status code 405 (Method Not
399	Allowed) if the method is known by the origin server but not allowed
400	for the resource, and 501 (Not Implemented) if the method is
401	unrecognized or not implemented by the origin server. The methods
402	GET and HEAD MUST be supported by all general-purpose servers. All
403	other methods are OPTIONAL; however, if the above methods are
404	implemented, they MUST be implemented with the same semantics as
405	those specified in Section 6.
406
407	2.1. Overview of Methods
408
409	The methods listed below are defined in Section 6.
410
411	+-------------+---------------+
412	\| Method Name \| Defined in... \|
413	+-------------+---------------+
414	\| OPTIONS \| Section 6.2 \|
415	\| GET \| Section 6.3 \|
416	\| HEAD \| Section 6.4 \|
417	\| POST \| Section 6.5 \|
418	\| PUT \| Section 6.6 \|
419	\| DELETE \| Section 6.7 \|
420	\| TRACE \| Section 6.8 \|
421	\| CONNECT \| Section 6.9 \|
422	+-------------+---------------+
423
424	Note that this list is not exhaustive -- it does not include request
425	methods defined in other specifications.
426
427	2.2. Method Registry
428
429	The HTTP Method Registry defines the name space for the method token
430	in the Request line of an HTTP request.
431
432	Registrations MUST include the following fields:
433
434	o Method Name (see Section 2)
435
436	o Safe ("yes" or "no", see Section 6.1.1)
437
438	o Pointer to specification text
439
440	Values to be added to this name space require IETF Review (see
441	[RFC5226], Section 4.1).
442
443	The registry itself is maintained at
444
445
446
447	Fielding, et al. Expires September 13, 2012 [Page 8]
448
449	Internet-Draft HTTP/1.1, Part 2 March 2012
450
451
452	<http://www.iana.org/assignments/http-methods>.
453
454	2.2.1. Considerations for New Methods
455
456	When it is necessary to express new semantics for a HTTP request that
457	aren't specific to a single application or media type, and currently
458	defined methods are inadequate, it may be appropriate to register a
459	new method.
460
461	HTTP methods are generic; that is, they are potentially applicable to
462	any resource, not just one particular media type, "type" of resource,
463	or application. As such, it is preferred that new HTTP methods be
464	registered in a document that isn't specific to a single application,
465	so that this is clear.
466
467	Due to the parsing rules defined in Section 3.3 of [Part1],
468	definitions of HTTP methods cannot prohibit the presence of a message
469	body on either the request or the response message (with responses to
470	HEAD requests being the single exception). Definitions of new
471	methods cannot change this rule, but they can specify that only zero-
472	length bodies (as opposed to absent bodies) are allowed.
473
474	New method definitions need to indicate whether they are safe
475	(Section 6.1.1), what semantics (if any) the request body has, and
476	whether they are idempotent (Section 6.1.2). They also need to state
477	whether they can be cached ([Part6]); in particular what conditions a
478	cache may store the response, and under what conditions such a stored
479	response may be used to satisfy a subsequent request.
480
481	3. Header Fields
482
483	Header fields are key value pairs that can be used to communicate
484	data about the message, its payload, the target resource, or about
485	the connection itself (i.e., control data). See Section 3.2 of
486	[Part1] for a general definition of their syntax.
487
488	3.1. Considerations for Creating Header Fields
489
490	New header fields are registered using the procedures described in
491	[RFC3864].
492
493	The requirements for header field names are defined in Section 4.1 of
494	[RFC3864]. Authors of specifications defining new fields are advised
495	to keep the name as short as practical, and not to prefix them with
496	"X-" if they are to be registered (either immediately or in the
497	future).
498
499	New header field values typically have their syntax defined using
500
501
502
503	Fielding, et al. Expires September 13, 2012 [Page 9]
504
505	Internet-Draft HTTP/1.1, Part 2 March 2012
506
507
508	ABNF ([RFC5234]), using the extension defined in Section 3.2.5 of
509	[Part1] as necessary, and are usually constrained to the range of
510	ASCII characters. Header fields needing a greater range of
511	characters can use an encoding such as the one defined in [RFC5987].
512
513	Because commas (",") are used as a generic delimiter between field-
514	values, they need to be treated with care if they are allowed in the
515	field-value's payload. Typically, components that might contain a
516	comma are protected with double-quotes using the quoted-string ABNF
517	production (Section 3.2.4 of [Part1]).
518
519	For example, a textual date and a URI (either of which might contain
520	a comma) could be safely carried in field-values like these:
521
522	Example-URI-Field: "http://example.com/a.html,foo",
523	"http://without-a-comma.example.com/"
524	Example-Date-Field: "Sat, 04 May 1996", "Wed, 14 Sep 2005"
525
526	Note that double quote delimiters almost always are used with the
527	quoted-string production; using a different syntax inside double
528	quotes will likely cause unnecessary confusion.
529
530	Many header fields use a format including (case-insensitively) named
531	parameters (for instance, Content-Type, defined in Section 6.8 of
532	[Part3]). Allowing both unquoted (token) and quoted (quoted-string)
533	syntax for the parameter value enables recipients to use existing
534	parser components. When allowing both forms, the meaning of a
535	parameter value ought to be independent of the syntax used for it
536	(for an example, see the notes on parameter handling for media types
537	in Section 2.3 of [Part3]).
538
539	Authors of specifications defining new header fields are advised to
540	consider documenting:
541
542	o Whether the field is a single value, or whether it can be a list
543	(delimited by commas; see Section 3.2 of [Part1]).
544
545	If it does not use the list syntax, document how to treat messages
546	where the header field occurs multiple times (a sensible default
547	would be to ignore the header field, but this might not always be
548	the right choice).
549
550	Note that intermediaries and software libraries might combine
551	multiple header field instances into a single one, despite the
552	header field not allowing this. A robust format enables
553	recipients to discover these situations (good example: "Content-
554	Type", as the comma can only appear inside quoted strings; bad
555	example: "Location", as a comma can occur inside a URI).
556
557
558
559	Fielding, et al. Expires September 13, 2012 [Page 10]
560
561	Internet-Draft HTTP/1.1, Part 2 March 2012
562
563
564	o Under what conditions the header field can be used; e.g., only in
565	responses or requests, in all messages, only on responses to a
566	particular request method.
567
568	o Whether it is appropriate to list the field-name in the Connection
569	header (i.e., if the header is to be hop-by-hop, see Section 6.1
570	of [Part1]).
571
572	o Under what conditions intermediaries are allowed to modify the
573	header field's value, insert or delete it.
574
575	o How the header might interact with caching (see [Part6]).
576
577	o Whether the header field is useful or allowable in trailers (see
578	Section 4.1 of [Part1]).
579
580	o Whether the header field should be preserved across redirects.
581
582	3.2. Request Header Fields
583
584	The request header fields allow the client to pass additional
585	information about the request, and about the client itself, to the
586	server. These fields act as request modifiers, with semantics
587	equivalent to the parameters on a programming language method
588	invocation.
589
590	+---------------------+------------------------+
591	\| Header Field Name \| Defined in... \|
592	+---------------------+------------------------+
593	\| Accept \| Section 6.1 of [Part3] \|
594	\| Accept-Charset \| Section 6.2 of [Part3] \|
595	\| Accept-Encoding \| Section 6.3 of [Part3] \|
596	\| Accept-Language \| Section 6.4 of [Part3] \|
597	\| Authorization \| Section 4.1 of [Part7] \|
598	\| Expect \| Section 10.3 \|
599	\| From \| Section 10.4 \|
600	\| Host \| Section 5.4 of [Part1] \|
601	\| If-Match \| Section 3.1 of [Part4] \|
602	\| If-Modified-Since \| Section 3.3 of [Part4] \|
603	\| If-None-Match \| Section 3.2 of [Part4] \|
604	\| If-Range \| Section 5.3 of [Part5] \|
605	\| If-Unmodified-Since \| Section 3.4 of [Part4] \|
606	\| Max-Forwards \| Section 10.6 \|
607	\| Proxy-Authorization \| Section 4.3 of [Part7] \|
608	\| Range \| Section 5.4 of [Part5] \|
609	\| Referer \| Section 10.7 \|
610	\| TE \| Section 4.3 of [Part1] \|
611
612
613
614
615	Fielding, et al. Expires September 13, 2012 [Page 11]
616
617	Internet-Draft HTTP/1.1, Part 2 March 2012
618
619
620	\| User-Agent \| Section 10.10 \|
621	+---------------------+------------------------+
622
623	3.3. Response Header Fields
624
625	The response header fields allow the server to pass additional
626	information about the response which cannot be placed in the status-
627	line. These header fields give information about the server and
628	about further access to the target resource (Section 5.5 of [Part1]).
629
630	+--------------------+------------------------+
631	\| Header Field Name \| Defined in... \|
632	+--------------------+------------------------+
633	\| Accept-Ranges \| Section 5.1 of [Part5] \|
634	\| Age \| Section 3.1 of [Part6] \|
635	\| Allow \| Section 10.1 \|
636	\| Date \| Section 10.2 \|
637	\| ETag \| Section 2.3 of [Part4] \|
638	\| Location \| Section 10.5 \|
639	\| Proxy-Authenticate \| Section 4.2 of [Part7] \|
640	\| Retry-After \| Section 10.8 \|
641	\| Server \| Section 10.9 \|
642	\| Vary \| Section 3.5 of [Part6] \|
643	\| WWW-Authenticate \| Section 4.4 of [Part7] \|
644	+--------------------+------------------------+
645
646	4. Status Code and Reason Phrase
647
648	The status-code element is a 3-digit integer result code of the
649	attempt to understand and satisfy the request.
650
651	The reason-phrase is intended to give a short textual description of
652	the status-code and is intended for a human user. The client does
653	not need to examine or display the reason-phrase.
654
655	status-code = 3DIGIT
656	reason-phrase = *( HTAB / SP / VCHAR / obs-text )
657
658	HTTP status codes are extensible. HTTP applications are not required
659	to understand the meaning of all registered status codes, though such
660	understanding is obviously desirable. However, applications MUST
661	understand the class of any status code, as indicated by the first
662	digit, and treat any unrecognized response as being equivalent to the
663	x00 status code of that class, with the exception that an
664	unrecognized response MUST NOT be cached. For example, if an
665	unrecognized status code of 431 is received by the client, it can
666	safely assume that there was something wrong with its request and
667	treat the response as if it had received a 400 status code. In such
668
669
670
671	Fielding, et al. Expires September 13, 2012 [Page 12]
672
673	Internet-Draft HTTP/1.1, Part 2 March 2012
674
675
676	cases, user agents SHOULD present to the user the representation
677	enclosed with the response, since that representation is likely to
678	include human-readable information which will explain the unusual
679	status.
680
681	4.1. Overview of Status Codes
682
683	The status codes listed below are defined in Section 7 of this
684	specification, Section 4 of [Part4], Section 3 of [Part5], and
685	Section 3 of [Part7]. The reason phrases listed here are only
686	recommendations -- they can be replaced by local equivalents without
687	affecting the protocol.
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727	Fielding, et al. Expires September 13, 2012 [Page 13]
728
729	Internet-Draft HTTP/1.1, Part 2 March 2012
730
731
732	+-------------+------------------------------+----------------------+
733	\| status-code \| reason-phrase \| Defined in... \|
734	+-------------+------------------------------+----------------------+
735	\| 100 \| Continue \| Section 7.1.1 \|
736	\| 101 \| Switching Protocols \| Section 7.1.2 \|
737	\| 200 \| OK \| Section 7.2.1 \|
738	\| 201 \| Created \| Section 7.2.2 \|
739	\| 202 \| Accepted \| Section 7.2.3 \|
740	\| 203 \| Non-Authoritative \| Section 7.2.4 \|
741	\| \| Information \| \|
742	\| 204 \| No Content \| Section 7.2.5 \|
743	\| 205 \| Reset Content \| Section 7.2.6 \|
744	\| 206 \| Partial Content \| Section 3.1 of \|
745	\| \| \| [Part5] \|
746	\| 300 \| Multiple Choices \| Section 7.3.1 \|
747	\| 301 \| Moved Permanently \| Section 7.3.2 \|
748	\| 302 \| Found \| Section 7.3.3 \|
749	\| 303 \| See Other \| Section 7.3.4 \|
750	\| 304 \| Not Modified \| Section 4.1 of \|
751	\| \| \| [Part4] \|
752	\| 305 \| Use Proxy \| Section 7.3.5 \|
753	\| 307 \| Temporary Redirect \| Section 7.3.7 \|
754	\| 400 \| Bad Request \| Section 7.4.1 \|
755	\| 401 \| Unauthorized \| Section 3.1 of \|
756	\| \| \| [Part7] \|
757	\| 402 \| Payment Required \| Section 7.4.2 \|
758	\| 403 \| Forbidden \| Section 7.4.3 \|
759	\| 404 \| Not Found \| Section 7.4.4 \|
760	\| 405 \| Method Not Allowed \| Section 7.4.5 \|
761	\| 406 \| Not Acceptable \| Section 7.4.6 \|
762	\| 407 \| Proxy Authentication \| Section 3.2 of \|
763	\| \| Required \| [Part7] \|
764	\| 408 \| Request Time-out \| Section 7.4.7 \|
765	\| 409 \| Conflict \| Section 7.4.8 \|
766	\| 410 \| Gone \| Section 7.4.9 \|
767	\| 411 \| Length Required \| Section 7.4.10 \|
768	\| 412 \| Precondition Failed \| Section 4.2 of \|
769	\| \| \| [Part4] \|
770	\| 413 \| Request Representation Too \| Section 7.4.11 \|
771	\| \| Large \| \|
772	\| 414 \| URI Too Long \| Section 7.4.12 \|
773	\| 415 \| Unsupported Media Type \| Section 7.4.13 \|
774	\| 416 \| Requested range not \| Section 3.2 of \|
775	\| \| satisfiable \| [Part5] \|
776	\| 417 \| Expectation Failed \| Section 7.4.14 \|
777	\| 426 \| Upgrade Required \| Section 7.4.15 \|
778	\| 500 \| Internal Server Error \| Section 7.5.1 \|
779	\| 501 \| Not Implemented \| Section 7.5.2 \|
780
781
782
783	Fielding, et al. Expires September 13, 2012 [Page 14]
784
785	Internet-Draft HTTP/1.1, Part 2 March 2012
786
787
788	\| 502 \| Bad Gateway \| Section 7.5.3 \|
789	\| 503 \| Service Unavailable \| Section 7.5.4 \|
790	\| 504 \| Gateway Time-out \| Section 7.5.5 \|
791	\| 505 \| HTTP Version not supported \| Section 7.5.6 \|
792	+-------------+------------------------------+----------------------+
793
794	Note that this list is not exhaustive -- it does not include
795	extension status codes defined in other specifications.
796
797	4.2. Status Code Registry
798
799	The HTTP Status Code Registry defines the name space for the status-
800	code token in the status-line of an HTTP response.
801
802	Values to be added to this name space require IETF Review (see
803	[RFC5226], Section 4.1).
804
805	The registry itself is maintained at
806	<http://www.iana.org/assignments/http-status-codes>.
807
808	4.2.1. Considerations for New Status Codes
809
810	When it is necessary to express new semantics for a HTTP response
811	that aren't specific to a single application or media type, and
812	currently defined status codes are inadequate, a new status code can
813	be registered.
814
815	HTTP status codes are generic; that is, they are potentially
816	applicable to any resource, not just one particular media type,
817	"type" of resource, or application. As such, it is preferred that
818	new HTTP status codes be registered in a document that isn't specific
819	to a single application, so that this is clear.
820
821	Definitions of new HTTP status codes typically explain the request
822	conditions that produce a response containing the status code (e.g.,
823	combinations of request headers and/or method(s)), along with any
824	interactions with response headers (e.g., those that are required,
825	those that modify the semantics of the response).
826
827	New HTTP status codes are required to fall under one of the
828	categories defined in Section 7. To allow existing parsers to
829	properly handle them, new status codes cannot disallow a response
830	body, although they can mandate a zero-length response body. They
831	can require the presence of one or more particular HTTP response
832	header(s).
833
834	Likewise, their definitions can specify that caches are allowed to
835	use heuristics to determine their freshness (see [Part6]; by default,
836
837
838
839	Fielding, et al. Expires September 13, 2012 [Page 15]
840
841	Internet-Draft HTTP/1.1, Part 2 March 2012
842
843
844	it is not allowed), and can define how to determine the resource
845	which they carry a representation for (see Section 5.1; by default,
846	it is anonymous).
847
848	5. Representation
849
850	Request and Response messages MAY transfer a representation if not
851	otherwise restricted by the request method or response status code.
852	A representation consists of metadata (representation header fields)
853	and data (representation body). When a complete or partial
854	representation is enclosed in an HTTP message, it is referred to as
855	the payload of the message. HTTP representations are defined in
856	[Part3].
857
858	A representation body is only present in a message when a message
859	body is present, as described in Section 3.3 of [Part1]. The
860	representation body is obtained from the message body by decoding any
861	Transfer-Encoding that might have been applied to ensure safe and
862	proper transfer of the message.
863
864	5.1. Identifying the Resource Associated with a Representation
865
866	It is sometimes necessary to determine an identifier for the resource
867	associated with a representation.
868
869	An HTTP request representation, when present, is always associated
870	with an anonymous (i.e., unidentified) resource.
871
872	In the common case, an HTTP response is a representation of the
873	target resource (see Section 5.5 of [Part1]). However, this is not
874	always the case. To determine the URI of the resource a response is
875	associated with, the following rules are used (with the first
876	applicable one being selected):
877
878	1. If the response status code is 200 or 203 and the request method
879	was GET, the response payload is a representation of the target
880	resource.
881
882	2. If the response status code is 204, 206, or 304 and the request
883	method was GET or HEAD, the response payload is a partial
884	representation of the target resource.
885
886	3. If the response has a Content-Location header field, and that URI
887	is the same as the effective request URI, the response payload is
888	a representation of the target resource.
889
890	4. If the response has a Content-Location header field, and that URI
891	is not the same as the effective request URI, then the response
892
893
894
895	Fielding, et al. Expires September 13, 2012 [Page 16]
896
897	Internet-Draft HTTP/1.1, Part 2 March 2012
898
899
900	asserts that its payload is a representation of the resource
901	identified by the Content-Location URI. However, such an
902	assertion cannot be trusted unless it can be verified by other
903	means (not defined by HTTP).
904
905	5. Otherwise, the response is a representation of an anonymous
906	(i.e., unidentified) resource.
907
908	[[TODO-req-uri: The comparison function is going to have to be
909	defined somewhere, because we already need to compare URIs for things
910	like cache invalidation.]]
911
912	6. Method Definitions
913
914	The set of common request methods for HTTP/1.1 is defined below.
915	Although this set can be expanded, additional methods cannot be
916	assumed to share the same semantics for separately extended clients
917	and servers.
918
919	6.1. Safe and Idempotent Methods
920
921	6.1.1. Safe Methods
922
923	Implementors need to be aware that the software represents the user
924	in their interactions over the Internet, and need to allow the user
925	to be aware of any actions they take which might have an unexpected
926	significance to themselves or others.
927
928	In particular, the convention has been established that the GET,
929	HEAD, OPTIONS, and TRACE request methods SHOULD NOT have the
930	significance of taking an action other than retrieval. These request
931	methods ought to be considered "safe". This allows user agents to
932	represent other methods, such as POST, PUT and DELETE, in a special
933	way, so that the user is made aware of the fact that a possibly
934	unsafe action is being requested.
935
936	Naturally, it is not possible to ensure that the server does not
937	generate side-effects as a result of performing a GET request; in
938	fact, some dynamic resources consider that a feature. The important
939	distinction here is that the user did not request the side-effects,
940	so therefore cannot be held accountable for them.
941
942	6.1.2. Idempotent Methods
943
944	Request methods can also have the property of "idempotence" in that,
945	aside from error or expiration issues, the intended effect of
946	multiple identical requests is the same as for a single request.
947	PUT, DELETE, and all safe request methods are idempotent. It is
948
949
950
951	Fielding, et al. Expires September 13, 2012 [Page 17]
952
953	Internet-Draft HTTP/1.1, Part 2 March 2012
954
955
956	important to note that idempotence refers only to changes requested
957	by the client: a server is free to change its state due to multiple
958	requests for the purpose of tracking those requests, versioning of
959	results, etc.
960
961	6.2. OPTIONS
962
963	The OPTIONS method requests information about the communication
964	options available on the request/response chain identified by the
965	effective request URI. This method allows a client to determine the
966	options and/or requirements associated with a resource, or the
967	capabilities of a server, without implying a resource action or
968	initiating a resource retrieval.
969
970	Responses to the OPTIONS method are not cacheable.
971
972	If the OPTIONS request includes a message body (as indicated by the
973	presence of Content-Length or Transfer-Encoding), then the media type
974	MUST be indicated by a Content-Type field. Although this
975	specification does not define any use for such a body, future
976	extensions to HTTP might use the OPTIONS body to make more detailed
977	queries on the server.
978
979	If the request-target (Section 5.3 of [Part1]) is an asterisk ("*"),
980	the OPTIONS request is intended to apply to the server in general
981	rather than to a specific resource. Since a server's communication
982	options typically depend on the resource, the "*" request is only
983	useful as a "ping" or "no-op" type of method; it does nothing beyond
984	allowing the client to test the capabilities of the server. For
985	example, this can be used to test a proxy for HTTP/1.1 conformance
986	(or lack thereof).
987
988	If the request-target is not an asterisk, the OPTIONS request applies
989	only to the options that are available when communicating with that
990	resource.
991
992	A 200 response SHOULD include any header fields that indicate
993	optional features implemented by the server and applicable to that
994	resource (e.g., Allow), possibly including extensions not defined by
995	this specification. The response body, if any, SHOULD also include
996	information about the communication options. The format for such a
997	body is not defined by this specification, but might be defined by
998	future extensions to HTTP. Content negotiation MAY be used to select
999	the appropriate response format. If no response body is included,
1000	the response MUST include a Content-Length field with a field-value
1001	of "0".
1002
1003	The Max-Forwards header field MAY be used to target a specific proxy
1004
1005
1006
1007	Fielding, et al. Expires September 13, 2012 [Page 18]
1008
1009	Internet-Draft HTTP/1.1, Part 2 March 2012
1010
1011
1012	in the request chain (see Section 10.6). If no Max-Forwards field is
1013	present in the request, then the forwarded request MUST NOT include a
1014	Max-Forwards field.
1015
1016	6.3. GET
1017
1018	The GET method requests transfer of a current representation of the
1019	target resource.
1020
1021	If the target resource is a data-producing process, it is the
1022	produced data which shall be returned as the representation in the
1023	response and not the source text of the process, unless that text
1024	happens to be the output of the process.
1025
1026	The semantics of the GET method change to a "conditional GET" if the
1027	request message includes an If-Modified-Since, If-Unmodified-Since,
1028	If-Match, If-None-Match, or If-Range header field. A conditional GET
1029	requests that the representation be transferred only under the
1030	circumstances described by the conditional header field(s). The
1031	conditional GET request is intended to reduce unnecessary network
1032	usage by allowing cached representations to be refreshed without
1033	requiring multiple requests or transferring data already held by the
1034	client.
1035
1036	The semantics of the GET method change to a "partial GET" if the
1037	request message includes a Range header field. A partial GET
1038	requests that only part of the representation be transferred, as
1039	described in Section 5.4 of [Part5]. The partial GET request is
1040	intended to reduce unnecessary network usage by allowing partially-
1041	retrieved representations to be completed without transferring data
1042	already held by the client.
1043
1044	Bodies on GET requests have no defined semantics. Note that sending
1045	a body on a GET request might cause some existing implementations to
1046	reject the request.
1047
1048	The response to a GET request is cacheable and MAY be used to satisfy
1049	subsequent GET and HEAD requests (see [Part6]).
1050
1051	See Section 12.2 for security considerations when used for forms.
1052
1053	6.4. HEAD
1054
1055	The HEAD method is identical to GET except that the server MUST NOT
1056	return a message body in the response. The metadata contained in the
1057	HTTP header fields in response to a HEAD request SHOULD be identical
1058	to the information sent in response to a GET request. This method
1059	can be used for obtaining metadata about the representation implied
1060
1061
1062
1063	Fielding, et al. Expires September 13, 2012 [Page 19]
1064
1065	Internet-Draft HTTP/1.1, Part 2 March 2012
1066
1067
1068	by the request without transferring the representation body. This
1069	method is often used for testing hypertext links for validity,
1070	accessibility, and recent modification.
1071
1072	The response to a HEAD request is cacheable and MAY be used to
1073	satisfy a subsequent HEAD request. It also has potential side
1074	effects on previously stored responses to GET; see Section 2.5 of
1075	[Part6].
1076
1077	Bodies on HEAD requests have no defined semantics. Note that sending
1078	a body on a HEAD request might cause some existing implementations to
1079	reject the request.
1080
1081	6.5. POST
1082
1083	The POST method requests that the origin server accept the
1084	representation enclosed in the request as data to be processed by the
1085	target resource. POST is designed to allow a uniform method to cover
1086	the following functions:
1087
1088	o Annotation of existing resources;
1089
1090	o Posting a message to a bulletin board, newsgroup, mailing list, or
1091	similar group of articles;
1092
1093	o Providing a block of data, such as the result of submitting a
1094	form, to a data-handling process;
1095
1096	o Extending a database through an append operation.
1097
1098	The actual function performed by the POST method is determined by the
1099	server and is usually dependent on the effective request URI.
1100
1101	The action performed by the POST method might not result in a
1102	resource that can be identified by a URI. In this case, either 200
1103	(OK) or 204 (No Content) is the appropriate response status code,
1104	depending on whether or not the response includes a representation
1105	that describes the result.
1106
1107	If a resource has been created on the origin server, the response
1108	SHOULD be 201 (Created) and contain a representation which describes
1109	the status of the request and refers to the new resource, and a
1110	Location header field (see Section 10.5).
1111
1112	Responses to POST requests are only cacheable when they include
1113	explicit freshness information (see Section 2.3.1 of [Part6]). A
1114	cached POST response with a Content-Location header field (see
1115	Section 6.7 of [Part3]) whose value is the effective Request URI MAY
1116
1117
1118
1119	Fielding, et al. Expires September 13, 2012 [Page 20]
1120
1121	Internet-Draft HTTP/1.1, Part 2 March 2012
1122
1123
1124	be used to satisfy subsequent GET and HEAD requests.
1125
1126	Note that POST caching is not widely implemented. However, the 303
1127	(See Other) response can be used to direct the user agent to retrieve
1128	a cacheable resource.
1129
1130	6.6. PUT
1131
1132	The PUT method requests that the state of the target resource be
1133	created or replaced with the state defined by the representation
1134	enclosed in the request message payload. A successful PUT of a given
1135	representation would suggest that a subsequent GET on that same
1136	target resource will result in an equivalent representation being
1137	returned in a 200 (OK) response. However, there is no guarantee that
1138	such a state change will be observable, since the target resource
1139	might be acted upon by other user agents in parallel, or might be
1140	subject to dynamic processing by the origin server, before any
1141	subsequent GET is received. A successful response only implies that
1142	the user agent's intent was achieved at the time of its processing by
1143	the origin server.
1144
1145	If the target resource does not have a current representation and the
1146	PUT successfully creates one, then the origin server MUST inform the
1147	user agent by sending a 201 (Created) response. If the target
1148	resource does have a current representation and that representation
1149	is successfully modified in accordance with the state of the enclosed
1150	representation, then either a 200 (OK) or 204 (No Content) response
1151	SHOULD be sent to indicate successful completion of the request.
1152
1153	Unrecognized header fields SHOULD be ignored (i.e., not saved as part
1154	of the resource state).
1155
1156	An origin server SHOULD verify that the PUT representation is
1157	consistent with any constraints which the server has for the target
1158	resource that cannot or will not be changed by the PUT. This is
1159	particularly important when the origin server uses internal
1160	configuration information related to the URI in order to set the
1161	values for representation metadata on GET responses. When a PUT
1162	representation is inconsistent with the target resource, the origin
1163	server SHOULD either make them consistent, by transforming the
1164	representation or changing the resource configuration, or respond
1165	with an appropriate error message containing sufficient information
1166	to explain why the representation is unsuitable. The 409 (Conflict)
1167	or 415 (Unsupported Media Type) status codes are suggested, with the
1168	latter being specific to constraints on Content-Type values.
1169
1170	For example, if the target resource is configured to always have a
1171	Content-Type of "text/html" and the representation being PUT has a
1172
1173
1174
1175	Fielding, et al. Expires September 13, 2012 [Page 21]
1176
1177	Internet-Draft HTTP/1.1, Part 2 March 2012
1178
1179
1180	Content-Type of "image/jpeg", then the origin server SHOULD do one
1181	of: (a) reconfigure the target resource to reflect the new media
1182	type; (b) transform the PUT representation to a format consistent
1183	with that of the resource before saving it as the new resource state;
1184	or, (c) reject the request with a 415 response indicating that the
1185	target resource is limited to "text/html", perhaps including a link
1186	to a different resource that would be a suitable target for the new
1187	representation.
1188
1189	HTTP does not define exactly how a PUT method affects the state of an
1190	origin server beyond what can be expressed by the intent of the user
1191	agent request and the semantics of the origin server response. It
1192	does not define what a resource might be, in any sense of that word,
1193	beyond the interface provided via HTTP. It does not define how
1194	resource state is "stored", nor how such storage might change as a
1195	result of a change in resource state, nor how the origin server
1196	translates resource state into representations. Generally speaking,
1197	all implementation details behind the resource interface are
1198	intentionally hidden by the server.
1199
1200	The fundamental difference between the POST and PUT methods is
1201	highlighted by the different intent for the target resource. The
1202	target resource in a POST request is intended to handle the enclosed
1203	representation as a data-accepting process, such as for a gateway to
1204	some other protocol or a document that accepts annotations. In
1205	contrast, the target resource in a PUT request is intended to take
1206	the enclosed representation as a new or replacement value. Hence,
1207	the intent of PUT is idempotent and visible to intermediaries, even
1208	though the exact effect is only known by the origin server.
1209
1210	Proper interpretation of a PUT request presumes that the user agent
1211	knows what target resource is desired. A service that is intended to
1212	select a proper URI on behalf of the client, after receiving a state-
1213	changing request, SHOULD be implemented using the POST method rather
1214	than PUT. If the origin server will not make the requested PUT state
1215	change to the target resource and instead wishes to have it applied
1216	to a different resource, such as when the resource has been moved to
1217	a different URI, then the origin server MUST send a 301 (Moved
1218	Permanently) response; the user agent MAY then make its own decision
1219	regarding whether or not to redirect the request.
1220
1221	A PUT request applied to the target resource MAY have side-effects on
1222	other resources. For example, an article might have a URI for
1223	identifying "the current version" (a resource) which is separate from
1224	the URIs identifying each particular version (different resources
1225	that at one point shared the same state as the current version
1226	resource). A successful PUT request on "the current version" URI
1227	might therefore create a new version resource in addition to changing
1228
1229
1230
1231	Fielding, et al. Expires September 13, 2012 [Page 22]
1232
1233	Internet-Draft HTTP/1.1, Part 2 March 2012
1234
1235
1236	the state of the target resource, and might also cause links to be
1237	added between the related resources.
1238
1239	An origin server SHOULD reject any PUT request that contains a
1240	Content-Range header field, since it might be misinterpreted as
1241	partial content (or might be partial content that is being mistakenly
1242	PUT as a full representation). Partial content updates are possible
1243	by targeting a separately identified resource with state that
1244	overlaps a portion of the larger resource, or by using a different
1245	method that has been specifically defined for partial updates (for
1246	example, the PATCH method defined in [RFC5789]).
1247
1248	Responses to the PUT method are not cacheable. If a PUT request
1249	passes through a cache that has one or more stored responses for the
1250	effective request URI, those stored responses will be invalidated
1251	(see Section 2.6 of [Part6]).
1252
1253	6.7. DELETE
1254
1255	The DELETE method requests that the origin server delete the target
1256	resource. This method MAY be overridden by human intervention (or
1257	other means) on the origin server. The client cannot be guaranteed
1258	that the operation has been carried out, even if the status code
1259	returned from the origin server indicates that the action has been
1260	completed successfully. However, the server SHOULD NOT indicate
1261	success unless, at the time the response is given, it intends to
1262	delete the resource or move it to an inaccessible location.
1263
1264	A successful response SHOULD be 200 (OK) if the response includes an
1265	representation describing the status, 202 (Accepted) if the action
1266	has not yet been enacted, or 204 (No Content) if the action has been
1267	enacted but the response does not include a representation.
1268
1269	Bodies on DELETE requests have no defined semantics. Note that
1270	sending a body on a DELETE request might cause some existing
1271	implementations to reject the request.
1272
1273	Responses to the DELETE method are not cacheable. If a DELETE
1274	request passes through a cache that has one or more stored responses
1275	for the effective request URI, those stored responses will be
1276	invalidated (see Section 2.6 of [Part6]).
1277
1278	6.8. TRACE
1279
1280	The TRACE method requests a remote, application-layer loop-back of
1281	the request message. The final recipient of the request SHOULD
1282	reflect the message received back to the client as the message body
1283	of a 200 (OK) response. The final recipient is either the origin
1284
1285
1286
1287	Fielding, et al. Expires September 13, 2012 [Page 23]
1288
1289	Internet-Draft HTTP/1.1, Part 2 March 2012
1290
1291
1292	server or the first proxy to receive a Max-Forwards value of zero (0)
1293	in the request (see Section 10.6). A TRACE request MUST NOT include
1294	a message body.
1295
1296	TRACE allows the client to see what is being received at the other
1297	end of the request chain and use that data for testing or diagnostic
1298	information. The value of the Via header field (Section 6.2 of
1299	[Part1]) is of particular interest, since it acts as a trace of the
1300	request chain. Use of the Max-Forwards header field allows the
1301	client to limit the length of the request chain, which is useful for
1302	testing a chain of proxies forwarding messages in an infinite loop.
1303
1304	If the request is valid, the response SHOULD have a Content-Type of
1305	"message/http" (see Section 7.3.1 of [Part1]) and contain a message
1306	body that encloses a copy of the entire request message. Responses
1307	to the TRACE method are not cacheable.
1308
1309	6.9. CONNECT
1310
1311	The CONNECT method requests that the proxy establish a tunnel to the
1312	request-target and, if successful, thereafter restrict its behavior
1313	to blind forwarding of packets until the connection is closed.
1314
1315	When using CONNECT, the request-target MUST use the authority form
1316	(Section 5.3 of [Part1]); i.e., the request-target consists of only
1317	the host name and port number of the tunnel destination, separated by
1318	a colon. For example,
1319
1320	CONNECT server.example.com:80 HTTP/1.1
1321	Host: server.example.com:80
1322
1323
1324	Any successful (2xx) response to a CONNECT request indicates that the
1325	proxy has established a connection to the requested host and port,
1326	and has switched to tunneling the current connection to that server
1327	connection. The tunneled data from the server begins immediately
1328	after the blank line that concludes the successful response's header
1329	block. A server SHOULD NOT send any Transfer-Encoding or Content-
1330	Length header fields in a successful response. A client MUST ignore
1331	any Content-Length or Transfer-Encoding header fields received in a
1332	successful response.
1333
1334	Any response other than a successful response indicates that the
1335	tunnel has not yet been formed and that the connection remains
1336	governed by HTTP.
1337
1338	Proxy authentication might be used to establish the authority to
1339	create a tunnel:
1340
1341
1342
1343	Fielding, et al. Expires September 13, 2012 [Page 24]
1344
1345	Internet-Draft HTTP/1.1, Part 2 March 2012
1346
1347
1348	CONNECT server.example.com:80 HTTP/1.1
1349	Host: server.example.com:80
1350	Proxy-Authorization: basic aGVsbG86d29ybGQ=
1351
1352
1353	A message body on a CONNECT request has no defined semantics.
1354	Sending a body on a CONNECT request might cause existing
1355	implementations to reject the request.
1356
1357	Similar to a pipelined HTTP/1.1 request, data to be tunneled from
1358	client to server MAY be sent immediately after the request (before a
1359	response is received). The usual caveats also apply: data may be
1360	discarded if the eventual response is negative, and the connection
1361	may be reset with no response if more than one TCP segment is
1362	outstanding.
1363
1364	It may be the case that the proxy itself can only reach the requested
1365	origin server through another proxy. In this case, the first proxy
1366	SHOULD make a CONNECT request of that next proxy, requesting a tunnel
1367	to the authority. A proxy MUST NOT respond with any 2xx status code
1368	unless it has either a direct or tunnel connection established to the
1369	authority.
1370
1371	If at any point either one of the peers gets disconnected, any
1372	outstanding data that came from that peer will be passed to the other
1373	one, and after that also the other connection will be terminated by
1374	the proxy. If there is outstanding data to that peer undelivered,
1375	that data will be discarded.
1376
1377	An origin server which receives a CONNECT request for itself MAY
1378	respond with a 2xx status code to indicate that a connection is
1379	established. However, most origin servers do not implement CONNECT.
1380
1381	7. Status Code Definitions
1382
1383	The first digit of the status-code defines the class of response.
1384	The last two digits do not have any categorization role. There are 5
1385	values for the first digit:
1386
1387	o 1xx: Informational - Request received, continuing process
1388
1389	o 2xx: Success - The action was successfully received, understood,
1390	and accepted
1391
1392	o 3xx: Redirection - Further action must be taken in order to
1393	complete the request
1394
1395
1396
1397
1398
1399	Fielding, et al. Expires September 13, 2012 [Page 25]
1400
1401	Internet-Draft HTTP/1.1, Part 2 March 2012
1402
1403
1404	o 4xx: Client Error - The request contains bad syntax or cannot be
1405	fulfilled
1406
1407	o 5xx: Server Error - The server failed to fulfill an apparently
1408	valid request
1409
1410	Each status-code is described below, including any metadata required
1411	in the response.
1412
1413	For most status codes the response can carry a payload, in which case
1414	a Content-Type header field indicates the payload's media type
1415	(Section 6.8 of [Part3]).
1416
1417	7.1. Informational 1xx
1418
1419	This class of status code indicates a provisional response,
1420	consisting only of the status-line and optional header fields, and is
1421	terminated by an empty line. There are no required header fields for
1422	this class of status code. Since HTTP/1.0 did not define any 1xx
1423	status codes, servers MUST NOT send a 1xx response to an HTTP/1.0
1424	client except under experimental conditions.
1425
1426	A client MUST be prepared to accept one or more 1xx status responses
1427	prior to a regular response, even if the client does not expect a 100
1428	(Continue) status message. Unexpected 1xx status responses MAY be
1429	ignored by a user agent.
1430
1431	Proxies MUST forward 1xx responses, unless the connection between the
1432	proxy and its client has been closed, or unless the proxy itself
1433	requested the generation of the 1xx response. (For example, if a
1434	proxy adds a "Expect: 100-continue" field when it forwards a request,
1435	then it need not forward the corresponding 100 (Continue)
1436	response(s).)
1437
1438	7.1.1. 100 Continue
1439
1440	The client SHOULD continue with its request. This interim response
1441	is used to inform the client that the initial part of the request has
1442	been received and has not yet been rejected by the server. The
1443	client SHOULD continue by sending the remainder of the request or, if
1444	the request has already been completed, ignore this response. The
1445	server MUST send a final response after the request has been
1446	completed. See Section 6.4.3 of [Part1] for detailed discussion of
1447	the use and handling of this status code.
1448
1449
1450
1451
1452
1453
1454
1455	Fielding, et al. Expires September 13, 2012 [Page 26]
1456
1457	Internet-Draft HTTP/1.1, Part 2 March 2012
1458
1459
1460	7.1.2. 101 Switching Protocols
1461
1462	The server understands and is willing to comply with the client's
1463	request, via the Upgrade message header field (Section 6.5 of
1464	[Part1]), for a change in the application protocol being used on this
1465	connection. The server will switch protocols to those defined by the
1466	response's Upgrade header field immediately after the empty line
1467	which terminates the 101 response.
1468
1469	The protocol SHOULD be switched only when it is advantageous to do
1470	so. For example, switching to a newer version of HTTP is
1471	advantageous over older versions, and switching to a real-time,
1472	synchronous protocol might be advantageous when delivering resources
1473	that use such features.
1474
1475	7.2. Successful 2xx
1476
1477	This class of status code indicates that the client's request was
1478	successfully received, understood, and accepted.
1479
1480	7.2.1. 200 OK
1481
1482	The request has succeeded. The payload returned with the response is
1483	dependent on the method used in the request, for example:
1484
1485	GET a representation of the target resource is sent in the response;
1486
1487	HEAD the same representation as GET, except without the message
1488	body;
1489
1490	POST a representation describing or containing the result of the
1491	action;
1492
1493	TRACE a representation containing the request message as received by
1494	the end server.
1495
1496	Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to
1497	determine freshness for 200 responses.
1498
1499	7.2.2. 201 Created
1500
1501	The request has been fulfilled and has resulted in a new resource
1502	being created.
1503
1504	The newly created resource is typically linked to from the response
1505	payload, with the most relevant URI also being carried in the
1506	Location header field. If the newly created resource's URI is the
1507	same as the Effective Request URI, this information can be omitted
1508
1509
1510
1511	Fielding, et al. Expires September 13, 2012 [Page 27]
1512
1513	Internet-Draft HTTP/1.1, Part 2 March 2012
1514
1515
1516	(e.g., in the case of a response to a PUT request).
1517
1518	The origin server MUST create the resource before returning the 201
1519	status code. If the action cannot be carried out immediately, the
1520	server SHOULD respond with 202 (Accepted) response instead.
1521
1522	A 201 response MAY contain an ETag response header field indicating
1523	the current value of the entity-tag for the representation of the
1524	resource just created (see Section 2.3 of [Part4]).
1525
1526	7.2.3. 202 Accepted
1527
1528	The request has been accepted for processing, but the processing has
1529	not been completed. The request might or might not eventually be
1530	acted upon, as it might be disallowed when processing actually takes
1531	place. There is no facility for re-sending a status code from an
1532	asynchronous operation such as this.
1533
1534	The 202 response is intentionally non-committal. Its purpose is to
1535	allow a server to accept a request for some other process (perhaps a
1536	batch-oriented process that is only run once per day) without
1537	requiring that the user agent's connection to the server persist
1538	until the process is completed. The representation returned with
1539	this response SHOULD include an indication of the request's current
1540	status and either a pointer to a status monitor or some estimate of
1541	when the user can expect the request to be fulfilled.
1542
1543	7.2.4. 203 Non-Authoritative Information
1544
1545	The representation in the response has been transformed or otherwise
1546	modified by a transforming proxy (Section 2.3 of [Part1]). Note that
1547	the behavior of transforming intermediaries is controlled by the no-
1548	transform Cache-Control directive (Section 3.2 of [Part6]).
1549
1550	This status code is only appropriate when the response status code
1551	would have been 200 (OK) otherwise. When the status code before
1552	transformation would have been different, the 214 Transformation
1553	Applied warn-code (Section 3.6 of [Part6]) is appropriate.
1554
1555	Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to
1556	determine freshness for 203 responses.
1557
1558	7.2.5. 204 No Content
1559
1560	The 204 (No Content) status code indicates that the server has
1561	successfully fulfilled the request and that there is no additional
1562	content to return in the response payload body. Metadata in the
1563	response header fields refer to the target resource and its current
1564
1565
1566
1567	Fielding, et al. Expires September 13, 2012 [Page 28]
1568
1569	Internet-Draft HTTP/1.1, Part 2 March 2012
1570
1571
1572	representation after the requested action.
1573
1574	For example, if a 204 status code is received in response to a PUT
1575	request and the response contains an ETag header field, then the PUT
1576	was successful and the ETag field-value contains the entity-tag for
1577	the new representation of that target resource.
1578
1579	The 204 response allows a server to indicate that the action has been
1580	successfully applied to the target resource while implying that the
1581	user agent SHOULD NOT traverse away from its current "document view"
1582	(if any). The server assumes that the user agent will provide some
1583	indication of the success to its user, in accord with its own
1584	interface, and apply any new or updated metadata in the response to
1585	the active representation.
1586
1587	For example, a 204 status code is commonly used with document editing
1588	interfaces corresponding to a "save" action, such that the document
1589	being saved remains available to the user for editing. It is also
1590	frequently used with interfaces that expect automated data transfers
1591	to be prevalent, such as within distributed version control systems.
1592
1593	The 204 response MUST NOT include a message body, and thus is always
1594	terminated by the first empty line after the header fields.
1595
1596	7.2.6. 205 Reset Content
1597
1598	The server has fulfilled the request and the user agent SHOULD reset
1599	the document view which caused the request to be sent. This response
1600	is primarily intended to allow input for actions to take place via
1601	user input, followed by a clearing of the form in which the input is
1602	given so that the user can easily initiate another input action.
1603
1604	The message body included with the response MUST be empty. Note that
1605	receivers still need to parse the response according to the algorithm
1606	defined in Section 3.3 of [Part1].
1607
1608	7.3. Redirection 3xx
1609
1610	This class of status code indicates that further action needs to be
1611	taken by the user agent in order to fulfill the request. If the
1612	required action involves a subsequent HTTP request, it MAY be carried
1613	out by the user agent without interaction with the user if and only
1614	if the method used in the second request is known to be "safe", as
1615	defined in Section 6.1.1.
1616
1617	There are several types of redirects:
1618
1619
1620
1621
1622
1623	Fielding, et al. Expires September 13, 2012 [Page 29]
1624
1625	Internet-Draft HTTP/1.1, Part 2 March 2012
1626
1627
1628	1. Redirects of the request to another URI, either temporarily or
1629	permanently. The new URI is specified in the Location header
1630	field. In this specification, the status codes 301 (Moved
1631	Permanently), 302 (Found), and 307 (Temporary Redirect) fall
1632	under this category.
1633
1634	2. Redirection to a new location that represents an indirect
1635	response to the request, such as the result of a POST operation
1636	to be retrieved with a subsequent GET request. This is status
1637	code 303 (See Other).
1638
1639	3. Redirection offering a choice of matching resources for use by
1640	agent-driven content negotiation (Section 5.2 of [Part3]). This
1641	is status code 300 (Multiple Choices).
1642
1643	4. Other kinds of redirection, such as to a cached result (status
1644	code 304 (Not Modified), see Section 4.1 of [Part4]).
1645
1646	Note: In HTTP/1.0, only the status codes 301 (Moved Permanently)
1647	and 302 (Found) were defined for the first type of redirect, and
1648	the second type did not exist at all ([RFC1945], Section 9.3).
1649	However it turned out that web forms using POST expected redirects
1650	to change the operation for the subsequent request to retrieval
1651	(GET). To address this use case, HTTP/1.1 introduced the second
1652	type of redirect with the status code 303 (See Other) ([RFC2068],
1653	Section 10.3.4). As user agents did not change their behavior to
1654	maintain backwards compatibility, the first revision of HTTP/1.1
1655	added yet another status code, 307 (Temporary Redirect), for which
1656	the backwards compatibility problems did not apply ([RFC2616],
1657	Section 10.3.8). Over 10 years later, most user agents still do
1658	method rewriting for status codes 301 and 302, therefore this
1659	specification makes that behavior conformant in case the original
1660	request was POST.
1661
1662	A Location header field on a 3xx response indicates that a client MAY
1663	automatically redirect to the URI provided; see Section 10.5.
1664
1665	Note that for methods not known to be "safe", as defined in
1666	Section 6.1.1, automatic redirection needs to done with care, since
1667	the redirect might change the conditions under which the request was
1668	issued.
1669
1670	Clients SHOULD detect and intervene in cyclical redirections (i.e.,
1671	"infinite" redirection loops).
1672
1673	Note: An earlier version of this specification recommended a
1674	maximum of five redirections ([RFC2068], Section 10.3). Content
1675	developers need to be aware that some clients might implement such
1676
1677
1678
1679	Fielding, et al. Expires September 13, 2012 [Page 30]
1680
1681	Internet-Draft HTTP/1.1, Part 2 March 2012
1682
1683
1684	a fixed limitation.
1685
1686	7.3.1. 300 Multiple Choices
1687
1688	The target resource has more than one representation, each with its
1689	own specific location, and agent-driven negotiation information
1690	(Section 5 of [Part3]) is being provided so that the user (or user
1691	agent) can select a preferred representation by redirecting its
1692	request to that location.
1693
1694	Unless it was a HEAD request, the response SHOULD include a
1695	representation containing a list of representation metadata and
1696	location(s) from which the user or user agent can choose the one most
1697	appropriate. Depending upon the format and the capabilities of the
1698	user agent, selection of the most appropriate choice MAY be performed
1699	automatically. However, this specification does not define any
1700	standard for such automatic selection.
1701
1702	If the server has a preferred choice of representation, it SHOULD
1703	include the specific URI for that representation in the Location
1704	field; user agents MAY use the Location field value for automatic
1705	redirection.
1706
1707	Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to
1708	determine freshness for 300 responses.
1709
1710	7.3.2. 301 Moved Permanently
1711
1712	The target resource has been assigned a new permanent URI and any
1713	future references to this resource SHOULD use one of the returned
1714	URIs. Clients with link editing capabilities ought to automatically
1715	re-link references to the effective request URI to one or more of the
1716	new references returned by the server, where possible.
1717
1718	Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to
1719	determine freshness for 301 responses.
1720
1721	The new permanent URI SHOULD be given by the Location field in the
1722	response. A response payload can contain a short hypertext note with
1723	a hyperlink to the new URI(s).
1724
1725	Note: For historic reasons, user agents MAY change the request
1726	method from POST to GET for the subsequent request. If this
1727	behavior is undesired, status code 307 (Temporary Redirect) can be
1728	used instead.
1729
1730
1731
1732
1733
1734
1735	Fielding, et al. Expires September 13, 2012 [Page 31]
1736
1737	Internet-Draft HTTP/1.1, Part 2 March 2012
1738
1739
1740	7.3.3. 302 Found
1741
1742	The target resource resides temporarily under a different URI. Since
1743	the redirection might be altered on occasion, the client SHOULD
1744	continue to use the effective request URI for future requests.
1745
1746	The temporary URI SHOULD be given by the Location field in the
1747	response. A response payload can contain a short hypertext note with
1748	a hyperlink to the new URI(s).
1749
1750	Note: For historic reasons, user agents MAY change the request
1751	method from POST to GET for the subsequent request. If this
1752	behavior is undesired, status code 307 (Temporary Redirect) can be
1753	used instead.
1754
1755	7.3.4. 303 See Other
1756
1757	The 303 status code indicates that the server is redirecting the user
1758	agent to a different resource, as indicated by a URI in the Location
1759	header field, that is intended to provide an indirect response to the
1760	original request. In order to satisfy the original request, a user
1761	agent SHOULD perform a retrieval request using the Location URI (a
1762	GET or HEAD request if using HTTP), which may itself be redirected
1763	further, and present the eventual result as an answer to the original
1764	request. Note that the new URI in the Location header field is not
1765	considered equivalent to the effective request URI.
1766
1767	This status code is generally applicable to any HTTP method. It is
1768	primarily used to allow the output of a POST action to redirect the
1769	user agent to a selected resource, since doing so provides the
1770	information corresponding to the POST response in a form that can be
1771	separately identified, bookmarked, and cached independent of the
1772	original request.
1773
1774	A 303 response to a GET request indicates that the requested resource
1775	does not have a representation of its own that can be transferred by
1776	the server over HTTP. The Location URI indicates a resource that is
1777	descriptive of the target resource, such that the follow-on
1778	representation might be useful to recipients without implying that it
1779	adequately represents the target resource. Note that answers to the
1780	questions of what can be represented, what representations are
1781	adequate, and what might be a useful description are outside the
1782	scope of HTTP and thus entirely determined by the URI owner(s).
1783
1784	Except for responses to a HEAD request, the representation of a 303
1785	response SHOULD contain a short hypertext note with a hyperlink to
1786	the Location URI.
1787
1788
1789
1790
1791	Fielding, et al. Expires September 13, 2012 [Page 32]
1792
1793	Internet-Draft HTTP/1.1, Part 2 March 2012
1794
1795
1796	7.3.5. 305 Use Proxy
1797
1798	The 305 status code was defined in a previous version of this
1799	specification (see Appendix A), and is now deprecated.
1800
1801	7.3.6. 306 (Unused)
1802
1803	The 306 status code was used in a previous version of the
1804	specification, is no longer used, and the code is reserved.
1805
1806	7.3.7. 307 Temporary Redirect
1807
1808	The target resource resides temporarily under a different URI. Since
1809	the redirection can change over time, the client SHOULD continue to
1810	use the effective request URI for future requests.
1811
1812	The temporary URI SHOULD be given by the Location field in the
1813	response. A response payload can contain a short hypertext note with
1814	a hyperlink to the new URI(s).
1815
1816	Note: This status code is similar to 302 Found, except that it
1817	does not allow rewriting the request method from POST to GET.
1818	This specification defines no equivalent counterpart for 301 Moved
1819	Permanently.
1820
1821	7.4. Client Error 4xx
1822
1823	The 4xx class of status code is intended for cases in which the
1824	client seems to have erred. Except when responding to a HEAD
1825	request, the server SHOULD include a representation containing an
1826	explanation of the error situation, and whether it is a temporary or
1827	permanent condition. These status codes are applicable to any
1828	request method. User agents SHOULD display any included
1829	representation to the user.
1830
1831	7.4.1. 400 Bad Request
1832
1833	The server cannot or will not process the request, due to a client
1834	error (e.g., malformed syntax).
1835
1836	7.4.2. 402 Payment Required
1837
1838	This code is reserved for future use.
1839
1840	7.4.3. 403 Forbidden
1841
1842	The server understood the request, but refuses to authorize it.
1843	Providing different user authentication credentials might be
1844
1845
1846
1847	Fielding, et al. Expires September 13, 2012 [Page 33]
1848
1849	Internet-Draft HTTP/1.1, Part 2 March 2012
1850
1851
1852	successful, but any credentials that were provided in the request are
1853	insufficient. The request SHOULD NOT be repeated with the same
1854	credentials.
1855
1856	If the request method was not HEAD and the server wishes to make
1857	public why the request has not been fulfilled, it SHOULD describe the
1858	reason for the refusal in the representation. If the server does not
1859	wish to make this information available to the client, the status
1860	code 404 (Not Found) MAY be used instead.
1861
1862	7.4.4. 404 Not Found
1863
1864	The server has not found anything matching the effective request URI.
1865	No indication is given of whether the condition is temporary or
1866	permanent. The 410 (Gone) status code SHOULD be used if the server
1867	knows, through some internally configurable mechanism, that an old
1868	resource is permanently unavailable and has no forwarding address.
1869	This status code is commonly used when the server does not wish to
1870	reveal exactly why the request has been refused, or when no other
1871	response is applicable.
1872
1873	7.4.5. 405 Method Not Allowed
1874
1875	The method specified in the request-line is not allowed for the
1876	target resource. The response MUST include an Allow header field
1877	containing a list of valid methods for the requested resource.
1878
1879	7.4.6. 406 Not Acceptable
1880
1881	The resource identified by the request is only capable of generating
1882	response representations which have content characteristics not
1883	acceptable according to the Accept and Accept-* header fields sent in
1884	the request (see Section 6 of [Part3]).
1885
1886	Unless it was a HEAD request, the response SHOULD include a
1887	representation containing a list of available representation
1888	characteristics and location(s) from which the user or user agent can
1889	choose the one most appropriate. Depending upon the format and the
1890	capabilities of the user agent, selection of the most appropriate
1891	choice MAY be performed automatically. However, this specification
1892	does not define any standard for such automatic selection.
1893
1894	Note: HTTP/1.1 servers are allowed to return responses which are
1895	not acceptable according to the accept header fields sent in the
1896	request. In some cases, this might even be preferable to sending
1897	a 406 response. User agents are encouraged to inspect the header
1898	fields of an incoming response to determine if it is acceptable.
1899
1900
1901
1902
1903	Fielding, et al. Expires September 13, 2012 [Page 34]
1904
1905	Internet-Draft HTTP/1.1, Part 2 March 2012
1906
1907
1908	If the response could be unacceptable, a user agent SHOULD
1909	temporarily stop receipt of more data and query the user for a
1910	decision on further actions.
1911
1912	7.4.7. 408 Request Timeout
1913
1914	The client did not produce a request within the time that the server
1915	was prepared to wait. The client MAY repeat the request without
1916	modifications at any later time.
1917
1918	7.4.8. 409 Conflict
1919
1920	The request could not be completed due to a conflict with the current
1921	state of the resource. This code is only allowed in situations where
1922	it is expected that the user might be able to resolve the conflict
1923	and resubmit the request. The response body SHOULD include enough
1924	information for the user to recognize the source of the conflict.
1925	Ideally, the response representation would include enough information
1926	for the user or user agent to fix the problem; however, that might
1927	not be possible and is not required.
1928
1929	Conflicts are most likely to occur in response to a PUT request. For
1930	example, if versioning were being used and the representation being
1931	PUT included changes to a resource which conflict with those made by
1932	an earlier (third-party) request, the server might use the 409
1933	response to indicate that it can't complete the request. In this
1934	case, the response representation would likely contain a list of the
1935	differences between the two versions.
1936
1937	7.4.9. 410 Gone
1938
1939	The target resource is no longer available at the server and no
1940	forwarding address is known. This condition is expected to be
1941	considered permanent. Clients with link editing capabilities SHOULD
1942	delete references to the effective request URI after user approval.
1943	If the server does not know, or has no facility to determine, whether
1944	or not the condition is permanent, the status code 404 (Not Found)
1945	SHOULD be used instead.
1946
1947	The 410 response is primarily intended to assist the task of web
1948	maintenance by notifying the recipient that the resource is
1949	intentionally unavailable and that the server owners desire that
1950	remote links to that resource be removed. Such an event is common
1951	for limited-time, promotional services and for resources belonging to
1952	individuals no longer working at the server's site. It is not
1953	necessary to mark all permanently unavailable resources as "gone" or
1954	to keep the mark for any length of time -- that is left to the
1955	discretion of the server owner.
1956
1957
1958
1959	Fielding, et al. Expires September 13, 2012 [Page 35]
1960
1961	Internet-Draft HTTP/1.1, Part 2 March 2012
1962
1963
1964	Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to
1965	determine freshness for 410 responses.
1966
1967	7.4.10. 411 Length Required
1968
1969	The server refuses to accept the request without a defined Content-
1970	Length. The client MAY repeat the request if it adds a valid
1971	Content-Length header field containing the length of the message body
1972	in the request message.
1973
1974	7.4.11. 413 Request Representation Too Large
1975
1976	The server is refusing to process a request because the request
1977	representation is larger than the server is willing or able to
1978	process. The server MAY close the connection to prevent the client
1979	from continuing the request.
1980
1981	If the condition is temporary, the server SHOULD include a Retry-
1982	After header field to indicate that it is temporary and after what
1983	time the client MAY try again.
1984
1985	7.4.12. 414 URI Too Long
1986
1987	The server is refusing to service the request because the effective
1988	request URI is longer than the server is willing to interpret. This
1989	rare condition is only likely to occur when a client has improperly
1990	converted a POST request to a GET request with long query
1991	information, when the client has descended into a URI "black hole" of
1992	redirection (e.g., a redirected URI prefix that points to a suffix of
1993	itself), or when the server is under attack by a client attempting to
1994	exploit security holes present in some servers using fixed-length
1995	buffers for reading or manipulating the request-target.
1996
1997	7.4.13. 415 Unsupported Media Type
1998
1999	The server is refusing to service the request because the request
2000	payload is in a format not supported by this request method on the
2001	target resource.
2002
2003	7.4.14. 417 Expectation Failed
2004
2005	The expectation given in an Expect header field (see Section 10.3)
2006	could not be met by this server, or, if the server is a proxy, the
2007	server has unambiguous evidence that the request could not be met by
2008	the next-hop server.
2009
2010
2011
2012
2013
2014
2015	Fielding, et al. Expires September 13, 2012 [Page 36]
2016
2017	Internet-Draft HTTP/1.1, Part 2 March 2012
2018
2019
2020	7.4.15. 426 Upgrade Required
2021
2022	The request can not be completed without a prior protocol upgrade.
2023	This response MUST include an Upgrade header field (Section 6.5 of
2024	[Part1]) specifying the required protocols.
2025
2026	Example:
2027
2028	HTTP/1.1 426 Upgrade Required
2029	Upgrade: HTTP/3.0
2030	Connection: Upgrade
2031	Content-Length: 53
2032	Content-Type: text/plain
2033
2034	This service requires use of the HTTP/3.0 protocol.
2035
2036	The server SHOULD include a message body in the 426 response which
2037	indicates in human readable form the reason for the error and
2038	describes any alternative courses which may be available to the user.
2039
2040	7.5. Server Error 5xx
2041
2042	Response status codes beginning with the digit "5" indicate cases in
2043	which the server is aware that it has erred or is incapable of
2044	performing the request. Except when responding to a HEAD request,
2045	the server SHOULD include a representation containing an explanation
2046	of the error situation, and whether it is a temporary or permanent
2047	condition. User agents SHOULD display any included representation to
2048	the user. These response codes are applicable to any request method.
2049
2050	7.5.1. 500 Internal Server Error
2051
2052	The server encountered an unexpected condition which prevented it
2053	from fulfilling the request.
2054
2055	7.5.2. 501 Not Implemented
2056
2057	The server does not support the functionality required to fulfill the
2058	request. This is the appropriate response when the server does not
2059	recognize the request method and is not capable of supporting it for
2060	any resource.
2061
2062	7.5.3. 502 Bad Gateway
2063
2064	The server, while acting as a gateway or proxy, received an invalid
2065	response from the upstream server it accessed in attempting to
2066	fulfill the request.
2067
2068
2069
2070
2071	Fielding, et al. Expires September 13, 2012 [Page 37]
2072
2073	Internet-Draft HTTP/1.1, Part 2 March 2012
2074
2075
2076	7.5.4. 503 Service Unavailable
2077
2078	The server is currently unable to handle the request due to a
2079	temporary overloading or maintenance of the server.
2080
2081	The implication is that this is a temporary condition which will be
2082	alleviated after some delay. If known, the length of the delay MAY
2083	be indicated in a Retry-After header field (Section 10.8). If no
2084	Retry-After is given, the client SHOULD handle the response as it
2085	would for a 500 response.
2086
2087	Note: The existence of the 503 status code does not imply that a
2088	server must use it when becoming overloaded. Some servers might
2089	wish to simply refuse the connection.
2090
2091	7.5.5. 504 Gateway Timeout
2092
2093	The server, while acting as a gateway or proxy, did not receive a
2094	timely response from the upstream server specified by the URI (e.g.,
2095	HTTP, FTP, LDAP) or some other auxiliary server (e.g., DNS) it needed
2096	to access in attempting to complete the request.
2097
2098	Note to implementors: some deployed proxies are known to return
2099	400 or 500 when DNS lookups time out.
2100
2101	7.5.6. 505 HTTP Version Not Supported
2102
2103	The server does not support, or refuses to support, the protocol
2104	version that was used in the request message. The server is
2105	indicating that it is unable or unwilling to complete the request
2106	using the same major version as the client, as described in Section
2107	2.6 of [Part1], other than with this error message. The response
2108	SHOULD contain a representation describing why that version is not
2109	supported and what other protocols are supported by that server.
2110
2111	8. Date/Time Formats
2112
2113	HTTP applications have historically allowed three different formats
2114	for date/time stamps. However, the preferred format is a fixed-
2115	length subset of that defined by [RFC1123]:
2116
2117	Sun, 06 Nov 1994 08:49:37 GMT ; RFC 1123
2118
2119	The other formats are described here only for compatibility with
2120	obsolete implementations.
2121
2122	Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format
2123	Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format
2124
2125
2126
2127	Fielding, et al. Expires September 13, 2012 [Page 38]
2128
2129	Internet-Draft HTTP/1.1, Part 2 March 2012
2130
2131
2132	HTTP/1.1 clients and servers that parse a date value MUST accept all
2133	three formats (for compatibility with HTTP/1.0), though they MUST
2134	only generate the RFC 1123 format for representing HTTP-date values
2135	in header fields.
2136
2137	All HTTP date/time stamps MUST be represented in Greenwich Mean Time
2138	(GMT), without exception. For the purposes of HTTP, GMT is exactly
2139	equal to UTC (Coordinated Universal Time). This is indicated in the
2140	first two formats by the inclusion of "GMT" as the three-letter
2141	abbreviation for time zone, and MUST be assumed when reading the
2142	asctime format. HTTP-date is case sensitive and MUST NOT include
2143	additional whitespace beyond that specifically included as SP in the
2144	grammar.
2145
2146	HTTP-date = rfc1123-date / obs-date
2147
2148	Preferred format:
2149
2150
2151
2152
2153
2154
2155
2156
2157
2158
2159
2160
2161
2162
2163
2164
2165
2166
2167
2168
2169
2170
2171
2172
2173
2174
2175
2176
2177
2178
2179
2180
2181
2182
2183	Fielding, et al. Expires September 13, 2012 [Page 39]
2184
2185	Internet-Draft HTTP/1.1, Part 2 March 2012
2186
2187
2188	rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT
2189	; fixed length subset of the format defined in
2190	; Section 5.2.14 of [RFC1123]
2191
2192	day-name = %x4D.6F.6E ; "Mon", case-sensitive
2193	/ %x54.75.65 ; "Tue", case-sensitive
2194	/ %x57.65.64 ; "Wed", case-sensitive
2195	/ %x54.68.75 ; "Thu", case-sensitive
2196	/ %x46.72.69 ; "Fri", case-sensitive
2197	/ %x53.61.74 ; "Sat", case-sensitive
2198	/ %x53.75.6E ; "Sun", case-sensitive
2199
2200	date1 = day SP month SP year
2201	; e.g., 02 Jun 1982
2202
2203	day = 2DIGIT
2204	month = %x4A.61.6E ; "Jan", case-sensitive
2205	/ %x46.65.62 ; "Feb", case-sensitive
2206	/ %x4D.61.72 ; "Mar", case-sensitive
2207	/ %x41.70.72 ; "Apr", case-sensitive
2208	/ %x4D.61.79 ; "May", case-sensitive
2209	/ %x4A.75.6E ; "Jun", case-sensitive
2210	/ %x4A.75.6C ; "Jul", case-sensitive
2211	/ %x41.75.67 ; "Aug", case-sensitive
2212	/ %x53.65.70 ; "Sep", case-sensitive
2213	/ %x4F.63.74 ; "Oct", case-sensitive
2214	/ %x4E.6F.76 ; "Nov", case-sensitive
2215	/ %x44.65.63 ; "Dec", case-sensitive
2216	year = 4DIGIT
2217
2218	GMT = %x47.4D.54 ; "GMT", case-sensitive
2219
2220	time-of-day = hour ":" minute ":" second
2221	; 00:00:00 - 23:59:59
2222
2223	hour = 2DIGIT
2224	minute = 2DIGIT
2225	second = 2DIGIT
2226
2227	The semantics of day-name, day, month, year, and time-of-day are the
2228	same as those defined for the RFC 5322 constructs with the
2229	corresponding name ([RFC5322], Section 3.3).
2230
2231	Obsolete formats:
2232
2233	obs-date = rfc850-date / asctime-date
2234
2235
2236
2237
2238
2239	Fielding, et al. Expires September 13, 2012 [Page 40]
2240
2241	Internet-Draft HTTP/1.1, Part 2 March 2012
2242
2243
2244	rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT
2245	date2 = day "-" month "-" 2DIGIT
2246	; day-month-year (e.g., 02-Jun-82)
2247
2248	day-name-l = %x4D.6F.6E.64.61.79 ; "Monday", case-sensitive
2249	/ %x54.75.65.73.64.61.79 ; "Tuesday", case-sensitive
2250	/ %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive
2251	/ %x54.68.75.72.73.64.61.79 ; "Thursday", case-sensitive
2252	/ %x46.72.69.64.61.79 ; "Friday", case-sensitive
2253	/ %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive
2254	/ %x53.75.6E.64.61.79 ; "Sunday", case-sensitive
2255
2256
2257	asctime-date = day-name SP date3 SP time-of-day SP year
2258	date3 = month SP ( 2DIGIT / ( SP 1DIGIT ))
2259	; month day (e.g., Jun 2)
2260
2261	Note: Recipients of date values are encouraged to be robust in
2262	accepting date values that might have been sent by non-HTTP
2263	applications, as is sometimes the case when retrieving or posting
2264	messages via proxies/gateways to SMTP or NNTP.
2265
2266	Note: HTTP requirements for the date/time stamp format apply only
2267	to their usage within the protocol stream. Clients and servers
2268	are not required to use these formats for user presentation,
2269	request logging, etc.
2270
2271	9. Product Tokens
2272
2273	Product tokens are used to allow communicating applications to
2274	identify themselves by software name and version. Most fields using
2275	product tokens also allow sub-products which form a significant part
2276	of the application to be listed, separated by whitespace. By
2277	convention, the products are listed in order of their significance
2278	for identifying the application.
2279
2280	product = token ["/" product-version]
2281	product-version = token
2282
2283	Examples:
2284
2285	User-Agent: CERN-LineMode/2.15 libwww/2.17b3
2286	Server: Apache/0.8.4
2287
2288	Product tokens SHOULD be short and to the point. They MUST NOT be
2289	used for advertising or other non-essential information. Although
2290	any token octet MAY appear in a product-version, this token SHOULD
2291	only be used for a version identifier (i.e., successive versions of
2292
2293
2294
2295	Fielding, et al. Expires September 13, 2012 [Page 41]
2296
2297	Internet-Draft HTTP/1.1, Part 2 March 2012
2298
2299
2300	the same product SHOULD only differ in the product-version portion of
2301	the product value).
2302
2303	10. Header Field Definitions
2304
2305	This section defines the syntax and semantics of HTTP/1.1 header
2306	fields related to request and response semantics.
2307
2308	10.1. Allow
2309
2310	The "Allow" header field lists the set of methods advertised as
2311	supported by the target resource. The purpose of this field is
2312	strictly to inform the recipient of valid request methods associated
2313	with the resource.
2314
2315	Allow = #method
2316
2317	Example of use:
2318
2319	Allow: GET, HEAD, PUT
2320
2321	The actual set of allowed methods is defined by the origin server at
2322	the time of each request.
2323
2324	A proxy MUST NOT modify the Allow header field -- it does not need to
2325	understand all the methods specified in order to handle them
2326	according to the generic message handling rules.
2327
2328	10.2. Date
2329
2330	The "Date" header field represents the date and time at which the
2331	message was originated, having the same semantics as the Origination
2332	Date Field (orig-date) defined in Section 3.6.1 of [RFC5322]. The
2333	field value is an HTTP-date, as defined in Section 8; it MUST be sent
2334	in rfc1123-date format.
2335
2336	Date = HTTP-date
2337
2338	An example is
2339
2340	Date: Tue, 15 Nov 1994 08:12:31 GMT
2341
2342	Origin servers MUST include a Date header field in all responses,
2343	except in these cases:
2344
2345	1. If the response status code is 100 (Continue) or 101 (Switching
2346	Protocols), the response MAY include a Date header field, at the
2347	server's option.
2348
2349
2350
2351	Fielding, et al. Expires September 13, 2012 [Page 42]
2352
2353	Internet-Draft HTTP/1.1, Part 2 March 2012
2354
2355
2356	2. If the response status code conveys a server error, e.g., 500
2357	(Internal Server Error) or 503 (Service Unavailable), and it is
2358	inconvenient or impossible to generate a valid Date.
2359
2360	3. If the server does not have a clock that can provide a reasonable
2361	approximation of the current time, its responses MUST NOT include
2362	a Date header field.
2363
2364	A received message that does not have a Date header field MUST be
2365	assigned one by the recipient if the message will be cached by that
2366	recipient.
2367
2368	Clients can use the Date header field as well; in order to keep
2369	request messages small, they are advised not to include it when it
2370	doesn't convey any useful information (as is usually the case for
2371	requests that do not contain a payload).
2372
2373	The HTTP-date sent in a Date header field SHOULD NOT represent a date
2374	and time subsequent to the generation of the message. It SHOULD
2375	represent the best available approximation of the date and time of
2376	message generation, unless the implementation has no means of
2377	generating a reasonably accurate date and time. In theory, the date
2378	ought to represent the moment just before the payload is generated.
2379	In practice, the date can be generated at any time during the message
2380	origination without affecting its semantic value.
2381
2382	10.3. Expect
2383
2384	The "Expect" header field is used to indicate that particular server
2385	behaviors are required by the client.
2386
2387	Expect = 1#expectation
2388
2389	expectation = expect-name [ BWS "=" BWS expect-value ]
2390	*( OWS ";" [ OWS expect-param ] )
2391	expect-param = expect-name [ BWS "=" BWS expect-value ]
2392
2393	expect-name = token
2394	expect-value = token / quoted-string
2395
2396	If all received Expect header field(s) are syntactically valid but
2397	contain an expectation that the recipient does not understand or
2398	cannot comply with, the recipient MUST respond with a 417
2399	(Expectation Failed) status code. A recipient of a syntactically
2400	invalid Expectation header field MUST respond with a 4xx status code
2401	other than 417.
2402
2403	The only expectation defined by this specification is:
2404
2405
2406
2407	Fielding, et al. Expires September 13, 2012 [Page 43]
2408
2409	Internet-Draft HTTP/1.1, Part 2 March 2012
2410
2411
2412	100-continue
2413
2414	The "100-continue" expectation is defined Section 6.4.3 of
2415	[Part1]. It does not support any expect-params.
2416
2417	Comparison is case-insensitive for names (expect-name), and case-
2418	sensitive for values (expect-value).
2419
2420	The Expect mechanism is hop-by-hop: the above requirements apply to
2421	any server, including proxies. However, the Expect header field
2422	itself is end-to-end; it MUST be forwarded if the request is
2423	forwarded.
2424
2425	Many older HTTP/1.0 and HTTP/1.1 applications do not understand the
2426	Expect header field.
2427
2428	10.4. From
2429
2430	The "From" header field, if given, SHOULD contain an Internet e-mail
2431	address for the human user who controls the requesting user agent.
2432	The address SHOULD be machine-usable, as defined by "mailbox" in
2433	Section 3.4 of [RFC5322]:
2434
2435	From = mailbox
2436
2437	mailbox = <mailbox, defined in [RFC5322], Section 3.4>
2438
2439	An example is:
2440
2441	From: webmaster@example.org
2442
2443	This header field MAY be used for logging purposes and as a means for
2444	identifying the source of invalid or unwanted requests. It SHOULD
2445	NOT be used as an insecure form of access protection. The
2446	interpretation of this field is that the request is being performed
2447	on behalf of the person given, who accepts responsibility for the
2448	method performed. In particular, robot agents SHOULD include this
2449	header field so that the person responsible for running the robot can
2450	be contacted if problems occur on the receiving end.
2451
2452	The Internet e-mail address in this field MAY be separate from the
2453	Internet host which issued the request. For example, when a request
2454	is passed through a proxy the original issuer's address SHOULD be
2455	used.
2456
2457	The client SHOULD NOT send the From header field without the user's
2458	approval, as it might conflict with the user's privacy interests or
2459	their site's security policy. It is strongly recommended that the
2460
2461
2462
2463	Fielding, et al. Expires September 13, 2012 [Page 44]
2464
2465	Internet-Draft HTTP/1.1, Part 2 March 2012
2466
2467
2468	user be able to disable, enable, and modify the value of this field
2469	at any time prior to a request.
2470
2471	10.5. Location
2472
2473	The "Location" header field MAY be sent in responses to refer to a
2474	specific resource in accordance with the semantics of the status
2475	code.
2476
2477	Location = URI-reference
2478
2479	For 201 (Created) responses, the Location is the URI of the new
2480	resource which was created by the request. For 3xx responses, the
2481	location SHOULD indicate the server's preferred URI for automatic
2482	redirection to the resource.
2483
2484	The field value consists of a single URI-reference. When it has the
2485	form of a relative reference ([RFC3986], Section 4.2), the final
2486	value is computed by resolving it against the effective request URI
2487	([RFC3986], Section 5). If the original URI, as navigated to by the
2488	user agent, did contain a fragment identifier, and the final value
2489	does not, then the original URI's fragment identifier is added to the
2490	final value.
2491
2492	For example, the original URI "http://www.example.org/~tim", combined
2493	with a field value given as:
2494
2495	Location: /pub/WWW/People.html#tim
2496
2497	would result in a final value of
2498	"http://www.example.org/pub/WWW/People.html#tim"
2499
2500	An original URI "http://www.example.org/index.html#larry", combined
2501	with a field value given as:
2502
2503	Location: http://www.example.net/index.html
2504
2505	would result in a final value of
2506	"http://www.example.net/index.html#larry", preserving the original
2507	fragment identifier.
2508
2509	Note: Some recipients attempt to recover from Location fields that
2510	are not valid URI references. This specification does not mandate
2511	or define such processing, but does allow it (see Section 1.1).
2512
2513	There are circumstances in which a fragment identifier in a Location
2514	URI would not be appropriate. For instance, when it appears in a 201
2515	Created response, where the Location header field specifies the URI
2516
2517
2518
2519	Fielding, et al. Expires September 13, 2012 [Page 45]
2520
2521	Internet-Draft HTTP/1.1, Part 2 March 2012
2522
2523
2524	for the entire created resource.
2525
2526	Note: The Content-Location header field (Section 6.7 of [Part3])
2527	differs from Location in that the Content-Location identifies the
2528	most specific resource corresponding to the enclosed
2529	representation. It is therefore possible for a response to
2530	contain header fields for both Location and Content-Location.
2531
2532	10.6. Max-Forwards
2533
2534	The "Max-Forwards" header field provides a mechanism with the TRACE
2535	(Section 6.8) and OPTIONS (Section 6.2) methods to limit the number
2536	of times that the request is forwarded by proxies. This can be
2537	useful when the client is attempting to trace a request which appears
2538	to be failing or looping mid-chain.
2539
2540	Max-Forwards = 1*DIGIT
2541
2542	The Max-Forwards value is a decimal integer indicating the remaining
2543	number of times this request message can be forwarded.
2544
2545	Each recipient of a TRACE or OPTIONS request containing a Max-
2546	Forwards header field MUST check and update its value prior to
2547	forwarding the request. If the received value is zero (0), the
2548	recipient MUST NOT forward the request; instead, it MUST respond as
2549	the final recipient. If the received Max-Forwards value is greater
2550	than zero, then the forwarded message MUST contain an updated Max-
2551	Forwards field with a value decremented by one (1).
2552
2553	The Max-Forwards header field MAY be ignored for all other request
2554	methods.
2555
2556	10.7. Referer
2557
2558	The "Referer" [sic] header field allows the client to specify the URI
2559	of the resource from which the target URI was obtained (the
2560	"referrer", although the header field is misspelled.).
2561
2562	The Referer header field allows servers to generate lists of back-
2563	links to resources for interest, logging, optimized caching, etc. It
2564	also allows obsolete or mistyped links to be traced for maintenance.
2565	Some servers use Referer as a means of controlling where they allow
2566	links from (so-called "deep linking"), but legitimate requests do not
2567	always contain a Referer header field.
2568
2569	If the target URI was obtained from a source that does not have its
2570	own URI (e.g., input from the user keyboard), the Referer field MUST
2571	either be sent with the value "about:blank", or not be sent at all.
2572
2573
2574
2575	Fielding, et al. Expires September 13, 2012 [Page 46]
2576
2577	Internet-Draft HTTP/1.1, Part 2 March 2012
2578
2579
2580	Note that this requirement does not apply to sources with non-HTTP
2581	URIs (e.g., FTP).
2582
2583	Referer = absolute-URI / partial-URI
2584
2585	Example:
2586
2587	Referer: http://www.example.org/hypertext/Overview.html
2588
2589	If the field value is a relative URI, it SHOULD be interpreted
2590	relative to the effective request URI. The URI MUST NOT include a
2591	fragment. See Section 12.2 for security considerations.
2592
2593	10.8. Retry-After
2594
2595	The header "Retry-After" field can be used with a 503 (Service
2596	Unavailable) response to indicate how long the service is expected to
2597	be unavailable to the requesting client. This field MAY also be used
2598	with any 3xx (Redirection) response to indicate the minimum time the
2599	user-agent is asked to wait before issuing the redirected request.
2600
2601	The value of this field can be either an HTTP-date or an integer
2602	number of seconds (in decimal) after the time of the response.
2603
2604	Retry-After = HTTP-date / delta-seconds
2605
2606	Time spans are non-negative decimal integers, representing time in
2607	seconds.
2608
2609	delta-seconds = 1*DIGIT
2610
2611	Two examples of its use are
2612
2613	Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
2614	Retry-After: 120
2615
2616	In the latter example, the delay is 2 minutes.
2617
2618	10.9. Server
2619
2620	The "Server" header field contains information about the software
2621	used by the origin server to handle the request.
2622
2623	The field can contain multiple product tokens (Section 9) and
2624	comments (Section 3.2 of [Part1]) identifying the server and any
2625	significant subproducts. The product tokens are listed in order of
2626	their significance for identifying the application.
2627
2628
2629
2630
2631	Fielding, et al. Expires September 13, 2012 [Page 47]
2632
2633	Internet-Draft HTTP/1.1, Part 2 March 2012
2634
2635
2636	Server = product *( RWS ( product / comment ) )
2637
2638	Example:
2639
2640	Server: CERN/3.0 libwww/2.17
2641
2642	If the response is being forwarded through a proxy, the proxy
2643	application MUST NOT modify the Server header field. Instead, it
2644	MUST include a Via field (as described in Section 6.2 of [Part1]).
2645
2646	Note: Revealing the specific software version of the server might
2647	allow the server machine to become more vulnerable to attacks
2648	against software that is known to contain security holes. Server
2649	implementors are encouraged to make this field a configurable
2650	option.
2651
2652	10.10. User-Agent
2653
2654	The "User-Agent" header field contains information about the user
2655	agent originating the request. User agents SHOULD include this field
2656	with requests.
2657
2658	Typically, it is used for statistical purposes, the tracing of
2659	protocol violations, and tailoring responses to avoid particular user
2660	agent limitations.
2661
2662	The field can contain multiple product tokens (Section 9) and
2663	comments (Section 3.2 of [Part1]) identifying the agent and its
2664	significant subproducts. By convention, the product tokens are
2665	listed in order of their significance for identifying the
2666	application.
2667
2668	Because this field is usually sent on every request a user agent
2669	makes, implementations are encouraged not to include needlessly fine-
2670	grained detail, and to limit (or even prohibit) the addition of
2671	subproducts by third parties. Overly long and detailed User-Agent
2672	field values make requests larger and can also be used to identify
2673	("fingerprint") the user against their wishes.
2674
2675	Likewise, implementations are encouraged not to use the product
2676	tokens of other implementations in order to declare compatibility
2677	with them, as this circumvents the purpose of the field. Finally,
2678	they are encouraged not to use comments to identify products; doing
2679	so makes the field value more difficult to parse.
2680
2681	User-Agent = product *( RWS ( product / comment ) )
2682
2683	Example:
2684
2685
2686
2687	Fielding, et al. Expires September 13, 2012 [Page 48]
2688
2689	Internet-Draft HTTP/1.1, Part 2 March 2012
2690
2691
2692	User-Agent: CERN-LineMode/2.15 libwww/2.17b3
2693
2694	11. IANA Considerations
2695
2696	11.1. Method Registry
2697
2698	The registration procedure for HTTP request methods is defined by
2699	Section 2.2 of this document.
2700
2701	The HTTP Method Registry shall be created at
2702	<http://www.iana.org/assignments/http-methods> and be populated with
2703	the registrations below:
2704
2705	+---------+------+-------------+
2706	\| Method \| Safe \| Reference \|
2707	+---------+------+-------------+
2708	\| CONNECT \| no \| Section 6.9 \|
2709	\| DELETE \| no \| Section 6.7 \|
2710	\| GET \| yes \| Section 6.3 \|
2711	\| HEAD \| yes \| Section 6.4 \|
2712	\| OPTIONS \| yes \| Section 6.2 \|
2713	\| POST \| no \| Section 6.5 \|
2714	\| PUT \| no \| Section 6.6 \|
2715	\| TRACE \| yes \| Section 6.8 \|
2716	+---------+------+-------------+
2717
2718	11.2. Status Code Registry
2719
2720	The registration procedure for HTTP Status Codes -- previously
2721	defined in Section 7.1 of [RFC2817] -- is now defined by Section 4.2
2722	of this document.
2723
2724	The HTTP Status Code Registry located at
2725	<http://www.iana.org/assignments/http-status-codes> shall be updated
2726	with the registrations below:
2727
2728
2729
2730
2731
2732
2733
2734
2735
2736
2737
2738
2739
2740
2741
2742
2743	Fielding, et al. Expires September 13, 2012 [Page 49]
2744
2745	Internet-Draft HTTP/1.1, Part 2 March 2012
2746
2747
2748	+-------+----------------------------------+----------------+
2749	\| Value \| Description \| Reference \|
2750	+-------+----------------------------------+----------------+
2751	\| 100 \| Continue \| Section 7.1.1 \|
2752	\| 101 \| Switching Protocols \| Section 7.1.2 \|
2753	\| 200 \| OK \| Section 7.2.1 \|
2754	\| 201 \| Created \| Section 7.2.2 \|
2755	\| 202 \| Accepted \| Section 7.2.3 \|
2756	\| 203 \| Non-Authoritative Information \| Section 7.2.4 \|
2757	\| 204 \| No Content \| Section 7.2.5 \|
2758	\| 205 \| Reset Content \| Section 7.2.6 \|
2759	\| 300 \| Multiple Choices \| Section 7.3.1 \|
2760	\| 301 \| Moved Permanently \| Section 7.3.2 \|
2761	\| 302 \| Found \| Section 7.3.3 \|
2762	\| 303 \| See Other \| Section 7.3.4 \|
2763	\| 305 \| Use Proxy \| Section 7.3.5 \|
2764	\| 306 \| (Unused) \| Section 7.3.6 \|
2765	\| 307 \| Temporary Redirect \| Section 7.3.7 \|
2766	\| 400 \| Bad Request \| Section 7.4.1 \|
2767	\| 402 \| Payment Required \| Section 7.4.2 \|
2768	\| 403 \| Forbidden \| Section 7.4.3 \|
2769	\| 404 \| Not Found \| Section 7.4.4 \|
2770	\| 405 \| Method Not Allowed \| Section 7.4.5 \|
2771	\| 406 \| Not Acceptable \| Section 7.4.6 \|
2772	\| 408 \| Request Timeout \| Section 7.4.7 \|
2773	\| 409 \| Conflict \| Section 7.4.8 \|
2774	\| 410 \| Gone \| Section 7.4.9 \|
2775	\| 411 \| Length Required \| Section 7.4.10 \|
2776	\| 413 \| Request Representation Too Large \| Section 7.4.11 \|
2777	\| 414 \| URI Too Long \| Section 7.4.12 \|
2778	\| 415 \| Unsupported Media Type \| Section 7.4.13 \|
2779	\| 417 \| Expectation Failed \| Section 7.4.14 \|
2780	\| 426 \| Upgrade Required \| Section 7.4.15 \|
2781	\| 500 \| Internal Server Error \| Section 7.5.1 \|
2782	\| 501 \| Not Implemented \| Section 7.5.2 \|
2783	\| 502 \| Bad Gateway \| Section 7.5.3 \|
2784	\| 503 \| Service Unavailable \| Section 7.5.4 \|
2785	\| 504 \| Gateway Timeout \| Section 7.5.5 \|
2786	\| 505 \| HTTP Version Not Supported \| Section 7.5.6 \|
2787	+-------+----------------------------------+----------------+
2788
2789	11.3. Header Field Registration
2790
2791	The Message Header Field Registry located at <http://www.iana.org/
2792	assignments/message-headers/message-header-index.html> shall be
2793	updated with the permanent registrations below (see [RFC3864]):
2794
2795
2796
2797
2798
2799	Fielding, et al. Expires September 13, 2012 [Page 50]
2800
2801	Internet-Draft HTTP/1.1, Part 2 March 2012
2802
2803
2804	+-------------------+----------+----------+---------------+
2805	\| Header Field Name \| Protocol \| Status \| Reference \|
2806	+-------------------+----------+----------+---------------+
2807	\| Allow \| http \| standard \| Section 10.1 \|
2808	\| Date \| http \| standard \| Section 10.2 \|
2809	\| Expect \| http \| standard \| Section 10.3 \|
2810	\| From \| http \| standard \| Section 10.4 \|
2811	\| Location \| http \| standard \| Section 10.5 \|
2812	\| Max-Forwards \| http \| standard \| Section 10.6 \|
2813	\| Referer \| http \| standard \| Section 10.7 \|
2814	\| Retry-After \| http \| standard \| Section 10.8 \|
2815	\| Server \| http \| standard \| Section 10.9 \|
2816	\| User-Agent \| http \| standard \| Section 10.10 \|
2817	+-------------------+----------+----------+---------------+
2818
2819	The change controller is: "IETF (iesg@ietf.org) - Internet
2820	Engineering Task Force".
2821
2822	12. Security Considerations
2823
2824	This section is meant to inform application developers, information
2825	providers, and users of the security limitations in HTTP/1.1 as
2826	described by this document. The discussion does not include
2827	definitive solutions to the problems revealed, though it does make
2828	some suggestions for reducing security risks.
2829
2830	12.1. Transfer of Sensitive Information
2831
2832	Like any generic data transfer protocol, HTTP cannot regulate the
2833	content of the data that is transferred, nor is there any a priori
2834	method of determining the sensitivity of any particular piece of
2835	information within the context of any given request. Therefore,
2836	applications SHOULD supply as much control over this information as
2837	possible to the provider of that information. Four header fields are
2838	worth special mention in this context: Server, Via, Referer and From.
2839
2840	Revealing the specific software version of the server might allow the
2841	server machine to become more vulnerable to attacks against software
2842	that is known to contain security holes. Implementors SHOULD make
2843	the Server header field a configurable option.
2844
2845	Proxies which serve as a portal through a network firewall SHOULD
2846	take special precautions regarding the transfer of header information
2847	that identifies the hosts behind the firewall. In particular, they
2848	SHOULD remove, or replace with sanitized versions, any Via fields
2849	generated behind the firewall.
2850
2851	The Referer header field allows reading patterns to be studied and
2852
2853
2854
2855	Fielding, et al. Expires September 13, 2012 [Page 51]
2856
2857	Internet-Draft HTTP/1.1, Part 2 March 2012
2858
2859
2860	reverse links drawn. Although it can be very useful, its power can
2861	be abused if user details are not separated from the information
2862	contained in the Referer. Even when the personal information has
2863	been removed, the Referer header field might indicate a private
2864	document's URI whose publication would be inappropriate.
2865
2866	The information sent in the From field might conflict with the user's
2867	privacy interests or their site's security policy, and hence it
2868	SHOULD NOT be transmitted without the user being able to disable,
2869	enable, and modify the contents of the field. The user MUST be able
2870	to set the contents of this field within a user preference or
2871	application defaults configuration.
2872
2873	We suggest, though do not require, that a convenient toggle interface
2874	be provided for the user to enable or disable the sending of From and
2875	Referer information.
2876
2877	The User-Agent (Section 10.10) or Server (Section 10.9) header fields
2878	can sometimes be used to determine that a specific client or server
2879	has a particular security hole which might be exploited.
2880	Unfortunately, this same information is often used for other valuable
2881	purposes for which HTTP currently has no better mechanism.
2882
2883	Furthermore, the User-Agent header field may contain enough entropy
2884	to be used, possibly in conjunction with other material, to uniquely
2885	identify the user.
2886
2887	Some request methods, like TRACE (Section 6.8), expose information
2888	that was sent in request header fields within the body of their
2889	response. Clients SHOULD be careful with sensitive information, like
2890	Cookies, Authorization credentials, and other header fields that
2891	might be used to collect data from the client.
2892
2893	12.2. Encoding Sensitive Information in URIs
2894
2895	Because the source of a link might be private information or might
2896	reveal an otherwise private information source, it is strongly
2897	recommended that the user be able to select whether or not the
2898	Referer field is sent. For example, a browser client could have a
2899	toggle switch for browsing openly/anonymously, which would
2900	respectively enable/disable the sending of Referer and From
2901	information.
2902
2903	Clients SHOULD NOT include a Referer header field in a (non-secure)
2904	HTTP request if the referring page was transferred with a secure
2905	protocol.
2906
2907	Authors of services SHOULD NOT use GET-based forms for the submission
2908
2909
2910
2911	Fielding, et al. Expires September 13, 2012 [Page 52]
2912
2913	Internet-Draft HTTP/1.1, Part 2 March 2012
2914
2915
2916	of sensitive data because that data will be placed in the request-
2917	target. Many existing servers, proxies, and user agents log or
2918	display the request-target in places where it might be visible to
2919	third parties. Such services can use POST-based form submission
2920	instead.
2921
2922	12.3. Location Header Fields: Spoofing and Information Leakage
2923
2924	If a single server supports multiple organizations that do not trust
2925	one another, then it MUST check the values of Location and Content-
2926	Location header fields in responses that are generated under control
2927	of said organizations to make sure that they do not attempt to
2928	invalidate resources over which they have no authority.
2929
2930	Furthermore, appending the fragment identifier from one URI to
2931	another one obtained from a Location header field might leak
2932	confidential information to the target server -- although the
2933	fragment identifier is not transmitted in the final request, it might
2934	be visible to the user agent through other means, such as scripting.
2935
2936	12.4. Security Considerations for CONNECT
2937
2938	Since tunneled data is opaque to the proxy, there are additional
2939	risks to tunneling to other well-known or reserved ports. A HTTP
2940	client CONNECTing to port 25 could relay spam via SMTP, for example.
2941	As such, proxies SHOULD restrict CONNECT access to a small number of
2942	known ports.
2943
2944	13. Acknowledgments
2945
2946	See Section 9 of [Part1].
2947
2948	14. References
2949
2950	14.1. Normative References
2951
2952	[Part1] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
2953	"HTTP/1.1, part 1: URIs, Connections, and Message
2954	Parsing", draft-ietf-httpbis-p1-messaging-19 (work in
2955	progress), March 2012.
2956
2957	[Part3] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
2958	"HTTP/1.1, part 3: Message Payload and Content
2959	Negotiation", draft-ietf-httpbis-p3-payload-19 (work in
2960	progress), March 2012.
2961
2962	[Part4] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
2963	"HTTP/1.1, part 4: Conditional Requests",
2964
2965
2966
2967	Fielding, et al. Expires September 13, 2012 [Page 53]
2968
2969	Internet-Draft HTTP/1.1, Part 2 March 2012
2970
2971
2972	draft-ietf-httpbis-p4-conditional-19 (work in progress),
2973	March 2012.
2974
2975	[Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
2976	"HTTP/1.1, part 5: Range Requests and Partial Responses",
2977	draft-ietf-httpbis-p5-range-19 (work in progress),
2978	March 2012.
2979
2980	[Part6] Fielding, R., Ed., Lafon, Y., Ed., Nottingham, M., Ed.,
2981	and J. Reschke, Ed., "HTTP/1.1, part 6: Caching",
2982	draft-ietf-httpbis-p6-cache-19 (work in progress),
2983	March 2012.
2984
2985	[Part7] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
2986	"HTTP/1.1, part 7: Authentication",
2987	draft-ietf-httpbis-p7-auth-19 (work in progress),
2988	March 2012.
2989
2990	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
2991	Requirement Levels", BCP 14, RFC 2119, March 1997.
2992
2993	[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
2994	Resource Identifier (URI): Generic Syntax", STD 66,
2995	RFC 3986, January 2005.
2996
2997	[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
2998	Specifications: ABNF", STD 68, RFC 5234, January 2008.
2999
3000	14.2. Informative References
3001
3002	[RFC1123] Braden, R., "Requirements for Internet Hosts - Application
3003	and Support", STD 3, RFC 1123, October 1989.
3004
3005	[RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext
3006	Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
3007
3008	[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.
3009	Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
3010	RFC 2068, January 1997.
3011
3012	[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
3013	Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
3014	Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
3015
3016	[RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within
3017	HTTP/1.1", RFC 2817, May 2000.
3018
3019	[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
3020
3021
3022
3023	Fielding, et al. Expires September 13, 2012 [Page 54]
3024
3025	Internet-Draft HTTP/1.1, Part 2 March 2012
3026
3027
3028	Procedures for Message Header Fields", BCP 90, RFC 3864,
3029	September 2004.
3030
3031	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
3032	IANA Considerations Section in RFCs", BCP 26, RFC 5226,
3033	May 2008.
3034
3035	[RFC5322] Resnick, P., "Internet Message Format", RFC 5322,
3036	October 2008.
3037
3038	[RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP",
3039	RFC 5789, March 2010.
3040
3041	[RFC5987] Reschke, J., "Character Set and Language Encoding for
3042	Hypertext Transfer Protocol (HTTP) Header Field
3043	Parameters", RFC 5987, August 2010.
3044
3045	Appendix A. Changes from RFC 2616
3046
3047	This document takes over the Status Code Registry, previously defined
3048	in Section 7.1 of [RFC2817]. (Section 4.2)
3049
3050	Clarify definition of POST. (Section 6.5)
3051
3052	Remove requirement to handle all Content-* header fields; ban use of
3053	Content-Range with PUT. (Section 6.6)
3054
3055	Take over definition of CONNECT method from [RFC2817]. (Section 6.9)
3056
3057	Broadened the definition of 203 (Non-Authoritative Information) to
3058	include cases of payload transformations as well. (Section 7.2.4)
3059
3060	Status codes 301, 302, and 307: removed the normative requirements on
3061	both response payloads and user interaction. (Section 7.3)
3062
3063	Failed to consider that there are many other request methods that are
3064	safe to automatically redirect, and further that the user agent is
3065	able to make that determination based on the request method
3066	semantics. Furthermore, allow user agents to rewrite the method from
3067	POST to GET for status codes 301 and 302. (Sections 7.3.2, 7.3.3 and
3068	7.3.7)
3069
3070	Deprecate 305 Use Proxy status code, because user agents did not
3071	implement it. It used to indicate that the target resource must be
3072	accessed through the proxy given by the Location field. The Location
3073	field gave the URI of the proxy. The recipient was expected to
3074	repeat this single request via the proxy. (Section 7.3.5)
3075
3076
3077
3078
3079	Fielding, et al. Expires September 13, 2012 [Page 55]
3080
3081	Internet-Draft HTTP/1.1, Part 2 March 2012
3082
3083
3084	Define status 426 (Upgrade Required) (this was incorporated from
3085	[RFC2817]). (Section 7.4.15)
3086
3087	Change ABNF productions for header fields to only define the field
3088	value. (Section 10)
3089
3090	Reclassify "Allow" as response header field, removing the option to
3091	specify it in a PUT request. Relax the server requirement on the
3092	contents of the Allow header field and remove requirement on clients
3093	to always trust the header field value. (Section 10.1)
3094
3095	The ABNF for the Expect header field has been both fixed (allowing
3096	parameters for value-less expectations as well) and simplified
3097	(allowing trailing semicolons after "100-continue" when they were
3098	invalid before). (Section 10.3)
3099
3100	Correct syntax of Location header field to allow URI references
3101	(including relative references and fragments), as referred symbol
3102	"absoluteURI" wasn't what was expected, and add some clarifications
3103	as to when use of fragments would not be appropriate. (Section 10.5)
3104
3105	Restrict Max-Forwards header field to OPTIONS and TRACE (previously,
3106	extension methods could have used it as well). (Section 10.6)
3107
3108	Allow Referer field value of "about:blank" as alternative to not
3109	specifying it. (Section 10.7)
3110
3111	In the description of the Server header field, the Via field was
3112	described as a SHOULD. The requirement was and is stated correctly
3113	in the description of the Via header field in Section 6.2 of [Part1].
3114	(Section 10.9)
3115
3116	Appendix B. Collected ABNF
3117
3118	Allow = [ ( "," / method ) *( OWS "," [ OWS method ] ) ]
3119
3120	BWS = <BWS, defined in [Part1], Section 3.2.1>
3121
3122	Date = HTTP-date
3123
3124	Expect = ( "," OWS ) expectation ( OWS "," [ OWS expectation ] )
3125
3126	From = mailbox
3127
3128	GMT = %x47.4D.54 ; GMT
3129
3130	HTTP-date = rfc1123-date / obs-date
3131
3132
3133
3134
3135	Fielding, et al. Expires September 13, 2012 [Page 56]
3136
3137	Internet-Draft HTTP/1.1, Part 2 March 2012
3138
3139
3140	Location = URI-reference
3141
3142	Max-Forwards = 1*DIGIT
3143
3144	OWS = <OWS, defined in [Part1], Section 3.2.1>
3145
3146	RWS = <RWS, defined in [Part1], Section 3.2.1>
3147	Referer = absolute-URI / partial-URI
3148	Retry-After = HTTP-date / delta-seconds
3149
3150	Server = product *( RWS ( product / comment ) )
3151
3152	URI-reference = <URI-reference, defined in [Part1], Section 2.7>
3153	User-Agent = product *( RWS ( product / comment ) )
3154
3155	absolute-URI = <absolute-URI, defined in [Part1], Section 2.7>
3156	asctime-date = day-name SP date3 SP time-of-day SP year
3157
3158	comment = <comment, defined in [Part1], Section 3.2.4>
3159
3160	date1 = day SP month SP year
3161	date2 = day "-" month "-" 2DIGIT
3162	date3 = month SP ( 2DIGIT / ( SP DIGIT ) )
3163	day = 2DIGIT
3164	day-name = %x4D.6F.6E ; Mon
3165	/ %x54.75.65 ; Tue
3166	/ %x57.65.64 ; Wed
3167	/ %x54.68.75 ; Thu
3168	/ %x46.72.69 ; Fri
3169	/ %x53.61.74 ; Sat
3170	/ %x53.75.6E ; Sun
3171	day-name-l = %x4D.6F.6E.64.61.79 ; Monday
3172	/ %x54.75.65.73.64.61.79 ; Tuesday
3173	/ %x57.65.64.6E.65.73.64.61.79 ; Wednesday
3174	/ %x54.68.75.72.73.64.61.79 ; Thursday
3175	/ %x46.72.69.64.61.79 ; Friday
3176	/ %x53.61.74.75.72.64.61.79 ; Saturday
3177	/ %x53.75.6E.64.61.79 ; Sunday
3178	delta-seconds = 1*DIGIT
3179
3180	expect-name = token
3181	expect-param = expect-name [ BWS "=" BWS expect-value ]
3182	expect-value = token / quoted-string
3183	expectation = expect-name [ BWS "=" BWS expect-value ] *( OWS ";" [
3184	OWS expect-param ] )
3185
3186	hour = 2DIGIT
3187
3188
3189
3190
3191	Fielding, et al. Expires September 13, 2012 [Page 57]
3192
3193	Internet-Draft HTTP/1.1, Part 2 March 2012
3194
3195
3196	mailbox = <mailbox, defined in [RFC5322], Section 3.4>
3197	method = token
3198	minute = 2DIGIT
3199	month = %x4A.61.6E ; Jan
3200	/ %x46.65.62 ; Feb
3201	/ %x4D.61.72 ; Mar
3202	/ %x41.70.72 ; Apr
3203	/ %x4D.61.79 ; May
3204	/ %x4A.75.6E ; Jun
3205	/ %x4A.75.6C ; Jul
3206	/ %x41.75.67 ; Aug
3207	/ %x53.65.70 ; Sep
3208	/ %x4F.63.74 ; Oct
3209	/ %x4E.6F.76 ; Nov
3210	/ %x44.65.63 ; Dec
3211
3212	obs-date = rfc850-date / asctime-date
3213	obs-text = <obs-text, defined in [Part1], Section 3.2.4>
3214
3215	partial-URI = <partial-URI, defined in [Part1], Section 2.7>
3216	product = token [ "/" product-version ]
3217	product-version = token
3218
3219	quoted-string = <quoted-string, defined in [Part1], Section 3.2.4>
3220
3221	reason-phrase = *( HTAB / SP / VCHAR / obs-text )
3222	rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT
3223	rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT
3224
3225	second = 2DIGIT
3226	status-code = 3DIGIT
3227
3228	time-of-day = hour ":" minute ":" second
3229	token = <token, defined in [Part1], Section 3.2.4>
3230
3231	year = 4DIGIT
3232
3233
3234
3235
3236
3237
3238
3239
3240
3241
3242
3243
3244
3245
3246
3247	Fielding, et al. Expires September 13, 2012 [Page 58]
3248
3249	Internet-Draft HTTP/1.1, Part 2 March 2012
3250
3251
3252	ABNF diagnostics:
3253
3254	; Allow defined but not used
3255	; Date defined but not used
3256	; Expect defined but not used
3257	; From defined but not used
3258	; Location defined but not used
3259	; Max-Forwards defined but not used
3260	; Referer defined but not used
3261	; Retry-After defined but not used
3262	; Server defined but not used
3263	; User-Agent defined but not used
3264	; reason-phrase defined but not used
3265	; status-code defined but not used
3266
3267	Appendix C. Change Log (to be removed by RFC Editor before publication)
3268
3269	C.1. Since RFC 2616
3270
3271	Extracted relevant partitions from [RFC2616].
3272
3273	C.2. Since draft-ietf-httpbis-p2-semantics-00
3274
3275	Closed issues:
3276
3277	o <http://tools.ietf.org/wg/httpbis/trac/ticket/5>: "Via is a MUST"
3278	(<http://purl.org/NET/http-errata#via-must>)
3279
3280	o <http://tools.ietf.org/wg/httpbis/trac/ticket/6>: "Fragments
3281	allowed in Location"
3282	(<http://purl.org/NET/http-errata#location-fragments>)
3283
3284	o <http://tools.ietf.org/wg/httpbis/trac/ticket/10>: "Safe Methods
3285	vs Redirection" (<http://purl.org/NET/http-errata#saferedirect>)
3286
3287	o <http://tools.ietf.org/wg/httpbis/trac/ticket/17>: "Revise
3288	description of the POST method"
3289	(<http://purl.org/NET/http-errata#post>)
3290
3291	o <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and
3292	Informative references"
3293
3294	o <http://tools.ietf.org/wg/httpbis/trac/ticket/42>: "RFC2606
3295	Compliance"
3296
3297	o <http://tools.ietf.org/wg/httpbis/trac/ticket/65>: "Informative
3298	references"
3299
3300
3301
3302
3303	Fielding, et al. Expires September 13, 2012 [Page 59]
3304
3305	Internet-Draft HTTP/1.1, Part 2 March 2012
3306
3307
3308	o <http://tools.ietf.org/wg/httpbis/trac/ticket/84>: "Redundant
3309	cross-references"
3310
3311	Other changes:
3312
3313	o Move definitions of 304 and 412 condition codes to [Part4]
3314
3315	C.3. Since draft-ietf-httpbis-p2-semantics-01
3316
3317	Closed issues:
3318
3319	o <http://tools.ietf.org/wg/httpbis/trac/ticket/21>: "PUT side
3320	effects"
3321
3322	o <http://tools.ietf.org/wg/httpbis/trac/ticket/91>: "Duplicate Host
3323	header requirements"
3324
3325	Ongoing work on ABNF conversion
3326	(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
3327
3328	o Move "Product Tokens" section (back) into Part 1, as "token" is
3329	used in the definition of the Upgrade header field.
3330
3331	o Add explicit references to BNF syntax and rules imported from
3332	other parts of the specification.
3333
3334	o Copy definition of delta-seconds from Part6 instead of referencing
3335	it.
3336
3337	C.4. Since draft-ietf-httpbis-p2-semantics-02
3338
3339	Closed issues:
3340
3341	o <http://tools.ietf.org/wg/httpbis/trac/ticket/24>: "Requiring
3342	Allow in 405 responses"
3343
3344	o <http://tools.ietf.org/wg/httpbis/trac/ticket/59>: "Status Code
3345	Registry"
3346
3347	o <http://tools.ietf.org/wg/httpbis/trac/ticket/61>: "Redirection
3348	vs. Location"
3349
3350	o <http://tools.ietf.org/wg/httpbis/trac/ticket/70>: "Cacheability
3351	of 303 response"
3352
3353	o <http://tools.ietf.org/wg/httpbis/trac/ticket/76>: "305 Use Proxy"
3354
3355
3356
3357
3358
3359	Fielding, et al. Expires September 13, 2012 [Page 60]
3360
3361	Internet-Draft HTTP/1.1, Part 2 March 2012
3362
3363
3364	o <http://tools.ietf.org/wg/httpbis/trac/ticket/105>:
3365	"Classification for Allow header"
3366
3367	o <http://tools.ietf.org/wg/httpbis/trac/ticket/112>: "PUT - 'store
3368	under' vs 'store at'"
3369
3370	Ongoing work on IANA Message Header Field Registration
3371	(<http://tools.ietf.org/wg/httpbis/trac/ticket/40>):
3372
3373	o Reference RFC 3984, and update header field registrations for
3374	headers defined in this document.
3375
3376	Ongoing work on ABNF conversion
3377	(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
3378
3379	o Replace string literals when the string really is case-sensitive
3380	(method).
3381
3382	C.5. Since draft-ietf-httpbis-p2-semantics-03
3383
3384	Closed issues:
3385
3386	o <http://tools.ietf.org/wg/httpbis/trac/ticket/98>: "OPTIONS
3387	request bodies"
3388
3389	o <http://tools.ietf.org/wg/httpbis/trac/ticket/119>: "Description
3390	of CONNECT should refer to RFC2817"
3391
3392	o <http://tools.ietf.org/wg/httpbis/trac/ticket/125>: "Location
3393	Content-Location reference request/response mixup"
3394
3395	Ongoing work on Method Registry
3396	(<http://tools.ietf.org/wg/httpbis/trac/ticket/72>):
3397
3398	o Added initial proposal for registration process, plus initial
3399	content (non-HTTP/1.1 methods to be added by a separate
3400	specification).
3401
3402	C.6. Since draft-ietf-httpbis-p2-semantics-04
3403
3404	Closed issues:
3405
3406	o <http://tools.ietf.org/wg/httpbis/trac/ticket/103>: "Content-*"
3407
3408	o <http://tools.ietf.org/wg/httpbis/trac/ticket/132>: "RFC 2822 is
3409	updated by RFC 5322"
3410
3411	Ongoing work on ABNF conversion
3412
3413
3414
3415	Fielding, et al. Expires September 13, 2012 [Page 61]
3416
3417	Internet-Draft HTTP/1.1, Part 2 March 2012
3418
3419
3420	(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
3421
3422	o Use "/" instead of "\|" for alternatives.
3423
3424	o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
3425	whitespace ("OWS") and required whitespace ("RWS").
3426
3427	o Rewrite ABNFs to spell out whitespace rules, factor out header
3428	field value format definitions.
3429
3430	C.7. Since draft-ietf-httpbis-p2-semantics-05
3431
3432	Closed issues:
3433
3434	o <http://tools.ietf.org/wg/httpbis/trac/ticket/94>: "reason-phrase
3435	BNF"
3436
3437	Final work on ABNF conversion
3438	(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
3439
3440	o Add appendix containing collected and expanded ABNF, reorganize
3441	ABNF introduction.
3442
3443	C.8. Since draft-ietf-httpbis-p2-semantics-06
3444
3445	Closed issues:
3446
3447	o <http://tools.ietf.org/wg/httpbis/trac/ticket/144>: "Clarify when
3448	Referer is sent"
3449
3450	o <http://tools.ietf.org/wg/httpbis/trac/ticket/164>: "status codes
3451	vs methods"
3452
3453	o <http://tools.ietf.org/wg/httpbis/trac/ticket/170>: "Do not
3454	require "updates" relation for specs that register status codes or
3455	method names"
3456
3457	C.9. Since draft-ietf-httpbis-p2-semantics-07
3458
3459	Closed issues:
3460
3461	o <http://tools.ietf.org/wg/httpbis/trac/ticket/27>: "Idempotency"
3462
3463	o <http://tools.ietf.org/wg/httpbis/trac/ticket/33>: "TRACE security
3464	considerations"
3465
3466	o <http://tools.ietf.org/wg/httpbis/trac/ticket/110>: "Clarify rules
3467	for determining what entities a response carries"
3468
3469
3470
3471	Fielding, et al. Expires September 13, 2012 [Page 62]
3472
3473	Internet-Draft HTTP/1.1, Part 2 March 2012
3474
3475
3476	o <http://tools.ietf.org/wg/httpbis/trac/ticket/140>: "update note
3477	citing RFC 1945 and 2068"
3478
3479	o <http://tools.ietf.org/wg/httpbis/trac/ticket/182>: "update note
3480	about redirect limit"
3481
3482	o <http://tools.ietf.org/wg/httpbis/trac/ticket/191>: "Location
3483	header ABNF should use 'URI'"
3484
3485	o <http://tools.ietf.org/wg/httpbis/trac/ticket/192>: "fragments in
3486	Location vs status 303"
3487
3488	o <http://tools.ietf.org/wg/httpbis/trac/ticket/198>: "move IANA
3489	registrations for optional status codes"
3490
3491	Partly resolved issues:
3492
3493	o <http://tools.ietf.org/wg/httpbis/trac/ticket/171>: "Are OPTIONS
3494	and TRACE safe?"
3495
3496	C.10. Since draft-ietf-httpbis-p2-semantics-08
3497
3498	Closed issues:
3499
3500	o <http://tools.ietf.org/wg/httpbis/trac/ticket/10>: "Safe Methods
3501	vs Redirection" (we missed the introduction to the 3xx status
3502	codes when fixing this previously)
3503
3504	C.11. Since draft-ietf-httpbis-p2-semantics-09
3505
3506	Closed issues:
3507
3508	o <http://tools.ietf.org/wg/httpbis/trac/ticket/43>: "Fragment
3509	combination / precedence during redirects"
3510
3511	Partly resolved issues:
3512
3513	o <http://tools.ietf.org/wg/httpbis/trac/ticket/185>: "Location
3514	header payload handling"
3515
3516	o <http://tools.ietf.org/wg/httpbis/trac/ticket/196>: "Term for the
3517	requested resource's URI"
3518
3519	C.12. Since draft-ietf-httpbis-p2-semantics-10
3520
3521	Closed issues:
3522
3523
3524
3525
3526
3527	Fielding, et al. Expires September 13, 2012 [Page 63]
3528
3529	Internet-Draft HTTP/1.1, Part 2 March 2012
3530
3531
3532	o <http://tools.ietf.org/wg/httpbis/trac/ticket/69>: "Clarify
3533	'Requested Variant'"
3534
3535	o <http://tools.ietf.org/wg/httpbis/trac/ticket/109>: "Clarify
3536	entity / representation / variant terminology"
3537
3538	o <http://tools.ietf.org/wg/httpbis/trac/ticket/139>: "Methods and
3539	Caching"
3540
3541	o <http://tools.ietf.org/wg/httpbis/trac/ticket/190>: "OPTIONS vs
3542	Max-Forwards"
3543
3544	o <http://tools.ietf.org/wg/httpbis/trac/ticket/199>: "Status codes
3545	and caching"
3546
3547	o <http://tools.ietf.org/wg/httpbis/trac/ticket/220>: "consider
3548	removing the 'changes from 2068' sections"
3549
3550	C.13. Since draft-ietf-httpbis-p2-semantics-11
3551
3552	Closed issues:
3553
3554	o <http://tools.ietf.org/wg/httpbis/trac/ticket/229>:
3555	"Considerations for new status codes"
3556
3557	o <http://tools.ietf.org/wg/httpbis/trac/ticket/230>:
3558	"Considerations for new methods"
3559
3560	o <http://tools.ietf.org/wg/httpbis/trac/ticket/232>: "User-Agent
3561	guidelines" (relating to the 'User-Agent' header field)
3562
3563	C.14. Since draft-ietf-httpbis-p2-semantics-12
3564
3565	Closed issues:
3566
3567	o <http://tools.ietf.org/wg/httpbis/trac/ticket/43>: "Fragment
3568	combination / precedence during redirects" (added warning about
3569	having a fragid on the redirect may cause inconvenience in some
3570	cases)
3571
3572	o <http://tools.ietf.org/wg/httpbis/trac/ticket/79>: "Content-* vs.
3573	PUT"
3574
3575	o <http://tools.ietf.org/wg/httpbis/trac/ticket/88>: "205 Bodies"
3576
3577	o <http://tools.ietf.org/wg/httpbis/trac/ticket/102>: "Understanding
3578	Content-* on non-PUT requests"
3579
3580
3581
3582
3583	Fielding, et al. Expires September 13, 2012 [Page 64]
3584
3585	Internet-Draft HTTP/1.1, Part 2 March 2012
3586
3587
3588	o <http://tools.ietf.org/wg/httpbis/trac/ticket/103>: "Content-*"
3589
3590	o <http://tools.ietf.org/wg/httpbis/trac/ticket/104>: "Header type
3591	defaulting"
3592
3593	o <http://tools.ietf.org/wg/httpbis/trac/ticket/112>: "PUT - 'store
3594	under' vs 'store at'"
3595
3596	o <http://tools.ietf.org/wg/httpbis/trac/ticket/137>: "duplicate
3597	ABNF for reason-phrase"
3598
3599	o <http://tools.ietf.org/wg/httpbis/trac/ticket/180>: "Note special
3600	status of Content-* prefix in header registration procedures"
3601
3602	o <http://tools.ietf.org/wg/httpbis/trac/ticket/203>: "Max-Forwards
3603	vs extension methods"
3604
3605	o <http://tools.ietf.org/wg/httpbis/trac/ticket/213>: "What is the
3606	value space of HTTP status codes?" (actually fixed in
3607	draft-ietf-httpbis-p2-semantics-11)
3608
3609	o <http://tools.ietf.org/wg/httpbis/trac/ticket/224>: "Header
3610	Classification"
3611
3612	o <http://tools.ietf.org/wg/httpbis/trac/ticket/225>: "PUT side
3613	effect: invalidation or just stale?"
3614
3615	o <http://tools.ietf.org/wg/httpbis/trac/ticket/226>: "proxies not
3616	supporting certain methods"
3617
3618	o <http://tools.ietf.org/wg/httpbis/trac/ticket/239>: "Migrate
3619	CONNECT from RFC2817 to p2"
3620
3621	o <http://tools.ietf.org/wg/httpbis/trac/ticket/240>: "Migrate
3622	Upgrade details from RFC2817"
3623
3624	o <http://tools.ietf.org/wg/httpbis/trac/ticket/267>: "clarify PUT
3625	semantics'"
3626
3627	o <http://tools.ietf.org/wg/httpbis/trac/ticket/275>: "duplicate
3628	ABNF for 'Method'"
3629
3630	o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle
3631	ABNFs for header fields"
3632
3633
3634
3635
3636
3637
3638
3639	Fielding, et al. Expires September 13, 2012 [Page 65]
3640
3641	Internet-Draft HTTP/1.1, Part 2 March 2012
3642
3643
3644	C.15. Since draft-ietf-httpbis-p2-semantics-13
3645
3646	Closed issues:
3647
3648	o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle
3649	ABNFs for header fields"
3650
3651	o <http://tools.ietf.org/wg/httpbis/trac/ticket/251>: "message body
3652	in CONNECT request"
3653
3654	C.16. Since draft-ietf-httpbis-p2-semantics-14
3655
3656	Closed issues:
3657
3658	o <http://tools.ietf.org/wg/httpbis/trac/ticket/255>: "Clarify
3659	status code for rate limiting"
3660
3661	o <http://tools.ietf.org/wg/httpbis/trac/ticket/294>: "clarify 403
3662	forbidden"
3663
3664	o <http://tools.ietf.org/wg/httpbis/trac/ticket/296>: "Clarify 203
3665	Non-Authoritative Information"
3666
3667	o <http://tools.ietf.org/wg/httpbis/trac/ticket/298>: "update
3668	default reason phrase for 413"
3669
3670	C.17. Since draft-ietf-httpbis-p2-semantics-15
3671
3672	Closed issues:
3673
3674	o <http://tools.ietf.org/wg/httpbis/trac/ticket/285>: "Strength of
3675	requirements on Accept re: 406"
3676
3677	o <http://tools.ietf.org/wg/httpbis/trac/ticket/303>: "400 response
3678	isn't generic"
3679
3680	C.18. Since draft-ietf-httpbis-p2-semantics-16
3681
3682	Closed issues:
3683
3684	o <http://tools.ietf.org/wg/httpbis/trac/ticket/160>: "Redirects and
3685	non-GET methods"
3686
3687	o <http://tools.ietf.org/wg/httpbis/trac/ticket/186>: "Document
3688	HTTP's error-handling philosophy"
3689
3690	o <http://tools.ietf.org/wg/httpbis/trac/ticket/231>:
3691	"Considerations for new headers"
3692
3693
3694
3695	Fielding, et al. Expires September 13, 2012 [Page 66]
3696
3697	Internet-Draft HTTP/1.1, Part 2 March 2012
3698
3699
3700	o <http://tools.ietf.org/wg/httpbis/trac/ticket/310>: "clarify 303
3701	redirect on HEAD"
3702
3703	C.19. Since draft-ietf-httpbis-p2-semantics-17
3704
3705	Closed issues:
3706
3707	o <http://tools.ietf.org/wg/httpbis/trac/ticket/185>: "Location
3708	header payload handling"
3709
3710	o <http://tools.ietf.org/wg/httpbis/trac/ticket/255>: "Clarify
3711	status code for rate limiting" (change backed out because a new
3712	status code is being defined for this purpose)
3713
3714	o <http://tools.ietf.org/wg/httpbis/trac/ticket/312>: "should there
3715	be a permanent variant of 307"
3716
3717	o <http://tools.ietf.org/wg/httpbis/trac/ticket/325>: "When are
3718	Location's semantics triggered?"
3719
3720	o <http://tools.ietf.org/wg/httpbis/trac/ticket/327>: "'expect'
3721	grammar missing OWS"
3722
3723	o <http://tools.ietf.org/wg/httpbis/trac/ticket/329>: "header field
3724	considerations: quoted-string vs use of double quotes"
3725
3726	C.20. Since draft-ietf-httpbis-p2-semantics-18
3727
3728	Closed issues:
3729
3730	o <http://tools.ietf.org/wg/httpbis/trac/ticket/227>: "Combining
3731	HEAD responses"
3732
3733	o <http://tools.ietf.org/wg/httpbis/trac/ticket/238>: "Requirements
3734	for user intervention during redirects"
3735
3736	o <http://tools.ietf.org/wg/httpbis/trac/ticket/250>: "message-body
3737	in CONNECT response"
3738
3739	o <http://tools.ietf.org/wg/httpbis/trac/ticket/295>: "Applying
3740	original fragment to 'plain' redirected URI"
3741
3742	o <http://tools.ietf.org/wg/httpbis/trac/ticket/302>: "Misplaced
3743	text on connection handling in p2"
3744
3745	o <http://tools.ietf.org/wg/httpbis/trac/ticket/331>: "clarify that
3746	201 doesn't require Location header fields"
3747
3748
3749
3750
3751	Fielding, et al. Expires September 13, 2012 [Page 67]
3752
3753	Internet-Draft HTTP/1.1, Part 2 March 2012
3754
3755
3756	o <http://tools.ietf.org/wg/httpbis/trac/ticket/332>: "relax
3757	requirements on hypertext in 3/4/5xx error responses"
3758
3759	o <http://tools.ietf.org/wg/httpbis/trac/ticket/333>: "example for
3760	426 response should have a payload"
3761
3762	o <http://tools.ietf.org/wg/httpbis/trac/ticket/336>: "drop
3763	indirection entries for status codes"
3764
3765	Index
3766
3767	1
3768	100 Continue (status code) 26
3769	100-continue (expect value) 44
3770	101 Switching Protocols (status code) 27
3771
3772	2
3773	200 OK (status code) 27
3774	201 Created (status code) 27
3775	202 Accepted (status code) 28
3776	203 Non-Authoritative Information (status code) 28
3777	204 No Content (status code) 28
3778	205 Reset Content (status code) 29
3779
3780	3
3781	300 Multiple Choices (status code) 31
3782	301 Moved Permanently (status code) 31
3783	302 Found (status code) 32
3784	303 See Other (status code) 32
3785	305 Use Proxy (status code) 33
3786	306 (Unused) (status code) 33
3787	307 Temporary Redirect (status code) 33
3788
3789	4
3790	400 Bad Request (status code) 33
3791	402 Payment Required (status code) 33
3792	403 Forbidden (status code) 33
3793	404 Not Found (status code) 34
3794	405 Method Not Allowed (status code) 34
3795	406 Not Acceptable (status code) 34
3796	408 Request Timeout (status code) 35
3797	409 Conflict (status code) 35
3798	410 Gone (status code) 35
3799	411 Length Required (status code) 36
3800	413 Request Representation Too Large (status code) 36
3801	414 URI Too Long (status code) 36
3802	415 Unsupported Media Type (status code) 36
3803	417 Expectation Failed (status code) 36
3804
3805
3806
3807	Fielding, et al. Expires September 13, 2012 [Page 68]
3808
3809	Internet-Draft HTTP/1.1, Part 2 March 2012
3810
3811
3812	426 Upgrade Required (status code) 37
3813
3814	5
3815	500 Internal Server Error (status code) 37
3816	501 Not Implemented (status code) 37
3817	502 Bad Gateway (status code) 37
3818	503 Service Unavailable (status code) 38
3819	504 Gateway Timeout (status code) 38
3820	505 HTTP Version Not Supported (status code) 38
3821
3822	A
3823	Allow header field 42
3824
3825	C
3826	CONNECT method 24
3827
3828	D
3829	Date header field 42
3830	DELETE method 23
3831
3832	E
3833	Expect header field 43
3834	Expect Values
3835	100-continue 44
3836
3837	F
3838	From header field 44
3839
3840	G
3841	GET method 19
3842	Grammar
3843	Allow 42
3844	asctime-date 41
3845	Date 42
3846	date1 40
3847	day 40
3848	day-name 40
3849	day-name-l 40
3850	delta-seconds 47
3851	Expect 43
3852	expect-name 43
3853	expect-param 43
3854	expect-value 43
3855	expectation 43
3856	extension-code 12
3857	From 44
3858	GMT 40
3859	hour 40
3860
3861
3862
3863	Fielding, et al. Expires September 13, 2012 [Page 69]
3864
3865	Internet-Draft HTTP/1.1, Part 2 March 2012
3866
3867
3868	HTTP-date 39
3869	Location 45
3870	Max-Forwards 46
3871	method 7
3872	minute 40
3873	month 40
3874	obs-date 40
3875	product 41
3876	product-version 41
3877	reason-phrase 12
3878	Referer 47
3879	Retry-After 47
3880	rfc850-date 41
3881	rfc1123-date 40
3882	second 40
3883	Server 47
3884	status-code 12
3885	time-of-day 40
3886	User-Agent 48
3887	year 40
3888
3889	H
3890	HEAD method 19
3891	Header Fields
3892	Allow 42
3893	Date 42
3894	Expect 43
3895	From 44
3896	Location 45
3897	Max-Forwards 46
3898	Referer 46
3899	Retry-After 47
3900	Server 47
3901	User-Agent 48
3902
3903	I
3904	Idempotent Methods 17
3905
3906	L
3907	Location header field 45
3908
3909	M
3910	Max-Forwards header field 46
3911	Methods
3912	CONNECT 24
3913	DELETE 23
3914	GET 19
3915	HEAD 19
3916
3917
3918
3919	Fielding, et al. Expires September 13, 2012 [Page 70]
3920
3921	Internet-Draft HTTP/1.1, Part 2 March 2012
3922
3923
3924	OPTIONS 18
3925	POST 20
3926	PUT 21
3927	TRACE 23
3928
3929	O
3930	OPTIONS method 18
3931
3932	P
3933	POST method 20
3934	PUT method 21
3935
3936	R
3937	Referer header field 46
3938	Retry-After header field 47
3939
3940	S
3941	Safe Methods 17
3942	Server header field 47
3943	Status Codes
3944	100 Continue 26
3945	101 Switching Protocols 27
3946	200 OK 27
3947	201 Created 27
3948	202 Accepted 28
3949	203 Non-Authoritative Information 28
3950	204 No Content 28
3951	205 Reset Content 29
3952	300 Multiple Choices 31
3953	301 Moved Permanently 31
3954	302 Found 32
3955	303 See Other 32
3956	305 Use Proxy 33
3957	306 (Unused) 33
3958	307 Temporary Redirect 33
3959	400 Bad Request 33
3960	402 Payment Required 33
3961	403 Forbidden 33
3962	404 Not Found 34
3963	405 Method Not Allowed 34
3964	406 Not Acceptable 34
3965	408 Request Timeout 35
3966	409 Conflict 35
3967	410 Gone 35
3968	411 Length Required 36
3969	413 Request Representation Too Large 36
3970	414 URI Too Long 36
3971	415 Unsupported Media Type 36
3972
3973
3974
3975	Fielding, et al. Expires September 13, 2012 [Page 71]
3976
3977	Internet-Draft HTTP/1.1, Part 2 March 2012
3978
3979
3980	417 Expectation Failed 36
3981	426 Upgrade Required 37
3982	500 Internal Server Error 37
3983	501 Not Implemented 37
3984	502 Bad Gateway 37
3985	503 Service Unavailable 38
3986	504 Gateway Timeout 38
3987	505 HTTP Version Not Supported 38
3988
3989	T
3990	TRACE method 23
3991
3992	U
3993	User-Agent header field 48
3994
3995	Authors' Addresses
3996
3997	Roy T. Fielding (editor)
3998	Adobe Systems Incorporated
3999	345 Park Ave
4000	San Jose, CA 95110
4001	USA
4002
4003	EMail: fielding@gbiv.com
4004	URI: http://roy.gbiv.com/
4005
4006
4007	Yves Lafon (editor)
4008	World Wide Web Consortium
4009	W3C / ERCIM
4010	2004, rte des Lucioles
4011	Sophia-Antipolis, AM 06902
4012	France
4013
4014	EMail: ylafon@w3.org
4015	URI: http://www.raubacapeu.net/people/yves/
4016
4017
4018
4019
4020
4021
4022
4023
4024
4025
4026
4027
4028
4029
4030
4031	Fielding, et al. Expires September 13, 2012 [Page 72]
4032
4033	Internet-Draft HTTP/1.1, Part 2 March 2012
4034
4035
4036	Julian F. Reschke (editor)
4037	greenbytes GmbH
4038	Hafenweg 16
4039	Muenster, NW 48155
4040	Germany
4041
4042	Phone: +49 251 2807760
4043	Fax: +49 251 2807761
4044	EMail: julian.reschke@greenbytes.de
4045	URI: http://greenbytes.de/tech/webdav/
4046
4047
4048
4049
4050
4051
4052
4053
4054
4055
4056
4057
4058
4059
4060
4061
4062
4063
4064
4065
4066
4067
4068
4069
4070
4071
4072
4073
4074
4075
4076
4077
4078
4079
4080
4081
4082
4083
4084
4085
4086
4087	Fielding, et al. Expires September 13, 2012 [Page 73]
4088

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

Context Navigation

source: draft-ietf-httpbis/19/draft-ietf-httpbis-p2-semantics-19.txt @ 1596

Download in other formats: