source: draft-ietf-httpbis/17/draft-ietf-httpbis-p2-semantics-17.txt @ 1529

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

Prepare publication of -17.

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