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

Last change on this file since 1592 was 1592, checked in by julian.reschke@…, 8 years ago

-19

  • Property svn:eol-style set to native
  • Property svn:executable set to *
File size: 150.6 KB
Line 
1
2
3
4HTTPbis Working Group                                   R. Fielding, Ed.
5Internet-Draft                                                     Adobe
6Obsoletes: 2616 (if approved)                              Y. Lafon, Ed.
7Updates: 2817 (if approved)                                          W3C
8Intended status: Standards Track                         J. Reschke, Ed.
9Expires: 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
16Abstract
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
29Editorial 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
42Status 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
55Fielding, et al.       Expires September 13, 2012               [Page 1]
56
57Internet-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
67Copyright 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
94Table 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
111Fielding, et al.       Expires September 13, 2012               [Page 2]
112
113Internet-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
167Fielding, et al.       Expires September 13, 2012               [Page 3]
168
169Internet-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
223Fielding, et al.       Expires September 13, 2012               [Page 4]
224
225Internet-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
279Fielding, et al.       Expires September 13, 2012               [Page 5]
280
281Internet-Draft              HTTP/1.1, Part 2                  March 2012
282
283
2841.  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
3061.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
335Fielding, et al.       Expires September 13, 2012               [Page 6]
336
337Internet-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
3441.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
3581.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
3691.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
3782.  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
391Fielding, et al.       Expires September 13, 2012               [Page 7]
392
393Internet-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
4072.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
4272.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
447Fielding, et al.       Expires September 13, 2012               [Page 8]
448
449Internet-Draft              HTTP/1.1, Part 2                  March 2012
450
451
452   <http://www.iana.org/assignments/http-methods>.
453
4542.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
4813.  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
4883.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
503Fielding, et al.       Expires September 13, 2012               [Page 9]
504
505Internet-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
559Fielding, et al.       Expires September 13, 2012              [Page 10]
560
561Internet-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
5823.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
615Fielding, et al.       Expires September 13, 2012              [Page 11]
616
617Internet-Draft              HTTP/1.1, Part 2                  March 2012
618
619
620   | User-Agent          | Section 10.10          |
621   +---------------------+------------------------+
622
6233.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
6464.  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
671Fielding, et al.       Expires September 13, 2012              [Page 12]
672
673Internet-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
6814.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
727Fielding, et al.       Expires September 13, 2012              [Page 13]
728
729Internet-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
783Fielding, et al.       Expires September 13, 2012              [Page 14]
784
785Internet-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
7974.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
8084.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
839Fielding, et al.       Expires September 13, 2012              [Page 15]
840
841Internet-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
8485.  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
8645.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
895Fielding, et al.       Expires September 13, 2012              [Page 16]
896
897Internet-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
9126.  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
9196.1.  Safe and Idempotent Methods
920
9216.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
9426.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
951Fielding, et al.       Expires September 13, 2012              [Page 17]
952
953Internet-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
9616.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
1007Fielding, et al.       Expires September 13, 2012              [Page 18]
1008
1009Internet-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
10166.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
10536.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
1063Fielding, et al.       Expires September 13, 2012              [Page 19]
1064
1065Internet-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
10816.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
1119Fielding, et al.       Expires September 13, 2012              [Page 20]
1120
1121Internet-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
11306.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
1175Fielding, et al.       Expires September 13, 2012              [Page 21]
1176
1177Internet-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
1231Fielding, et al.       Expires September 13, 2012              [Page 22]
1232
1233Internet-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
12536.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
12786.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
1287Fielding, et al.       Expires September 13, 2012              [Page 23]
1288
1289Internet-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
13096.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
1343Fielding, et al.       Expires September 13, 2012              [Page 24]
1344
1345Internet-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
13817.  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
1399Fielding, et al.       Expires September 13, 2012              [Page 25]
1400
1401Internet-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
14177.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
14387.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
1455Fielding, et al.       Expires September 13, 2012              [Page 26]
1456
1457Internet-Draft              HTTP/1.1, Part 2                  March 2012
1458
1459
14607.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
14757.2.  Successful 2xx
1476
1477   This class of status code indicates that the client's request was
1478   successfully received, understood, and accepted.
1479
14807.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
14997.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
1511Fielding, et al.       Expires September 13, 2012              [Page 27]
1512
1513Internet-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
15267.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
15437.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
15587.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
1567Fielding, et al.       Expires September 13, 2012              [Page 28]
1568
1569Internet-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
15967.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
16087.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
1623Fielding, et al.       Expires September 13, 2012              [Page 29]
1624
1625Internet-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
1679Fielding, et al.       Expires September 13, 2012              [Page 30]
1680
1681Internet-Draft              HTTP/1.1, Part 2                  March 2012
1682
1683
1684      a fixed limitation.
1685
16867.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
17107.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
1735Fielding, et al.       Expires September 13, 2012              [Page 31]
1736
1737Internet-Draft              HTTP/1.1, Part 2                  March 2012
1738
1739
17407.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
17557.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
1791Fielding, et al.       Expires September 13, 2012              [Page 32]
1792
1793Internet-Draft              HTTP/1.1, Part 2                  March 2012
1794
1795
17967.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
18017.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
18067.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
18217.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
18317.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
18367.4.2.  402 Payment Required
1837
1838   This code is reserved for future use.
1839
18407.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
1847Fielding, et al.       Expires September 13, 2012              [Page 33]
1848
1849Internet-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
18627.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
18737.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
18797.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
1903Fielding, et al.       Expires September 13, 2012              [Page 34]
1904
1905Internet-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
19127.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
19187.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
19377.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
1959Fielding, et al.       Expires September 13, 2012              [Page 35]
1960
1961Internet-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
19677.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
19747.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
19857.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
19977.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
20037.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
2015Fielding, et al.       Expires September 13, 2012              [Page 36]
2016
2017Internet-Draft              HTTP/1.1, Part 2                  March 2012
2018
2019
20207.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
20407.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
20507.5.1.  500 Internal Server Error
2051
2052   The server encountered an unexpected condition which prevented it
2053   from fulfilling the request.
2054
20557.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
20627.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
2071Fielding, et al.       Expires September 13, 2012              [Page 37]
2072
2073Internet-Draft              HTTP/1.1, Part 2                  March 2012
2074
2075
20767.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
20917.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
21017.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
21118.  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
2127Fielding, et al.       Expires September 13, 2012              [Page 38]
2128
2129Internet-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
2183Fielding, et al.       Expires September 13, 2012              [Page 39]
2184
2185Internet-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
2239Fielding, et al.       Expires September 13, 2012              [Page 40]
2240
2241Internet-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
22719.  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
2295Fielding, et al.       Expires September 13, 2012              [Page 41]
2296
2297Internet-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
230310.  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
230810.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
232810.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
2351Fielding, et al.       Expires September 13, 2012              [Page 42]
2352
2353Internet-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
238210.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
2407Fielding, et al.       Expires September 13, 2012              [Page 43]
2408
2409Internet-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
242810.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
2463Fielding, et al.       Expires September 13, 2012              [Page 44]
2464
2465Internet-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
247110.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
2519Fielding, et al.       Expires September 13, 2012              [Page 45]
2520
2521Internet-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
253210.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
255610.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
2575Fielding, et al.       Expires September 13, 2012              [Page 46]
2576
2577Internet-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
259310.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
261810.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
2631Fielding, et al.       Expires September 13, 2012              [Page 47]
2632
2633Internet-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
265210.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
2687Fielding, et al.       Expires September 13, 2012              [Page 48]
2688
2689Internet-Draft              HTTP/1.1, Part 2                  March 2012
2690
2691
2692     User-Agent: CERN-LineMode/2.15 libwww/2.17b3
2693
269411.  IANA Considerations
2695
269611.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
271811.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
2743Fielding, et al.       Expires September 13, 2012              [Page 49]
2744
2745Internet-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
278911.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
2799Fielding, et al.       Expires September 13, 2012              [Page 50]
2800
2801Internet-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
282212.  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
283012.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
2855Fielding, et al.       Expires September 13, 2012              [Page 51]
2856
2857Internet-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
289312.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
2911Fielding, et al.       Expires September 13, 2012              [Page 52]
2912
2913Internet-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
292212.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
293612.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
294413.  Acknowledgments
2945
2946   See Section 9 of [Part1].
2947
294814.  References
2949
295014.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
2967Fielding, et al.       Expires September 13, 2012              [Page 53]
2968
2969Internet-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
300014.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
3023Fielding, et al.       Expires September 13, 2012              [Page 54]
3024
3025Internet-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
3045Appendix 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
3079Fielding, et al.       Expires September 13, 2012              [Page 55]
3080
3081Internet-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
3116Appendix 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
3135Fielding, et al.       Expires September 13, 2012              [Page 56]
3136
3137Internet-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
3191Fielding, et al.       Expires September 13, 2012              [Page 57]
3192
3193Internet-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
3247Fielding, et al.       Expires September 13, 2012              [Page 58]
3248
3249Internet-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
3267Appendix C.  Change Log (to be removed by RFC Editor before publication)
3268
3269C.1.  Since RFC 2616
3270
3271   Extracted relevant partitions from [RFC2616].
3272
3273C.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
3303Fielding, et al.       Expires September 13, 2012              [Page 59]
3304
3305Internet-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
3315C.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
3337C.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
3359Fielding, et al.       Expires September 13, 2012              [Page 60]
3360
3361Internet-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
3382C.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
3402C.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
3415Fielding, et al.       Expires September 13, 2012              [Page 61]
3416
3417Internet-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
3430C.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
3443C.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
3457C.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
3471Fielding, et al.       Expires September 13, 2012              [Page 62]
3472
3473Internet-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
3496C.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
3504C.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
3519C.12.  Since draft-ietf-httpbis-p2-semantics-10
3520
3521   Closed issues:
3522
3523
3524
3525
3526
3527Fielding, et al.       Expires September 13, 2012              [Page 63]
3528
3529Internet-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
3550C.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
3563C.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
3583Fielding, et al.       Expires September 13, 2012              [Page 64]
3584
3585Internet-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
3639Fielding, et al.       Expires September 13, 2012              [Page 65]
3640
3641Internet-Draft              HTTP/1.1, Part 2                  March 2012
3642
3643
3644C.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
3654C.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
3670C.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
3680C.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
3695Fielding, et al.       Expires September 13, 2012              [Page 66]
3696
3697Internet-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
3703C.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
3726C.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
3751Fielding, et al.       Expires September 13, 2012              [Page 67]
3752
3753Internet-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
3765Index
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
3807Fielding, et al.       Expires September 13, 2012              [Page 68]
3808
3809Internet-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
3863Fielding, et al.       Expires September 13, 2012              [Page 69]
3864
3865Internet-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
3919Fielding, et al.       Expires September 13, 2012              [Page 70]
3920
3921Internet-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
3975Fielding, et al.       Expires September 13, 2012              [Page 71]
3976
3977Internet-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
3995Authors' 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
4031Fielding, et al.       Expires September 13, 2012              [Page 72]
4032
4033Internet-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
4087Fielding, et al.       Expires September 13, 2012              [Page 73]
4088
Note: See TracBrowser for help on using the repository browser.