source: draft-ietf-httpbis/18/draft-ietf-httpbis-p2-semantics-18.txt @ 1860

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

prepare for publication of -18 on Jan 04.

  • Property svn:eol-style set to native
  • Property svn:executable set to *
File size: 154.4 KB
RevLine 
[1499]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: July 7, 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                                                         January 4, 2012
23
24
25                  HTTP/1.1, part 2: Message Semantics
26                   draft-ietf-httpbis-p2-semantics-18
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 July 7, 2012                  [Page 1]
56
57Internet-Draft              HTTP/1.1, Part 2                January 2012
58
59
60   The changes in this draft are summarized in Appendix C.19.
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 July 7, 2012.
78
79Copyright Notice
80
81   Copyright (c) 2012 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 July 7, 2012                  [Page 2]
112
113Internet-Draft              HTTP/1.1, Part 2                January 2012
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  . . . . . . . . . . . . . . . . 13
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 July 7, 2012                  [Page 3]
168
169Internet-Draft              HTTP/1.1, Part 2                January 2012
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  . . . . . . . . . . 36
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 July 7, 2012                  [Page 4]
224
225Internet-Draft              HTTP/1.1, Part 2                January 2012
226
227
228     10.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 50
229     10.3. Header Field Registration  . . . . . . . . . . . . . . . . 51
230   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 52
231     11.1. Transfer of Sensitive Information  . . . . . . . . . . . . 52
232     11.2. Encoding Sensitive Information in URIs . . . . . . . . . . 53
233     11.3. Location Headers and Spoofing  . . . . . . . . . . . . . . 54
234     11.4. Security Considerations for CONNECT  . . . . . . . . . . . 54
235   12. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 54
236   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54
237     13.1. Normative References . . . . . . . . . . . . . . . . . . . 54
238     13.2. Informative References . . . . . . . . . . . . . . . . . . 55
239   Appendix A.  Changes from RFC 2616 . . . . . . . . . . . . . . . . 56
240   Appendix B.  Collected ABNF  . . . . . . . . . . . . . . . . . . . 57
241   Appendix C.  Change Log (to be removed by RFC Editor before
242                publication)  . . . . . . . . . . . . . . . . . . . . 60
243     C.1.  Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 60
244     C.2.  Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 60
245     C.3.  Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . . 60
246     C.4.  Since draft-ietf-httpbis-p2-semantics-02 . . . . . . . . . 61
247     C.5.  Since draft-ietf-httpbis-p2-semantics-03 . . . . . . . . . 62
248     C.6.  Since draft-ietf-httpbis-p2-semantics-04 . . . . . . . . . 62
249     C.7.  Since draft-ietf-httpbis-p2-semantics-05 . . . . . . . . . 62
250     C.8.  Since draft-ietf-httpbis-p2-semantics-06 . . . . . . . . . 63
251     C.9.  Since draft-ietf-httpbis-p2-semantics-07 . . . . . . . . . 63
252     C.10. Since draft-ietf-httpbis-p2-semantics-08 . . . . . . . . . 64
253     C.11. Since draft-ietf-httpbis-p2-semantics-09 . . . . . . . . . 64
254     C.12. Since draft-ietf-httpbis-p2-semantics-10 . . . . . . . . . 64
255     C.13. Since draft-ietf-httpbis-p2-semantics-11 . . . . . . . . . 65
256     C.14. Since draft-ietf-httpbis-p2-semantics-12 . . . . . . . . . 65
257     C.15. Since draft-ietf-httpbis-p2-semantics-13 . . . . . . . . . 66
258     C.16. Since draft-ietf-httpbis-p2-semantics-14 . . . . . . . . . 67
259     C.17. Since draft-ietf-httpbis-p2-semantics-15 . . . . . . . . . 67
260     C.18. Since draft-ietf-httpbis-p2-semantics-16 . . . . . . . . . 67
261     C.19. Since draft-ietf-httpbis-p2-semantics-17 . . . . . . . . . 67
262   Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279Fielding, et al.          Expires July 7, 2012                  [Page 5]
280
281Internet-Draft              HTTP/1.1, Part 2                January 2012
282
283
2841.  Introduction
285
286   This document defines HTTP/1.1 request and response semantics.  Each
287   HTTP message, as defined in [Part1], is in the form of either a
288   request or a response.  An HTTP server listens on a connection for
289   HTTP requests and responds to each request, in the order received on
290   that connection, with one or more HTTP response messages.  This
291   document defines the commonly agreed upon semantics of the HTTP
292   uniform interface, the intentions defined by each request method, and
293   the various response messages that might be expected as a result of
294   applying that method to the target resource.
295
296   This document is currently disorganized in order to minimize the
297   changes between drafts and enable reviewers to see the smaller errata
298   changes.  A future draft will reorganize the sections to better
299   reflect the content.  In particular, the sections will be ordered
300   according to the typical processing of an HTTP request message (after
301   message parsing): resource mapping, methods, request modifying header
302   fields, response status, status modifying header fields, and resource
303   metadata.  The current mess reflects how widely dispersed these
304   topics and associated requirements had become in [RFC2616].
305
3061.1.  Conformance and Error Handling
307
308   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
309   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
310   document are to be interpreted as described in [RFC2119].
311
312   This document defines conformance criteria for several roles in HTTP
313   communication, including Senders, Recipients, Clients, Servers, User-
314   Agents, Origin Servers, Intermediaries, Proxies and Gateways.  See
315   Section 2 of [Part1] for definitions of these terms.
316
317   An implementation is considered conformant if it complies with all of
318   the requirements associated with its role(s).  Note that SHOULD-level
319   requirements are relevant here, unless one of the documented
320   exceptions is applicable.
321
322   This document also uses ABNF to define valid protocol elements
323   (Section 1.2).  In addition to the prose requirements placed upon
324   them, Senders MUST NOT generate protocol elements that are invalid.
325
326   Unless noted otherwise, Recipients MAY take steps to recover a usable
327   protocol element from an invalid construct.  However, HTTP does not
328   define specific error handling mechanisms, except in cases where it
329   has direct impact on security.  This is because different uses of the
330   protocol require different error handling strategies; for example, a
331   Web browser may wish to transparently recover from a response where
332
333
334
335Fielding, et al.          Expires July 7, 2012                  [Page 6]
336
337Internet-Draft              HTTP/1.1, Part 2                January 2012
338
339
340   the Location header field doesn't parse according to the ABNF,
341   whereby in a systems control protocol using HTTP, this type of error
342   recovery could lead to dangerous consequences.
343
3441.2.  Syntax Notation
345
346   This specification uses the 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     BWS           = <BWS, defined in [Part1], Section 1.2.2>
363     OWS           = <OWS, defined in [Part1], Section 1.2.2>
364     RWS           = <RWS, defined in [Part1], Section 1.2.2>
365     obs-text      = <obs-text, defined in [Part1], Section 1.2.2>
366     quoted-string = <quoted-string, defined in [Part1], Section 3.2.3>
367     token         = <token, defined in [Part1], Section 3.2.3>
368
3691.2.2.  ABNF Rules defined in other Parts of the Specification
370
371   The ABNF rules below are defined in other parts:
372
373     absolute-URI  = <absolute-URI, defined in [Part1], Section 2.7>
374     comment       = <comment, defined in [Part1], Section 3.2>
375     partial-URI   = <partial-URI, defined in [Part1], Section 2.7>
376     product       = <product, defined in [Part1], Section 5.2>
377     URI-reference = <URI-reference, defined in [Part1], Section 2.7>
378
3792.  Method
380
381   The Method token indicates the request method to be performed on the
382   target resource (Section 4.3 of [Part1]).  The method is case-
383   sensitive.
384
385     Method         = token
386
387   The list of methods allowed by a resource can be specified in an
388
389
390
391Fielding, et al.          Expires July 7, 2012                  [Page 7]
392
393Internet-Draft              HTTP/1.1, Part 2                January 2012
394
395
396   Allow header field (Section 9.1).  The status code of the response
397   always notifies the client whether a method is currently allowed on a
398   resource, since the set of allowed methods can change dynamically.
399   An origin server SHOULD respond with the status code 405 (Method Not
400   Allowed) if the method is known by the origin server but not allowed
401   for the resource, and 501 (Not Implemented) if the method is
402   unrecognized or not implemented by the origin server.  The methods
403   GET and HEAD MUST be supported by all general-purpose servers.  All
404   other methods are OPTIONAL; however, if the above methods are
405   implemented, they MUST be implemented with the same semantics as
406   those specified in Section 6.
407
4082.1.  Overview of Methods
409
410   The methods listed below are defined in Section 6.
411
412   +-------------+---------------+
413   | Method Name | Defined in... |
414   +-------------+---------------+
415   | OPTIONS     | Section 6.2   |
416   | GET         | Section 6.3   |
417   | HEAD        | Section 6.4   |
418   | POST        | Section 6.5   |
419   | PUT         | Section 6.6   |
420   | DELETE      | Section 6.7   |
421   | TRACE       | Section 6.8   |
422   | CONNECT     | Section 6.9   |
423   +-------------+---------------+
424
425   Note that this list is not exhaustive -- it does not include request
426   methods defined in other specifications.
427
4282.2.  Method Registry
429
430   The HTTP Method Registry defines the name space for the Method token
431   in the Request line of an HTTP request.
432
433   Registrations MUST include the following fields:
434
435   o  Method Name (see Section 2)
436
437   o  Safe ("yes" or "no", see Section 6.1.1)
438
439   o  Pointer to specification text
440
441   Values to be added to this name space are subject to IETF review
442   ([RFC5226], Section 4.1).
443
444
445
446
447Fielding, et al.          Expires July 7, 2012                  [Page 8]
448
449Internet-Draft              HTTP/1.1, Part 2                January 2012
450
451
452   The registry itself is maintained at
453   <http://www.iana.org/assignments/http-methods>.
454
4552.2.1.  Considerations for New Methods
456
457   When it is necessary to express new semantics for a HTTP request that
458   aren't specific to a single application or media type, and currently
459   defined methods are inadequate, it may be appropriate to register a
460   new method.
461
462   HTTP methods are generic; that is, they are potentially applicable to
463   any resource, not just one particular media type, "type" of resource,
464   or application.  As such, it is preferred that new HTTP methods be
465   registered in a document that isn't specific to a single application,
466   so that this is clear.
467
468   Due to the parsing rules defined in Section 3.3 of [Part1],
469   definitions of HTTP methods cannot prohibit the presence of a
470   message-body on either the request or the response message (with
471   responses to HEAD requests being the single exception).  Definitions
472   of new methods cannot change this rule, but they can specify that
473   only zero-length bodies (as opposed to absent bodies) are allowed.
474
475   New method definitions need to indicate whether they are safe
476   (Section 6.1.1), what semantics (if any) the request body has, and
477   whether they are idempotent (Section 6.1.2).  They also need to state
478   whether they can be cached ([Part6]); in particular what conditions a
479   cache may store the response, and under what conditions such a stored
480   response may be used to satisfy a subsequent request.
481
4823.  Header Fields
483
484   Header fields are key value pairs that can be used to communicate
485   data about the message, its payload, the target resource, or about
486   the connection itself (i.e., control data).  See Section 3.2 of
487   [Part1] for a general definition of their syntax.
488
4893.1.  Considerations for Creating Header Fields
490
491   New header fields are registered using the procedures described in
492   [RFC3864].
493
494   The requirements for header field names are defined in Section 4.1 of
495   [RFC3864].  Authors of specifications defining new fields are advised
496   to keep the name as short as practical, and not to prefix them with
497   "X-" if they are to be registered (either immediately or in the
498   future).
499
500
501
502
503Fielding, et al.          Expires July 7, 2012                  [Page 9]
504
505Internet-Draft              HTTP/1.1, Part 2                January 2012
506
507
508   New header field values typically have their syntax defined using
509   ABNF ([RFC5234]), using the extensions defined in Section 1.2.1 of
510   [Part1] as necessary, and are usually constrained to the range of
511   ASCII characters.  Header fields needing a greater range of
512   characters can use an encoding such as the one defined in [RFC5987].
513
514   Because commas (",") are used as a generic delimiter between field-
515   values, they need to be treated with care if they are allowed in the
516   field-value's payload.  Typically, components that might contain a
517   comma are protected with double-quotes using the quoted-string ABNF
518   production (Section 3.2.3 of [Part1]).
519
520   For example, a textual date and a URI (either of which might contain
521   a comma) could be safely carried in field-values like these:
522
523     Example-URI-Field: "http://example.com/a.html,foo",
524                        "http://without-a-comma.example.com/"
525     Example-Date-Field: "Sat, 04 May 1996", "Wed, 14 Sep 2005"
526
527   Note that double quote delimiters almost always are used with the
528   quoted-string production; using a different syntax inside double
529   quotes will likely cause unnecessary confusion.
530
531   Many header fields use a format including (case-insensitively) named
532   parameters (for instance, Content-Type, defined in Section 6.8 of
533   [Part3]).  Allowing both unquoted (token) and quoted (quoted-string)
534   syntax for the parameter value enables recipients to use existing
535   parser components.  When allowing both forms, the meaning of a
536   parameter value ought to be independent of the syntax used for it
537   (for an example, see the notes on parameter handling for media types
538   in Section 2.3 of [Part3]).
539
540   Authors of specifications defining new header fields are advised to
541   consider documenting:
542
543   o  Whether the field is a single value, or whether it can be a list
544      (delimited by commas; see Section 3.2 of [Part1]).
545
546      If it does not use the list syntax, document how to treat messages
547      where the header field occurs multiple times (a sensible default
548      would be to ignore the header field, but this might not always be
549      the right choice).
550
551      Note that intermediaries and software libraries might combine
552      multiple header field instances into a single one, despite the
553      header field not allowing this.  A robust format enables
554      recipients to discover these situations (good example: "Content-
555      Type", as the comma can only appear inside quoted strings; bad
556
557
558
559Fielding, et al.          Expires July 7, 2012                 [Page 10]
560
561Internet-Draft              HTTP/1.1, Part 2                January 2012
562
563
564      example: "Location", as a comma can occur inside a URI).
565
566   o  Under what conditions the header field can be used; e.g., only in
567      responses or requests, in all messages, only on responses to a
568      particular request method.
569
570   o  Whether it is appropriate to list the field-name in the Connection
571      header (i.e., if the header is to be hop-by-hop, see Section 8.1
572      of [Part1]).
573
574   o  Under what conditions intermediaries are allowed to modify the
575      header field's value, insert or delete it.
576
577   o  How the header might interact with caching (see [Part6]).
578
579   o  Whether the header field is useful or allowable in trailers (see
580      Section 5.1.1 of [Part1]).
581
582   o  Whether the header field should be preserved across redirects.
583
5843.2.  Request Header Fields
585
586   The request header fields allow the client to pass additional
587   information about the request, and about the client itself, to the
588   server.  These fields act as request modifiers, with semantics
589   equivalent to the parameters on a programming language method
590   invocation.
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615Fielding, et al.          Expires July 7, 2012                 [Page 11]
616
617Internet-Draft              HTTP/1.1, Part 2                January 2012
618
619
620   +---------------------+------------------------+
621   | Header Field Name   | Defined in...          |
622   +---------------------+------------------------+
623   | Accept              | Section 6.1 of [Part3] |
624   | Accept-Charset      | Section 6.2 of [Part3] |
625   | Accept-Encoding     | Section 6.3 of [Part3] |
626   | Accept-Language     | Section 6.4 of [Part3] |
627   | Authorization       | Section 4.1 of [Part7] |
628   | Expect              | Section 9.3            |
629   | From                | Section 9.4            |
630   | Host                | Section 8.3 of [Part1] |
631   | If-Match            | Section 3.1 of [Part4] |
632   | If-Modified-Since   | Section 3.3 of [Part4] |
633   | If-None-Match       | Section 3.2 of [Part4] |
634   | If-Range            | Section 5.3 of [Part5] |
635   | If-Unmodified-Since | Section 3.4 of [Part4] |
636   | Max-Forwards        | Section 9.6            |
637   | Proxy-Authorization | Section 4.3 of [Part7] |
638   | Range               | Section 5.4 of [Part5] |
639   | Referer             | Section 9.7            |
640   | TE                  | Section 8.4 of [Part1] |
641   | User-Agent          | Section 9.10           |
642   +---------------------+------------------------+
643
6443.3.  Response Header Fields
645
646   The response header fields allow the server to pass additional
647   information about the response which cannot be placed in the Status-
648   Line.  These header fields give information about the server and
649   about further access to the target resource (Section 4.3 of [Part1]).
650
651   +--------------------+------------------------+
652   | Header Field Name  | Defined in...          |
653   +--------------------+------------------------+
654   | Accept-Ranges      | Section 5.1 of [Part5] |
655   | Age                | Section 3.1 of [Part6] |
656   | Allow              | Section 9.1            |
657   | Date               | Section 9.2            |
658   | ETag               | Section 2.3 of [Part4] |
659   | Location           | Section 9.5            |
660   | Proxy-Authenticate | Section 4.2 of [Part7] |
661   | Retry-After        | Section 9.8            |
662   | Server             | Section 9.9            |
663   | Vary               | Section 3.5 of [Part6] |
664   | WWW-Authenticate   | Section 4.4 of [Part7] |
665   +--------------------+------------------------+
666
667
668
669
670
671Fielding, et al.          Expires July 7, 2012                 [Page 12]
672
673Internet-Draft              HTTP/1.1, Part 2                January 2012
674
675
6764.  Status Code and Reason Phrase
677
678   The Status-Code element is a 3-digit integer result code of the
679   attempt to understand and satisfy the request.
680
681   The Reason-Phrase is intended to give a short textual description of
682   the Status-Code and is intended for a human user.  The client does
683   not need to examine or display the Reason-Phrase.
684
685     Status-Code    = 3DIGIT
686     Reason-Phrase  = *( HTAB / SP / VCHAR / obs-text )
687
688   HTTP status codes are extensible.  HTTP applications are not required
689   to understand the meaning of all registered status codes, though such
690   understanding is obviously desirable.  However, applications MUST
691   understand the class of any status code, as indicated by the first
692   digit, and treat any unrecognized response as being equivalent to the
693   x00 status code of that class, with the exception that an
694   unrecognized response MUST NOT be cached.  For example, if an
695   unrecognized status code of 431 is received by the client, it can
696   safely assume that there was something wrong with its request and
697   treat the response as if it had received a 400 status code.  In such
698   cases, user agents SHOULD present to the user the representation
699   enclosed with the response, since that representation is likely to
700   include human-readable information which will explain the unusual
701   status.
702
7034.1.  Overview of Status Codes
704
705   The status codes listed below are defined in Section 7 of this
706   specification, Section 4 of [Part4], Section 3 of [Part5], and
707   Section 3 of [Part7].  The reason phrases listed here are only
708   recommendations -- they can be replaced by local equivalents without
709   affecting the protocol.
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727Fielding, et al.          Expires July 7, 2012                 [Page 13]
728
729Internet-Draft              HTTP/1.1, Part 2                January 2012
730
731
732   +-------------+------------------------------+----------------------+
733   | Status-Code | Reason-Phrase                | Defined in...        |
734   +-------------+------------------------------+----------------------+
735   | 100         | Continue                     | Section 7.1.1        |
736   | 101         | Switching Protocols          | Section 7.1.2        |
737   | 200         | OK                           | Section 7.2.1        |
738   | 201         | Created                      | Section 7.2.2        |
739   | 202         | Accepted                     | Section 7.2.3        |
740   | 203         | Non-Authoritative            | Section 7.2.4        |
741   |             | Information                  |                      |
742   | 204         | No Content                   | Section 7.2.5        |
743   | 205         | Reset Content                | Section 7.2.6        |
744   | 206         | Partial Content              | Section 3.1 of       |
745   |             |                              | [Part5]              |
746   | 300         | Multiple Choices             | Section 7.3.1        |
747   | 301         | Moved Permanently            | Section 7.3.2        |
748   | 302         | Found                        | Section 7.3.3        |
749   | 303         | See Other                    | Section 7.3.4        |
750   | 304         | Not Modified                 | Section 4.1 of       |
751   |             |                              | [Part4]              |
752   | 305         | Use Proxy                    | Section 7.3.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 July 7, 2012                 [Page 14]
784
785Internet-Draft              HTTP/1.1, Part 2                January 2012
786
787
788   | 502         | Bad Gateway                  | Section 7.5.3        |
789   | 503         | Service Unavailable          | Section 7.5.4        |
790   | 504         | Gateway Time-out             | Section 7.5.5        |
791   | 505         | HTTP Version not supported   | Section 7.5.6        |
792   +-------------+------------------------------+----------------------+
793
794   Note that this list is not exhaustive -- it does not include
795   extension status codes defined in other specifications.
796
7974.2.  Status Code Registry
798
799   The HTTP Status Code Registry defines the name space for the Status-
800   Code token in the Status-Line of an HTTP response.
801
802   Values to be added to this name space 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 July 7, 2012                 [Page 15]
840
841Internet-Draft              HTTP/1.1, Part 2                January 2012
842
843
844   it is not allowed), and can define how to determine the resource
845   which they carry a representation for (see Section 5.1; by default,
846   it is anonymous).
847
8485.  Representation
849
850   Request and Response messages MAY transfer a representation if not
851   otherwise restricted by the request method or response status code.
852   A representation consists of metadata (representation header fields)
853   and data (representation body).  When a complete or partial
854   representation is enclosed in an HTTP message, it is referred to as
855   the payload of the message.  HTTP representations are defined in
856   [Part3].
857
858   A representation body is only present in a message when a message-
859   body is present, as described in Section 3.3 of [Part1].  The
860   representation body is obtained from the message-body by decoding any
861   Transfer-Encoding that might have been applied to ensure safe and
862   proper transfer of the message.
863
8645.1.  Identifying the Resource Associated with a Representation
865
866   It is sometimes necessary to determine an identifier for the resource
867   associated with a representation.
868
869   An HTTP request representation, when present, is always associated
870   with an anonymous (i.e., unidentified) resource.
871
872   In the common case, an HTTP response is a representation of the
873   target resource (see Section 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 July 7, 2012                 [Page 16]
896
897Internet-Draft              HTTP/1.1, Part 2                January 2012
898
899
900       asserts that its payload is a representation of the resource
901       identified by the Content-Location URI.  However, such an
902       assertion cannot be trusted unless it can be verified by other
903       means (not defined by HTTP).
904
905   5.  Otherwise, the response is a representation of an anonymous
906       (i.e., unidentified) resource.
907
908   [[TODO-req-uri: The comparison function is going to have to be
909   defined somewhere, because we already need to compare URIs for things
910   like cache invalidation.]]
911
9126.  Method Definitions
913
914   The set of common request methods for HTTP/1.1 is defined below.
915   Although this set can be expanded, additional methods cannot be
916   assumed to share the same semantics for separately extended clients
917   and servers.
918
9196.1.  Safe and Idempotent Methods
920
9216.1.1.  Safe Methods
922
923   Implementors need to be aware that the software represents the user
924   in their interactions over the Internet, and need to allow the user
925   to be aware of any actions they take which might have an unexpected
926   significance to themselves or others.
927
928   In particular, the convention has been established that the GET,
929   HEAD, OPTIONS, and TRACE request methods SHOULD NOT have the
930   significance of taking an action other than retrieval.  These request
931   methods ought to be considered "safe".  This allows user agents to
932   represent other methods, such as POST, PUT and DELETE, in a special
933   way, so that the user is made aware of the fact that a possibly
934   unsafe action is being requested.
935
936   Naturally, it is not possible to ensure that the server does not
937   generate side-effects as a result of performing a GET request; in
938   fact, some dynamic resources consider that a feature.  The important
939   distinction here is that the user did not request the side-effects,
940   so therefore cannot be held accountable for them.
941
9426.1.2.  Idempotent Methods
943
944   Request methods can also have the property of "idempotence" in that,
945   aside from error or expiration issues, the intended effect of
946   multiple identical requests is the same as for a single request.
947   PUT, DELETE, and all safe request methods are idempotent.  It is
948
949
950
951Fielding, et al.          Expires July 7, 2012                 [Page 17]
952
953Internet-Draft              HTTP/1.1, Part 2                January 2012
954
955
956   important to note that idempotence refers only to changes requested
957   by the client: a server is free to change its state due to multiple
958   requests for the purpose of tracking those requests, versioning of
959   results, etc.
960
9616.2.  OPTIONS
962
963   The OPTIONS method requests information about the communication
964   options available on the request/response chain identified by the
965   effective request URI.  This method allows a client to determine the
966   options and/or requirements associated with a resource, or the
967   capabilities of a server, without implying a resource action or
968   initiating a resource retrieval.
969
970   Responses to the OPTIONS method are not cacheable.
971
972   If the OPTIONS request includes a message-body (as indicated by the
973   presence of Content-Length or Transfer-Encoding), then the media type
974   MUST be indicated by a Content-Type field.  Although this
975   specification does not define any use for such a body, future
976   extensions to HTTP might use the OPTIONS body to make more detailed
977   queries on the server.
978
979   If the request-target 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 July 7, 2012                 [Page 18]
1008
1009Internet-Draft              HTTP/1.1, Part 2                January 2012
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 July 7, 2012                 [Page 19]
1064
1065Internet-Draft              HTTP/1.1, Part 2                January 2012
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 July 7, 2012                 [Page 20]
1120
1121Internet-Draft              HTTP/1.1, Part 2                January 2012
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 July 7, 2012                 [Page 21]
1176
1177Internet-Draft              HTTP/1.1, Part 2                January 2012
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 July 7, 2012                 [Page 22]
1232
1233Internet-Draft              HTTP/1.1, Part 2                January 2012
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 July 7, 2012                 [Page 23]
1288
1289Internet-Draft              HTTP/1.1, Part 2                January 2012
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 July 7, 2012                 [Page 24]
1344
1345Internet-Draft              HTTP/1.1, Part 2                January 2012
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 July 7, 2012                 [Page 25]
1400
1401Internet-Draft              HTTP/1.1, Part 2                January 2012
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 July 7, 2012                 [Page 26]
1456
1457Internet-Draft              HTTP/1.1, Part 2                January 2012
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 July 7, 2012                 [Page 27]
1512
1513Internet-Draft              HTTP/1.1, Part 2                January 2012
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 July 7, 2012                 [Page 28]
1568
1569Internet-Draft              HTTP/1.1, Part 2                January 2012
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 July 7, 2012                 [Page 29]
1624
1625Internet-Draft              HTTP/1.1, Part 2                January 2012
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   A Location header field on a 3xx response indicates that a client MAY
1661   automatically redirect to the URI provided; see Section 9.5.
1662
1663   Clients SHOULD detect and intervene in cyclical redirections (i.e.,
1664   "infinite" redirection loops).
1665
1666      Note: An earlier version of this specification recommended a
1667      maximum of five redirections ([RFC2068], Section 10.3).  Content
1668      developers need to be aware that some clients might implement such
1669      a fixed limitation.
1670
16717.3.1.  300 Multiple Choices
1672
1673   The target resource has more than one representation, each with its
1674   own specific location, and agent-driven negotiation information
1675   (Section 5 of [Part3]) is being provided so that the user (or user
1676
1677
1678
1679Fielding, et al.          Expires July 7, 2012                 [Page 30]
1680
1681Internet-Draft              HTTP/1.1, Part 2                January 2012
1682
1683
1684   agent) can select a preferred representation by redirecting its
1685   request to that location.
1686
1687   Unless it was a HEAD request, the response SHOULD include a
1688   representation containing a list of representation metadata and
1689   location(s) from which the user or user agent can choose the one most
1690   appropriate.  The data format is specified by the media type given in
1691   the Content-Type header field.  Depending upon the format and the
1692   capabilities of the user agent, selection of the most appropriate
1693   choice MAY be performed automatically.  However, this specification
1694   does not define any standard for such automatic selection.
1695
1696   If the server has a preferred choice of representation, it SHOULD
1697   include the specific URI for that representation in the Location
1698   field; user agents MAY use the Location field value for automatic
1699   redirection.
1700
1701   Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to
1702   determine freshness for 300 responses.
1703
17047.3.2.  301 Moved Permanently
1705
1706   The target resource has been assigned a new permanent URI and any
1707   future references to this resource SHOULD use one of the returned
1708   URIs.  Clients with link editing capabilities ought to automatically
1709   re-link references to the effective request URI to one or more of the
1710   new references returned by the server, where possible.
1711
1712   Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to
1713   determine freshness for 301 responses.
1714
1715   The new permanent URI SHOULD be given by the Location field in the
1716   response.  Unless the request method was HEAD, the representation of
1717   the response SHOULD contain a short hypertext note with a hyperlink
1718   to the new URI(s).
1719
1720   If the 301 status code is received in response to a request method
1721   that is known to be "safe", as defined in Section 6.1.1, then the
1722   request MAY be automatically redirected by the user agent without
1723   confirmation.  Otherwise, the user agent MUST NOT automatically
1724   redirect the request unless it can be confirmed by the user, since
1725   this might change the conditions under which the request was issued.
1726
1727      Note: For historic reasons, user agents MAY change the request
1728      method from POST to GET for the subsequent request.  If this
1729      behavior is undesired, status code 307 (Temporary Redirect) can be
1730      used instead.
1731
1732
1733
1734
1735Fielding, et al.          Expires July 7, 2012                 [Page 31]
1736
1737Internet-Draft              HTTP/1.1, Part 2                January 2012
1738
1739
17407.3.3.  302 Found
1741
1742   The target resource resides temporarily under a different URI.  Since
1743   the redirection might be altered on occasion, the client SHOULD
1744   continue to use the effective request URI for future requests.
1745
1746   The temporary URI SHOULD be given by the Location field in the
1747   response.  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 July 7, 2012                 [Page 32]
1792
1793Internet-Draft              HTTP/1.1, Part 2                January 2012
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 July 7, 2012                 [Page 33]
1848
1849Internet-Draft              HTTP/1.1, Part 2                January 2012
1850
1851
1852      Note: This status code is similar to 302 Found, except that it
1853      does not allow rewriting the request method from POST to GET.
1854      This specification defines no equivalent counterpart for 301 Moved
1855      Permanently.
1856
18577.4.  Client Error 4xx
1858
1859   The 4xx class of status code is intended for cases in which the
1860   client seems to have erred.  Except when responding to a HEAD
1861   request, the server SHOULD include a representation containing an
1862   explanation of the error situation, and whether it is a temporary or
1863   permanent condition.  These status codes are applicable to any
1864   request method.  User agents SHOULD display any included
1865   representation to the user.
1866
1867   If the client is sending data, a server implementation using TCP
1868   SHOULD be careful to ensure that the client acknowledges receipt of
1869   the packet(s) containing the response, before the server closes the
1870   input connection.  If the client continues sending data to the server
1871   after the close, the server's TCP stack will send a reset packet to
1872   the client, which might erase the client's unacknowledged input
1873   buffers before they can be read and interpreted by the HTTP
1874   application.
1875
18767.4.1.  400 Bad Request
1877
1878   The server cannot or will not process the request, due to a client
1879   error (e.g., malformed syntax).
1880
18817.4.2.  401 Unauthorized
1882
1883   The request requires user authentication (see Section 3.1 of
1884   [Part7]).
1885
18867.4.3.  402 Payment Required
1887
1888   This code is reserved for future use.
1889
18907.4.4.  403 Forbidden
1891
1892   The server understood the request, but refuses to authorize it.
1893   Providing different user authentication credentials might be
1894   successful, but any credentials that were provided in the request are
1895   insufficient.  The request SHOULD NOT be repeated with the same
1896   credentials.
1897
1898   If the request method was not HEAD and the server wishes to make
1899   public why the request has not been fulfilled, it SHOULD describe the
1900
1901
1902
1903Fielding, et al.          Expires July 7, 2012                 [Page 34]
1904
1905Internet-Draft              HTTP/1.1, Part 2                January 2012
1906
1907
1908   reason for the refusal in the representation.  If the server does not
1909   wish to make this information available to the client, the status
1910   code 404 (Not Found) MAY be used instead.
1911
19127.4.5.  404 Not Found
1913
1914   The server has not found anything matching the effective request URI.
1915   No indication is given of whether the condition is temporary or
1916   permanent.  The 410 (Gone) status code SHOULD be used if the server
1917   knows, through some internally configurable mechanism, that an old
1918   resource is permanently unavailable and has no forwarding address.
1919   This status code is commonly used when the server does not wish to
1920   reveal exactly why the request has been refused, or when no other
1921   response is applicable.
1922
19237.4.6.  405 Method Not Allowed
1924
1925   The method specified in the Request-Line is not allowed for the
1926   target resource.  The response MUST include an Allow header field
1927   containing a list of valid methods for the requested resource.
1928
19297.4.7.  406 Not Acceptable
1930
1931   The resource identified by the request is only capable of generating
1932   response representations which have content characteristics not
1933   acceptable according to the Accept and Accept-* header fields sent in
1934   the request (see Section 6 of [Part3]).
1935
1936   Unless it was a HEAD request, the response SHOULD include a
1937   representation containing a list of available representation
1938   characteristics and location(s) from which the user or user agent can
1939   choose the one most appropriate.  The data format is specified by the
1940   media type given in the Content-Type header field.  Depending upon
1941   the format and the capabilities of the user agent, selection of the
1942   most appropriate choice MAY be performed automatically.  However,
1943   this specification does not define any standard for such automatic
1944   selection.
1945
1946      Note: HTTP/1.1 servers are allowed to return responses which are
1947      not acceptable according to the accept header fields sent in the
1948      request.  In some cases, this might even be preferable to sending
1949      a 406 response.  User agents are encouraged to inspect the header
1950      fields of an incoming response to determine if it is acceptable.
1951
1952   If the response could be unacceptable, a user agent SHOULD
1953   temporarily stop receipt of more data and query the user for a
1954   decision on further actions.
1955
1956
1957
1958
1959Fielding, et al.          Expires July 7, 2012                 [Page 35]
1960
1961Internet-Draft              HTTP/1.1, Part 2                January 2012
1962
1963
19647.4.8.  407 Proxy Authentication Required
1965
1966   This code is similar to 401 (Unauthorized), but indicates that the
1967   client must first authenticate itself with the proxy (see Section 3.2
1968   of [Part7]).
1969
19707.4.9.  408 Request Timeout
1971
1972   The client did not produce a request within the time that the server
1973   was prepared to wait.  The client MAY repeat the request without
1974   modifications at any later time.
1975
19767.4.10.  409 Conflict
1977
1978   The request could not be completed due to a conflict with the current
1979   state of the resource.  This code is only allowed in situations where
1980   it is expected that the user might be able to resolve the conflict
1981   and resubmit the request.  The response body SHOULD include enough
1982   information for the user to recognize the source of the conflict.
1983   Ideally, the response representation would include enough information
1984   for the user or user agent to fix the problem; however, that might
1985   not be possible and is not required.
1986
1987   Conflicts are most likely to occur in response to a PUT request.  For
1988   example, if versioning were being used and the representation being
1989   PUT included changes to a resource which conflict with those made by
1990   an earlier (third-party) request, the server might use the 409
1991   response to indicate that it can't complete the request.  In this
1992   case, the response representation would likely contain a list of the
1993   differences between the two versions in a format defined by the
1994   response Content-Type.
1995
19967.4.11.  410 Gone
1997
1998   The target resource is no longer available at the server and no
1999   forwarding address is known.  This condition is expected to be
2000   considered permanent.  Clients with link editing capabilities SHOULD
2001   delete references to the effective request URI after user approval.
2002   If the server does not know, or has no facility to determine, whether
2003   or not the condition is permanent, the status code 404 (Not Found)
2004   SHOULD be used instead.
2005
2006   The 410 response is primarily intended to assist the task of web
2007   maintenance by notifying the recipient that the resource is
2008   intentionally unavailable and that the server owners desire that
2009   remote links to that resource be removed.  Such an event is common
2010   for limited-time, promotional services and for resources belonging to
2011   individuals no longer working at the server's site.  It is not
2012
2013
2014
2015Fielding, et al.          Expires July 7, 2012                 [Page 36]
2016
2017Internet-Draft              HTTP/1.1, Part 2                January 2012
2018
2019
2020   necessary to mark all permanently unavailable resources as "gone" or
2021   to keep the mark for any length of time -- that is left to the
2022   discretion of the server owner.
2023
2024   Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to
2025   determine freshness for 410 responses.
2026
20277.4.12.  411 Length Required
2028
2029   The server refuses to accept the request without a defined Content-
2030   Length.  The client MAY repeat the request if it adds a valid
2031   Content-Length header field containing the length of the message-body
2032   in the request message.
2033
20347.4.13.  412 Precondition Failed
2035
2036   The precondition given in one or more of the header fields evaluated
2037   to false when it was tested on the server, as defined in Section 4.2
2038   of [Part4].
2039
20407.4.14.  413 Request Representation Too Large
2041
2042   The server is refusing to process a request because the request
2043   representation is larger than the server is willing or able to
2044   process.  The server MAY close the connection to prevent the client
2045   from continuing the request.
2046
2047   If the condition is temporary, the server SHOULD include a Retry-
2048   After header field to indicate that it is temporary and after what
2049   time the client MAY try again.
2050
20517.4.15.  414 URI Too Long
2052
2053   The server is refusing to service the request because the effective
2054   request URI is longer than the server is willing to interpret.  This
2055   rare condition is only likely to occur when a client has improperly
2056   converted a POST request to a GET request with long query
2057   information, when the client has descended into a URI "black hole" of
2058   redirection (e.g., a redirected URI prefix that points to a suffix of
2059   itself), or when the server is under attack by a client attempting to
2060   exploit security holes present in some servers using fixed-length
2061   buffers for reading or manipulating the effective request URI.
2062
20637.4.16.  415 Unsupported Media Type
2064
2065   The server is refusing to service the request because the request
2066   payload is in a format not supported by this request method on the
2067   target resource.
2068
2069
2070
2071Fielding, et al.          Expires July 7, 2012                 [Page 37]
2072
2073Internet-Draft              HTTP/1.1, Part 2                January 2012
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 July 7, 2012                 [Page 38]
2128
2129Internet-Draft              HTTP/1.1, Part 2                January 2012
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 to handle the request due to a
2148   temporary overloading or maintenance of the server.
2149
2150   The implication is that this is a temporary condition which will be
2151   alleviated after some delay.  If known, the length of the delay MAY
2152   be indicated in a Retry-After header field (Section 9.8).  If no
2153   Retry-After is given, the client SHOULD handle the response as it
2154   would for a 500 response.
2155
2156      Note: The existence of the 503 status code does not imply that a
2157      server must use it when becoming overloaded.  Some servers might
2158      wish to simply refuse the connection.
2159
21607.5.5.  504 Gateway Timeout
2161
2162   The server, while acting as a gateway or proxy, did not receive a
2163   timely response from the upstream server specified by the URI (e.g.,
2164   HTTP, FTP, LDAP) or some other auxiliary server (e.g., DNS) it needed
2165   to access in attempting to complete the request.
2166
2167      Note to implementors: some deployed proxies are known to return
2168      400 or 500 when DNS lookups time out.
2169
21707.5.6.  505 HTTP Version Not Supported
2171
2172   The server does not support, or refuses to support, the protocol
2173   version that was used in the request message.  The server is
2174   indicating that it is unable or unwilling to complete the request
2175   using the same major version as the client, as described in Section
2176   2.6 of [Part1], other than with this error message.  The response
2177   SHOULD contain a representation describing why that version is not
2178   supported and what other protocols are supported by that server.
2179
2180
2181
2182
2183Fielding, et al.          Expires July 7, 2012                 [Page 39]
2184
2185Internet-Draft              HTTP/1.1, Part 2                January 2012
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 July 7, 2012                 [Page 40]
2240
2241Internet-Draft              HTTP/1.1, Part 2                January 2012
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 July 7, 2012                 [Page 41]
2296
2297Internet-Draft              HTTP/1.1, Part 2                January 2012
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 July 7, 2012                 [Page 42]
2352
2353Internet-Draft              HTTP/1.1, Part 2                January 2012
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 July 7, 2012                 [Page 43]
2408
2409Internet-Draft              HTTP/1.1, Part 2                January 2012
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  = expect-name [ BWS "=" BWS expect-value ]
2423                                *( OWS ";" [ OWS expect-param ] )
2424     expect-param = expect-name [ BWS "=" BWS expect-value ]
2425
2426     expect-name  = token
2427     expect-value = token / quoted-string
2428
2429   If all received Expect header field(s) are syntactically valid but
2430   contain an expectation that the recipient does not understand or
2431   cannot comply with, the recipient MUST respond with a 417
2432   (Expectation Failed) status code.  A recipient of a syntactically
2433   invalid Expectation header field MUST respond with a 4xx status code
2434   other than 417.
2435
2436   The only expectation defined by this specification is:
2437
2438   100-continue
2439
2440      The "100-continue" expectation is defined Section 6.2.3 of
2441      [Part1].  It does not support any expect-params.
2442
2443   Comparison is case-insensitive for names (expect-name), and case-
2444   sensitive for values (expect-value).
2445
2446   The Expect mechanism is hop-by-hop: the above requirements apply to
2447   any server, including proxies.  However, the Expect header field
2448   itself is end-to-end; it MUST be forwarded if the request is
2449   forwarded.
2450
2451   Many older HTTP/1.0 and HTTP/1.1 applications do not understand the
2452   Expect header field.
2453
24549.4.  From
2455
2456   The "From" header field, if given, SHOULD contain an Internet e-mail
2457   address for the human user who controls the requesting user agent.
2458   The address SHOULD be machine-usable, as defined by "mailbox" in
2459   Section 3.4 of [RFC5322]:
2460
2461
2462
2463Fielding, et al.          Expires July 7, 2012                 [Page 44]
2464
2465Internet-Draft              HTTP/1.1, Part 2                January 2012
2466
2467
2468     From    = mailbox
2469
2470     mailbox = <mailbox, defined in [RFC5322], Section 3.4>
2471
2472   An example is:
2473
2474     From: webmaster@example.org
2475
2476   This header field MAY be used for logging purposes and as a means for
2477   identifying the source of invalid or unwanted requests.  It SHOULD
2478   NOT be used as an insecure form of access protection.  The
2479   interpretation of this field is that the request is being performed
2480   on behalf of the person given, who accepts responsibility for the
2481   method performed.  In particular, robot agents SHOULD include this
2482   header field so that the person responsible for running the robot can
2483   be contacted if problems occur on the receiving end.
2484
2485   The Internet e-mail address in this field MAY be separate from the
2486   Internet host which issued the request.  For example, when a request
2487   is passed through a proxy the original issuer's address SHOULD be
2488   used.
2489
2490   The client SHOULD NOT send the From header field without the user's
2491   approval, as it might conflict with the user's privacy interests or
2492   their site's security policy.  It is strongly recommended that the
2493   user be able to disable, enable, and modify the value of this field
2494   at any time prior to a request.
2495
24969.5.  Location
2497
2498   The "Location" header field is used to identify a newly created
2499   resource, or to redirect the recipient to a different location for
2500   completion of the request.
2501
2502   For 201 (Created) responses, the Location is the URI of the new
2503   resource which was created by the request.  For 3xx responses, the
2504   location SHOULD indicate the server's preferred URI for automatic
2505   redirection to the resource.
2506
2507   The field value consists of a single URI-reference.  When it has the
2508   form of a relative reference ([RFC3986], Section 4.2), the final
2509   value is computed by resolving it against the effective request URI
2510   ([RFC3986], Section 5).
2511
2512     Location = URI-reference
2513
2514
2515
2516
2517
2518
2519Fielding, et al.          Expires July 7, 2012                 [Page 45]
2520
2521Internet-Draft              HTTP/1.1, Part 2                January 2012
2522
2523
2524   Examples are:
2525
2526     Location: http://www.example.org/pub/WWW/People.html#tim
2527
2528     Location: /index.html
2529
2530      Note: Some recipients attempt to recover from Location fields that
2531      are not valid URI references.  This specification does not mandate
2532      or define such processing, but does allow it (see Section 1.1).
2533
2534   There are circumstances in which a fragment identifier in a Location
2535   URI would not be appropriate.  For instance, when it appears in a 201
2536   Created response, where the Location header field specifies the URI
2537   for the entire created resource.
2538
2539      Note: This specification does not define precedence rules for the
2540      case where the original URI, as navigated to by the user agent,
2541      and the Location header field value both contain fragment
2542      identifiers.  Thus be aware that including fragment identifiers
2543      might inconvenience anyone relying on the semantics of the
2544      original URI's fragment identifier.
2545
2546      Note: The Content-Location header field (Section 6.7 of [Part3])
2547      differs from Location in that the Content-Location identifies the
2548      most specific resource corresponding to the enclosed
2549      representation.  It is therefore possible for a response to
2550      contain header fields for both Location and Content-Location.
2551
25529.6.  Max-Forwards
2553
2554   The "Max-Forwards" header field provides a mechanism with the TRACE
2555   (Section 6.8) and OPTIONS (Section 6.2) methods to limit the number
2556   of times that the request is forwarded by proxies.  This can be
2557   useful when the client is attempting to trace a request which appears
2558   to be failing or looping in mid-chain.
2559
2560     Max-Forwards = 1*DIGIT
2561
2562   The Max-Forwards value is a decimal integer indicating the remaining
2563   number of times this request message can be forwarded.
2564
2565   Each recipient of a TRACE or OPTIONS request containing a Max-
2566   Forwards header field MUST check and update its value prior to
2567   forwarding the request.  If the received value is zero (0), the
2568   recipient MUST NOT forward the request; instead, it MUST respond as
2569   the final recipient.  If the received Max-Forwards value is greater
2570   than zero, then the forwarded message MUST contain an updated Max-
2571   Forwards field with a value decremented by one (1).
2572
2573
2574
2575Fielding, et al.          Expires July 7, 2012                 [Page 46]
2576
2577Internet-Draft              HTTP/1.1, Part 2                January 2012
2578
2579
2580   The Max-Forwards header field MAY be ignored for all other request
2581   methods.
2582
25839.7.  Referer
2584
2585   The "Referer" [sic] header field allows the client to specify the URI
2586   of the resource from which the effective request URI was obtained
2587   (the "referrer", although the header field is misspelled.).
2588
2589   The Referer header field allows servers to generate lists of back-
2590   links to resources for interest, logging, optimized caching, etc.  It
2591   also allows obsolete or mistyped links to be traced for maintenance.
2592   Some servers use Referer as a means of controlling where they allow
2593   links from (so-called "deep linking"), but legitimate requests do not
2594   always contain a Referer header field.
2595
2596   If the effective request URI was obtained from a source that does not
2597   have its own URI (e.g., input from the user keyboard), the Referer
2598   field MUST either be sent with the value "about:blank", or not be
2599   sent at all.  Note that this requirement does not apply to sources
2600   with non-HTTP URIs (e.g., FTP).
2601
2602     Referer = absolute-URI / partial-URI
2603
2604   Example:
2605
2606     Referer: http://www.example.org/hypertext/Overview.html
2607
2608   If the field value is a relative URI, it SHOULD be interpreted
2609   relative to the effective request URI.  The URI MUST NOT include a
2610   fragment.  See Section 11.2 for security considerations.
2611
26129.8.  Retry-After
2613
2614   The header "Retry-After" field can be used with a 503 (Service
2615   Unavailable) response to indicate how long the service is expected to
2616   be unavailable to the requesting client.  This field MAY also be used
2617   with any 3xx (Redirection) response to indicate the minimum time the
2618   user-agent is asked wait before issuing the redirected request.
2619
2620   The value of this field can be either an HTTP-date or an integer
2621   number of seconds (in decimal) after the time of the response.
2622
2623     Retry-After = HTTP-date / delta-seconds
2624
2625   Time spans are non-negative decimal integers, representing time in
2626   seconds.
2627
2628
2629
2630
2631Fielding, et al.          Expires July 7, 2012                 [Page 47]
2632
2633Internet-Draft              HTTP/1.1, Part 2                January 2012
2634
2635
2636     delta-seconds  = 1*DIGIT
2637
2638   Two examples of its use are
2639
2640     Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
2641     Retry-After: 120
2642
2643   In the latter example, the delay is 2 minutes.
2644
26459.9.  Server
2646
2647   The "Server" header field contains information about the software
2648   used by the origin server to handle the request.
2649
2650   The field can contain multiple product tokens (Section 5.2 of
2651   [Part1]) and comments (Section 3.2 of [Part1]) identifying the server
2652   and any significant subproducts.  The product tokens are listed in
2653   order of their significance for identifying the application.
2654
2655     Server = product *( RWS ( product / comment ) )
2656
2657   Example:
2658
2659     Server: CERN/3.0 libwww/2.17
2660
2661   If the response is being forwarded through a proxy, the proxy
2662   application MUST NOT modify the Server header field.  Instead, it
2663   MUST include a Via field (as described in Section 8.8 of [Part1]).
2664
2665      Note: Revealing the specific software version of the server might
2666      allow the server machine to become more vulnerable to attacks
2667      against software that is known to contain security holes.  Server
2668      implementors are encouraged to make this field a configurable
2669      option.
2670
26719.10.  User-Agent
2672
2673   The "User-Agent" header field contains information about the user
2674   agent originating the request.  User agents SHOULD include this field
2675   with requests.
2676
2677   Typically, it is used for statistical purposes, the tracing of
2678   protocol violations, and tailoring responses to avoid particular user
2679   agent limitations.
2680
2681   The field can contain multiple product tokens (Section 5.2 of
2682   [Part1]) and comments (Section 3.2 of [Part1]) identifying the agent
2683   and its significant subproducts.  By convention, the product tokens
2684
2685
2686
2687Fielding, et al.          Expires July 7, 2012                 [Page 48]
2688
2689Internet-Draft              HTTP/1.1, Part 2                January 2012
2690
2691
2692   are listed in order of their significance for identifying the
2693   application.
2694
2695   Because this field is usually sent on every request a user agent
2696   makes, implementations are encouraged not to include needlessly fine-
2697   grained detail, and to limit (or even prohibit) the addition of
2698   subproducts by third parties.  Overly long and detailed User-Agent
2699   field values make requests larger and can also be used to identify
2700   ("fingerprint") the user against their wishes.
2701
2702   Likewise, implementations are encouraged not to use the product
2703   tokens of other implementations in order to declare compatibility
2704   with them, as this circumvents the purpose of the field.  Finally,
2705   they are encouraged not to use comments to identify products; doing
2706   so makes the field value more difficult to parse.
2707
2708     User-Agent = product *( RWS ( product / comment ) )
2709
2710   Example:
2711
2712     User-Agent: CERN-LineMode/2.15 libwww/2.17b3
2713
271410.  IANA Considerations
2715
271610.1.  Method Registry
2717
2718   The registration procedure for HTTP request methods is defined by
2719   Section 2.2 of this document.
2720
2721   The HTTP Method Registry shall be created at
2722   <http://www.iana.org/assignments/http-methods> and be populated with
2723   the registrations below:
2724
2725   +---------+------+-------------+
2726   | Method  | Safe | Reference   |
2727   +---------+------+-------------+
2728   | CONNECT | no   | Section 6.9 |
2729   | DELETE  | no   | Section 6.7 |
2730   | GET     | yes  | Section 6.3 |
2731   | HEAD    | yes  | Section 6.4 |
2732   | OPTIONS | yes  | Section 6.2 |
2733   | POST    | no   | Section 6.5 |
2734   | PUT     | no   | Section 6.6 |
2735   | TRACE   | yes  | Section 6.8 |
2736   +---------+------+-------------+
2737
2738
2739
2740
2741
2742
2743Fielding, et al.          Expires July 7, 2012                 [Page 49]
2744
2745Internet-Draft              HTTP/1.1, Part 2                January 2012
2746
2747
274810.2.  Status Code Registry
2749
2750   The registration procedure for HTTP Status Codes -- previously
2751   defined in Section 7.1 of [RFC2817] -- is now defined by Section 4.2
2752   of this document.
2753
2754   The HTTP Status Code Registry located at
2755   <http://www.iana.org/assignments/http-status-codes> shall be updated
2756   with the registrations below:
2757
2758
2759
2760
2761
2762
2763
2764
2765
2766
2767
2768
2769
2770
2771
2772
2773
2774
2775
2776
2777
2778
2779
2780
2781
2782
2783
2784
2785
2786
2787
2788
2789
2790
2791
2792
2793
2794
2795
2796
2797
2798
2799Fielding, et al.          Expires July 7, 2012                 [Page 50]
2800
2801Internet-Draft              HTTP/1.1, Part 2                January 2012
2802
2803
2804   +-------+----------------------------------+----------------+
2805   | Value | Description                      | Reference      |
2806   +-------+----------------------------------+----------------+
2807   | 100   | Continue                         | Section 7.1.1  |
2808   | 101   | Switching Protocols              | Section 7.1.2  |
2809   | 200   | OK                               | Section 7.2.1  |
2810   | 201   | Created                          | Section 7.2.2  |
2811   | 202   | Accepted                         | Section 7.2.3  |
2812   | 203   | Non-Authoritative Information    | Section 7.2.4  |
2813   | 204   | No Content                       | Section 7.2.5  |
2814   | 205   | Reset Content                    | Section 7.2.6  |
2815   | 300   | Multiple Choices                 | Section 7.3.1  |
2816   | 301   | Moved Permanently                | Section 7.3.2  |
2817   | 302   | Found                            | Section 7.3.3  |
2818   | 303   | See Other                        | Section 7.3.4  |
2819   | 305   | Use Proxy                        | Section 7.3.6  |
2820   | 306   | (Unused)                         | Section 7.3.7  |
2821   | 307   | Temporary Redirect               | Section 7.3.8  |
2822   | 400   | Bad Request                      | Section 7.4.1  |
2823   | 402   | Payment Required                 | Section 7.4.3  |
2824   | 403   | Forbidden                        | Section 7.4.4  |
2825   | 404   | Not Found                        | Section 7.4.5  |
2826   | 405   | Method Not Allowed               | Section 7.4.6  |
2827   | 406   | Not Acceptable                   | Section 7.4.7  |
2828   | 407   | Proxy Authentication Required    | Section 7.4.8  |
2829   | 408   | Request Timeout                  | Section 7.4.9  |
2830   | 409   | Conflict                         | Section 7.4.10 |
2831   | 410   | Gone                             | Section 7.4.11 |
2832   | 411   | Length Required                  | Section 7.4.12 |
2833   | 413   | Request Representation Too Large | Section 7.4.14 |
2834   | 414   | URI Too Long                     | Section 7.4.15 |
2835   | 415   | Unsupported Media Type           | Section 7.4.16 |
2836   | 417   | Expectation Failed               | Section 7.4.18 |
2837   | 426   | Upgrade Required                 | Section 7.4.19 |
2838   | 500   | Internal Server Error            | Section 7.5.1  |
2839   | 501   | Not Implemented                  | Section 7.5.2  |
2840   | 502   | Bad Gateway                      | Section 7.5.3  |
2841   | 503   | Service Unavailable              | Section 7.5.4  |
2842   | 504   | Gateway Timeout                  | Section 7.5.5  |
2843   | 505   | HTTP Version Not Supported       | Section 7.5.6  |
2844   +-------+----------------------------------+----------------+
2845
284610.3.  Header Field Registration
2847
2848   The Message Header Field Registry located at <http://www.iana.org/
2849   assignments/message-headers/message-header-index.html> shall be
2850   updated with the permanent registrations below (see [RFC3864]):
2851
2852
2853
2854
2855Fielding, et al.          Expires July 7, 2012                 [Page 51]
2856
2857Internet-Draft              HTTP/1.1, Part 2                January 2012
2858
2859
2860   +-------------------+----------+----------+--------------+
2861   | Header Field Name | Protocol | Status   | Reference    |
2862   +-------------------+----------+----------+--------------+
2863   | Allow             | http     | standard | Section 9.1  |
2864   | Date              | http     | standard | Section 9.2  |
2865   | Expect            | http     | standard | Section 9.3  |
2866   | From              | http     | standard | Section 9.4  |
2867   | Location          | http     | standard | Section 9.5  |
2868   | Max-Forwards      | http     | standard | Section 9.6  |
2869   | Referer           | http     | standard | Section 9.7  |
2870   | Retry-After       | http     | standard | Section 9.8  |
2871   | Server            | http     | standard | Section 9.9  |
2872   | User-Agent        | http     | standard | Section 9.10 |
2873   +-------------------+----------+----------+--------------+
2874
2875   The change controller is: "IETF (iesg@ietf.org) - Internet
2876   Engineering Task Force".
2877
287811.  Security Considerations
2879
2880   This section is meant to inform application developers, information
2881   providers, and users of the security limitations in HTTP/1.1 as
2882   described by this document.  The discussion does not include
2883   definitive solutions to the problems revealed, though it does make
2884   some suggestions for reducing security risks.
2885
288611.1.  Transfer of Sensitive Information
2887
2888   Like any generic data transfer protocol, HTTP cannot regulate the
2889   content of the data that is transferred, nor is there any a priori
2890   method of determining the sensitivity of any particular piece of
2891   information within the context of any given request.  Therefore,
2892   applications SHOULD supply as much control over this information as
2893   possible to the provider of that information.  Four header fields are
2894   worth special mention in this context: Server, Via, Referer and From.
2895
2896   Revealing the specific software version of the server might allow the
2897   server machine to become more vulnerable to attacks against software
2898   that is known to contain security holes.  Implementors SHOULD make
2899   the Server header field a configurable option.
2900
2901   Proxies which serve as a portal through a network firewall SHOULD
2902   take special precautions regarding the transfer of header information
2903   that identifies the hosts behind the firewall.  In particular, they
2904   SHOULD remove, or replace with sanitized versions, any Via fields
2905   generated behind the firewall.
2906
2907   The Referer header field allows reading patterns to be studied and
2908
2909
2910
2911Fielding, et al.          Expires July 7, 2012                 [Page 52]
2912
2913Internet-Draft              HTTP/1.1, Part 2                January 2012
2914
2915
2916   reverse links drawn.  Although it can be very useful, its power can
2917   be abused if user details are not separated from the information
2918   contained in the Referer.  Even when the personal information has
2919   been removed, the Referer header field might indicate a private
2920   document's URI whose publication would be inappropriate.
2921
2922   The information sent in the From field might conflict with the user's
2923   privacy interests or their site's security policy, and hence it
2924   SHOULD NOT be transmitted without the user being able to disable,
2925   enable, and modify the contents of the field.  The user MUST be able
2926   to set the contents of this field within a user preference or
2927   application defaults configuration.
2928
2929   We suggest, though do not require, that a convenient toggle interface
2930   be provided for the user to enable or disable the sending of From and
2931   Referer information.
2932
2933   The User-Agent (Section 9.10) or Server (Section 9.9) header fields
2934   can sometimes be used to determine that a specific client or server
2935   have a particular security hole which might be exploited.
2936   Unfortunately, this same information is often used for other valuable
2937   purposes for which HTTP currently has no better mechanism.
2938
2939   Furthermore, the User-Agent header field may contain enough entropy
2940   to be used, possibly in conjunction with other material, to uniquely
2941   identify the user.
2942
2943   Some request methods, like TRACE (Section 6.8), expose information
2944   that was sent in request header fields within the body of their
2945   response.  Clients SHOULD be careful with sensitive information, like
2946   Cookies, Authorization credentials, and other header fields that
2947   might be used to collect data from the client.
2948
294911.2.  Encoding Sensitive Information in URIs
2950
2951   Because the source of a link might be private information or might
2952   reveal an otherwise private information source, it is strongly
2953   recommended that the user be able to select whether or not the
2954   Referer field is sent.  For example, a browser client could have a
2955   toggle switch for browsing openly/anonymously, which would
2956   respectively enable/disable the sending of Referer and From
2957   information.
2958
2959   Clients SHOULD NOT include a Referer header field in a (non-secure)
2960   HTTP request if the referring page was transferred with a secure
2961   protocol.
2962
2963   Authors of services SHOULD NOT use GET-based forms for the submission
2964
2965
2966
2967Fielding, et al.          Expires July 7, 2012                 [Page 53]
2968
2969Internet-Draft              HTTP/1.1, Part 2                January 2012
2970
2971
2972   of sensitive data because that data will be placed in the request-
2973   target.  Many existing servers, proxies, and user agents log or
2974   display the request-target in places where it might be visible to
2975   third parties.  Such services can use POST-based form submission
2976   instead.
2977
297811.3.  Location Headers and Spoofing
2979
2980   If a single server supports multiple organizations that do not trust
2981   one another, then it MUST check the values of Location and Content-
2982   Location header fields in responses that are generated under control
2983   of said organizations to make sure that they do not attempt to
2984   invalidate resources over which they have no authority.
2985
298611.4.  Security Considerations for CONNECT
2987
2988   Since tunneled data is opaque to the proxy, there are additional
2989   risks to tunneling to other well-known or reserved ports.  A HTTP
2990   client CONNECTing to port 25 could relay spam via SMTP, for example.
2991   As such, proxies SHOULD restrict CONNECT access to a small number of
2992   known ports.
2993
299412.  Acknowledgments
2995
2996   See Section 11 of [Part1].
2997
299813.  References
2999
300013.1.  Normative References
3001
3002   [Part1]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
3003              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
3004              and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,
3005              and Message Parsing", draft-ietf-httpbis-p1-messaging-18
3006              (work in progress), January 2012.
3007
3008   [Part3]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
3009              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
3010              and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload
3011              and Content Negotiation", draft-ietf-httpbis-p3-payload-18
3012              (work in progress), January 2012.
3013
3014   [Part4]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
3015              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
3016              and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional
3017              Requests", draft-ietf-httpbis-p4-conditional-18 (work in
3018              progress), January 2012.
3019
3020
3021
3022
3023Fielding, et al.          Expires July 7, 2012                 [Page 54]
3024
3025Internet-Draft              HTTP/1.1, Part 2                January 2012
3026
3027
3028   [Part5]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
3029              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
3030              and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and
3031              Partial Responses", draft-ietf-httpbis-p5-range-18 (work
3032              in progress), January 2012.
3033
3034   [Part6]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
3035              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
3036              Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part
3037              6: Caching", draft-ietf-httpbis-p6-cache-18 (work in
3038              progress), January 2012.
3039
3040   [Part7]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
3041              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
3042              and J. Reschke, Ed., "HTTP/1.1, part 7: Authentication",
3043              draft-ietf-httpbis-p7-auth-18 (work in progress),
3044              January 2012.
3045
3046   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
3047              Requirement Levels", BCP 14, RFC 2119, March 1997.
3048
3049   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
3050              Resource Identifier (URI): Generic Syntax", STD 66,
3051              RFC 3986, January 2005.
3052
3053   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
3054              Specifications: ABNF", STD 68, RFC 5234, January 2008.
3055
305613.2.  Informative References
3057
3058   [RFC1123]  Braden, R., "Requirements for Internet Hosts - Application
3059              and Support", STD 3, RFC 1123, October 1989.
3060
3061   [RFC1945]  Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext
3062              Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
3063
3064   [RFC2068]  Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.
3065              Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
3066              RFC 2068, January 1997.
3067
3068   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
3069              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
3070              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
3071
3072   [RFC2817]  Khare, R. and S. Lawrence, "Upgrading to TLS Within
3073              HTTP/1.1", RFC 2817, May 2000.
3074
3075   [RFC3864]  Klyne, G., Nottingham, M., and J. Mogul, "Registration
3076
3077
3078
3079Fielding, et al.          Expires July 7, 2012                 [Page 55]
3080
3081Internet-Draft              HTTP/1.1, Part 2                January 2012
3082
3083
3084              Procedures for Message Header Fields", BCP 90, RFC 3864,
3085              September 2004.
3086
3087   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
3088              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
3089              May 2008.
3090
3091   [RFC5322]  Resnick, P., "Internet Message Format", RFC 5322,
3092              October 2008.
3093
3094   [RFC5789]  Dusseault, L. and J. Snell, "PATCH Method for HTTP",
3095              RFC 5789, March 2010.
3096
3097   [RFC5987]  Reschke, J., "Character Set and Language Encoding for
3098              Hypertext Transfer Protocol (HTTP) Header Field
3099              Parameters", RFC 5987, August 2010.
3100
3101Appendix A.  Changes from RFC 2616
3102
3103   This document takes over the Status Code Registry, previously defined
3104   in Section 7.1 of [RFC2817].  (Section 4.2)
3105
3106   Clarify definition of POST.  (Section 6.5)
3107
3108   Remove requirement to handle all Content-* header fields; ban use of
3109   Content-Range with PUT.  (Section 6.6)
3110
3111   Take over definition of CONNECT method from [RFC2817].  (Section 6.9)
3112
3113   Broadened the definition of 203 (Non-Authoritative Information) to
3114   include cases of payload transformations as well.  (Section 7.2.4)
3115
3116   Failed to consider that there are many other request methods that are
3117   safe to automatically redirect, and further that the user agent is
3118   able to make that determination based on the request method
3119   semantics.  Furthermore, allow user agents to rewrite the method from
3120   POST to GET for status codes 301 and 302.  (Sections 7.3.2, 7.3.3 and
3121   7.3.8)
3122
3123   Deprecate 305 Use Proxy status code, because user agents did not
3124   implement it.  It used to indicate that the target resource must be
3125   accessed through the proxy given by the Location field.  The Location
3126   field gave the URI of the proxy.  The recipient was expected to
3127   repeat this single request via the proxy.  (Section 7.3.6)
3128
3129   Define status 426 (Upgrade Required) (this was incorporated from
3130   [RFC2817]).  (Section 7.4.19)
3131
3132
3133
3134
3135Fielding, et al.          Expires July 7, 2012                 [Page 56]
3136
3137Internet-Draft              HTTP/1.1, Part 2                January 2012
3138
3139
3140   Change ABNF productions for header fields to only define the field
3141   value.  (Section 9)
3142
3143   Reclassify "Allow" as response header field, removing the option to
3144   specify it in a PUT request.  Relax the server requirement on the
3145   contents of the Allow header field and remove requirement on clients
3146   to always trust the header field value.  (Section 9.1)
3147
3148   The ABNF for the Expect header field has been both fixed (allowing
3149   parameters for value-less expectations as well) and simplified
3150   (allowing trailing semicolons after "100-continue" when they were
3151   invalid before).  (Section 9.3)
3152
3153   Correct syntax of Location header field to allow URI references
3154   (including relative references and fragments), as referred symbol
3155   "absoluteURI" wasn't what was expected, and add some clarifications
3156   as to when use of fragments would not be appropriate.  (Section 9.5)
3157
3158   Restrict Max-Forwards header field to OPTIONS and TRACE (previously,
3159   extension methods could have used it as well).  (Section 9.6)
3160
3161   Allow Referer field value of "about:blank" as alternative to not
3162   specifying it.  (Section 9.7)
3163
3164   In the description of the Server header field, the Via field was
3165   described as a SHOULD.  The requirement was and is stated correctly
3166   in the description of the Via header field in Section 8.8 of [Part1].
3167   (Section 9.9)
3168
3169Appendix B.  Collected ABNF
3170
3171   Allow = [ ( "," / Method ) *( OWS "," [ OWS Method ] ) ]
3172
3173   BWS = <BWS, defined in [Part1], Section 1.2.2>
3174
3175   Date = HTTP-date
3176
3177   Expect = *( "," OWS ) expectation *( OWS "," [ OWS expectation ] )
3178
3179   From = mailbox
3180
3181   GMT = %x47.4D.54 ; GMT
3182
3183   HTTP-date = rfc1123-date / obs-date
3184
3185   Location = URI-reference
3186
3187   Max-Forwards = 1*DIGIT
3188
3189
3190
3191Fielding, et al.          Expires July 7, 2012                 [Page 57]
3192
3193Internet-Draft              HTTP/1.1, Part 2                January 2012
3194
3195
3196   Method = token
3197
3198   OWS = <OWS, defined in [Part1], Section 1.2.2>
3199
3200   RWS = <RWS, defined in [Part1], Section 1.2.2>
3201   Reason-Phrase = *( HTAB / SP / VCHAR / obs-text )
3202   Referer = absolute-URI / partial-URI
3203   Retry-After = HTTP-date / delta-seconds
3204
3205   Server = product *( RWS ( product / comment ) )
3206   Status-Code = 3DIGIT
3207
3208   URI-reference = <URI-reference, defined in [Part1], Section 2.7>
3209   User-Agent = product *( RWS ( product / comment ) )
3210
3211   absolute-URI = <absolute-URI, defined in [Part1], Section 2.7>
3212   asctime-date = day-name SP date3 SP time-of-day SP year
3213
3214   comment = <comment, defined in [Part1], Section 3.2>
3215
3216   date1 = day SP month SP year
3217   date2 = day "-" month "-" 2DIGIT
3218   date3 = month SP ( 2DIGIT / ( SP DIGIT ) )
3219   day = 2DIGIT
3220   day-name = %x4D.6F.6E ; Mon
3221    / %x54.75.65 ; Tue
3222    / %x57.65.64 ; Wed
3223    / %x54.68.75 ; Thu
3224    / %x46.72.69 ; Fri
3225    / %x53.61.74 ; Sat
3226    / %x53.75.6E ; Sun
3227   day-name-l = %x4D.6F.6E.64.61.79 ; Monday
3228    / %x54.75.65.73.64.61.79 ; Tuesday
3229    / %x57.65.64.6E.65.73.64.61.79 ; Wednesday
3230    / %x54.68.75.72.73.64.61.79 ; Thursday
3231    / %x46.72.69.64.61.79 ; Friday
3232    / %x53.61.74.75.72.64.61.79 ; Saturday
3233    / %x53.75.6E.64.61.79 ; Sunday
3234   delta-seconds = 1*DIGIT
3235
3236   expect-name = token
3237   expect-param = expect-name [ BWS "=" BWS expect-value ]
3238   expect-value = token / quoted-string
3239   expectation = expect-name [ BWS "=" BWS expect-value ] *( OWS ";" [
3240    OWS expect-param ] )
3241
3242   hour = 2DIGIT
3243
3244
3245
3246
3247Fielding, et al.          Expires July 7, 2012                 [Page 58]
3248
3249Internet-Draft              HTTP/1.1, Part 2                January 2012
3250
3251
3252   mailbox = <mailbox, defined in [RFC5322], Section 3.4>
3253   minute = 2DIGIT
3254   month = %x4A.61.6E ; Jan
3255    / %x46.65.62 ; Feb
3256    / %x4D.61.72 ; Mar
3257    / %x41.70.72 ; Apr
3258    / %x4D.61.79 ; May
3259    / %x4A.75.6E ; Jun
3260    / %x4A.75.6C ; Jul
3261    / %x41.75.67 ; Aug
3262    / %x53.65.70 ; Sep
3263    / %x4F.63.74 ; Oct
3264    / %x4E.6F.76 ; Nov
3265    / %x44.65.63 ; Dec
3266
3267   obs-date = rfc850-date / asctime-date
3268   obs-text = <obs-text, defined in [Part1], Section 1.2.2>
3269
3270   partial-URI = <partial-URI, defined in [Part1], Section 2.7>
3271   product = <product, defined in [Part1], Section 5.2>
3272
3273   quoted-string = <quoted-string, defined in [Part1], Section 3.2.3>
3274
3275   rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT
3276   rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT
3277
3278   second = 2DIGIT
3279
3280   time-of-day = hour ":" minute ":" second
3281   token = <token, defined in [Part1], Section 3.2.3>
3282
3283   year = 4DIGIT
3284
3285   ABNF diagnostics:
3286
3287   ; Allow defined but not used
3288   ; Date defined but not used
3289   ; Expect defined but not used
3290   ; From defined but not used
3291   ; Location defined but not used
3292   ; Max-Forwards defined but not used
3293   ; Reason-Phrase defined but not used
3294   ; Referer defined but not used
3295   ; Retry-After defined but not used
3296   ; Server defined but not used
3297   ; Status-Code defined but not used
3298   ; User-Agent defined but not used
3299
3300
3301
3302
3303Fielding, et al.          Expires July 7, 2012                 [Page 59]
3304
3305Internet-Draft              HTTP/1.1, Part 2                January 2012
3306
3307
3308Appendix C.  Change Log (to be removed by RFC Editor before publication)
3309
3310C.1.  Since RFC 2616
3311
3312   Extracted relevant partitions from [RFC2616].
3313
3314C.2.  Since draft-ietf-httpbis-p2-semantics-00
3315
3316   Closed issues:
3317
3318   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/5>: "Via is a MUST"
3319      (<http://purl.org/NET/http-errata#via-must>)
3320
3321   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/6>: "Fragments
3322      allowed in Location"
3323      (<http://purl.org/NET/http-errata#location-fragments>)
3324
3325   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/10>: "Safe Methods
3326      vs Redirection" (<http://purl.org/NET/http-errata#saferedirect>)
3327
3328   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/17>: "Revise
3329      description of the POST method"
3330      (<http://purl.org/NET/http-errata#post>)
3331
3332   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and
3333      Informative references"
3334
3335   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/42>: "RFC2606
3336      Compliance"
3337
3338   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/65>: "Informative
3339      references"
3340
3341   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/84>: "Redundant
3342      cross-references"
3343
3344   Other changes:
3345
3346   o  Move definitions of 304 and 412 condition codes to [Part4]
3347
3348C.3.  Since draft-ietf-httpbis-p2-semantics-01
3349
3350   Closed issues:
3351
3352   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/21>: "PUT side
3353      effects"
3354
3355
3356
3357
3358
3359Fielding, et al.          Expires July 7, 2012                 [Page 60]
3360
3361Internet-Draft              HTTP/1.1, Part 2                January 2012
3362
3363
3364   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/91>: "Duplicate Host
3365      header requirements"
3366
3367   Ongoing work on ABNF conversion
3368   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
3369
3370   o  Move "Product Tokens" section (back) into Part 1, as "token" is
3371      used in the definition of the Upgrade header field.
3372
3373   o  Add explicit references to BNF syntax and rules imported from
3374      other parts of the specification.
3375
3376   o  Copy definition of delta-seconds from Part6 instead of referencing
3377      it.
3378
3379C.4.  Since draft-ietf-httpbis-p2-semantics-02
3380
3381   Closed issues:
3382
3383   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/24>: "Requiring
3384      Allow in 405 responses"
3385
3386   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/59>: "Status Code
3387      Registry"
3388
3389   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/61>: "Redirection
3390      vs. Location"
3391
3392   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/70>: "Cacheability
3393      of 303 response"
3394
3395   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/76>: "305 Use Proxy"
3396
3397   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/105>:
3398      "Classification for Allow header"
3399
3400   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/112>: "PUT - 'store
3401      under' vs 'store at'"
3402
3403   Ongoing work on IANA Message Header Field Registration
3404   (<http://tools.ietf.org/wg/httpbis/trac/ticket/40>):
3405
3406   o  Reference RFC 3984, and update header field registrations for
3407      headers defined in this document.
3408
3409   Ongoing work on ABNF conversion
3410   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
3411
3412
3413
3414
3415Fielding, et al.          Expires July 7, 2012                 [Page 61]
3416
3417Internet-Draft              HTTP/1.1, Part 2                January 2012
3418
3419
3420   o  Replace string literals when the string really is case-sensitive
3421      (method).
3422
3423C.5.  Since draft-ietf-httpbis-p2-semantics-03
3424
3425   Closed issues:
3426
3427   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/98>: "OPTIONS
3428      request bodies"
3429
3430   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/119>: "Description
3431      of CONNECT should refer to RFC2817"
3432
3433   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/125>: "Location
3434      Content-Location reference request/response mixup"
3435
3436   Ongoing work on Method Registry
3437   (<http://tools.ietf.org/wg/httpbis/trac/ticket/72>):
3438
3439   o  Added initial proposal for registration process, plus initial
3440      content (non-HTTP/1.1 methods to be added by a separate
3441      specification).
3442
3443C.6.  Since draft-ietf-httpbis-p2-semantics-04
3444
3445   Closed issues:
3446
3447   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/103>: "Content-*"
3448
3449   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/132>: "RFC 2822 is
3450      updated by RFC 5322"
3451
3452   Ongoing work on ABNF conversion
3453   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
3454
3455   o  Use "/" instead of "|" for alternatives.
3456
3457   o  Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
3458      whitespace ("OWS") and required whitespace ("RWS").
3459
3460   o  Rewrite ABNFs to spell out whitespace rules, factor out header
3461      field value format definitions.
3462
3463C.7.  Since draft-ietf-httpbis-p2-semantics-05
3464
3465   Closed issues:
3466
3467
3468
3469
3470
3471Fielding, et al.          Expires July 7, 2012                 [Page 62]
3472
3473Internet-Draft              HTTP/1.1, Part 2                January 2012
3474
3475
3476   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/94>: "Reason-Phrase
3477      BNF"
3478
3479   Final work on ABNF conversion
3480   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
3481
3482   o  Add appendix containing collected and expanded ABNF, reorganize
3483      ABNF introduction.
3484
3485C.8.  Since draft-ietf-httpbis-p2-semantics-06
3486
3487   Closed issues:
3488
3489   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/144>: "Clarify when
3490      Referer is sent"
3491
3492   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/164>: "status codes
3493      vs methods"
3494
3495   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/170>: "Do not
3496      require "updates" relation for specs that register status codes or
3497      method names"
3498
3499C.9.  Since draft-ietf-httpbis-p2-semantics-07
3500
3501   Closed issues:
3502
3503   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/27>: "Idempotency"
3504
3505   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/33>: "TRACE security
3506      considerations"
3507
3508   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/110>: "Clarify rules
3509      for determining what entities a response carries"
3510
3511   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/140>: "update note
3512      citing RFC 1945 and 2068"
3513
3514   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/182>: "update note
3515      about redirect limit"
3516
3517   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/191>: "Location
3518      header ABNF should use 'URI'"
3519
3520   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/192>: "fragments in
3521      Location vs status 303"
3522
3523
3524
3525
3526
3527Fielding, et al.          Expires July 7, 2012                 [Page 63]
3528
3529Internet-Draft              HTTP/1.1, Part 2                January 2012
3530
3531
3532   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/198>: "move IANA
3533      registrations for optional status codes"
3534
3535   Partly resolved issues:
3536
3537   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/171>: "Are OPTIONS
3538      and TRACE safe?"
3539
3540C.10.  Since draft-ietf-httpbis-p2-semantics-08
3541
3542   Closed issues:
3543
3544   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/10>: "Safe Methods
3545      vs Redirection" (we missed the introduction to the 3xx status
3546      codes when fixing this previously)
3547
3548C.11.  Since draft-ietf-httpbis-p2-semantics-09
3549
3550   Closed issues:
3551
3552   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/43>: "Fragment
3553      combination / precedence during redirects"
3554
3555   Partly resolved issues:
3556
3557   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/185>: "Location
3558      header payload handling"
3559
3560   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/196>: "Term for the
3561      requested resource's URI"
3562
3563C.12.  Since draft-ietf-httpbis-p2-semantics-10
3564
3565   Closed issues:
3566
3567   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/69>: "Clarify
3568      'Requested Variant'"
3569
3570   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/109>: "Clarify
3571      entity / representation / variant terminology"
3572
3573   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/139>: "Methods and
3574      Caching"
3575
3576   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/190>: "OPTIONS vs
3577      Max-Forwards"
3578
3579
3580
3581
3582
3583Fielding, et al.          Expires July 7, 2012                 [Page 64]
3584
3585Internet-Draft              HTTP/1.1, Part 2                January 2012
3586
3587
3588   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/199>: "Status codes
3589      and caching"
3590
3591   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/220>: "consider
3592      removing the 'changes from 2068' sections"
3593
3594C.13.  Since draft-ietf-httpbis-p2-semantics-11
3595
3596   Closed issues:
3597
3598   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/229>:
3599      "Considerations for new status codes"
3600
3601   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/230>:
3602      "Considerations for new methods"
3603
3604   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/232>: "User-Agent
3605      guidelines" (relating to the 'User-Agent' header field)
3606
3607C.14.  Since draft-ietf-httpbis-p2-semantics-12
3608
3609   Closed issues:
3610
3611   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/43>: "Fragment
3612      combination / precedence during redirects" (added warning about
3613      having a fragid on the redirect may cause inconvenience in some
3614      cases)
3615
3616   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/79>: "Content-* vs.
3617      PUT"
3618
3619   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/88>: "205 Bodies"
3620
3621   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/102>: "Understanding
3622      Content-* on non-PUT requests"
3623
3624   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/103>: "Content-*"
3625
3626   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/104>: "Header type
3627      defaulting"
3628
3629   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/112>: "PUT - 'store
3630      under' vs 'store at'"
3631
3632   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/137>: "duplicate
3633      ABNF for Reason-Phrase"
3634
3635
3636
3637
3638
3639Fielding, et al.          Expires July 7, 2012                 [Page 65]
3640
3641Internet-Draft              HTTP/1.1, Part 2                January 2012
3642
3643
3644   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/180>: "Note special
3645      status of Content-* prefix in header registration procedures"
3646
3647   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/203>: "Max-Forwards
3648      vs extension methods"
3649
3650   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/213>: "What is the
3651      value space of HTTP status codes?" (actually fixed in
3652      draft-ietf-httpbis-p2-semantics-11)
3653
3654   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/224>: "Header
3655      Classification"
3656
3657   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/225>: "PUT side
3658      effect: invalidation or just stale?"
3659
3660   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/226>: "proxies not
3661      supporting certain methods"
3662
3663   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/239>: "Migrate
3664      CONNECT from RFC2817 to p2"
3665
3666   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/240>: "Migrate
3667      Upgrade details from RFC2817"
3668
3669   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/267>: "clarify PUT
3670      semantics'"
3671
3672   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/275>: "duplicate
3673      ABNF for 'Method'"
3674
3675   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle
3676      ABNFs for header fields"
3677
3678C.15.  Since draft-ietf-httpbis-p2-semantics-13
3679
3680   Closed issues:
3681
3682   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle
3683      ABNFs for header fields"
3684
3685   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/251>: "message-body
3686      in CONNECT request"
3687
3688
3689
3690
3691
3692
3693
3694
3695Fielding, et al.          Expires July 7, 2012                 [Page 66]
3696
3697Internet-Draft              HTTP/1.1, Part 2                January 2012
3698
3699
3700C.16.  Since draft-ietf-httpbis-p2-semantics-14
3701
3702   Closed issues:
3703
3704   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/255>: "Clarify
3705      status code for rate limiting"
3706
3707   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/294>: "clarify 403
3708      forbidden"
3709
3710   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/296>: "Clarify 203
3711      Non-Authoritative Information"
3712
3713   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/298>: "update
3714      default reason phrase for 413"
3715
3716C.17.  Since draft-ietf-httpbis-p2-semantics-15
3717
3718   Closed issues:
3719
3720   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/285>: "Strength of
3721      requirements on Accept re: 406"
3722
3723   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/303>: "400 response
3724      isn't generic"
3725
3726C.18.  Since draft-ietf-httpbis-p2-semantics-16
3727
3728   Closed issues:
3729
3730   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/160>: "Redirects and
3731      non-GET methods"
3732
3733   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/186>: "Document
3734      HTTP's error-handling philosophy"
3735
3736   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/231>:
3737      "Considerations for new headers"
3738
3739   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/310>: "clarify 303
3740      redirect on HEAD"
3741
3742C.19.  Since draft-ietf-httpbis-p2-semantics-17
3743
3744   Closed issues:
3745
3746   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/185>: "Location
3747      header payload handling"
3748
3749
3750
3751Fielding, et al.          Expires July 7, 2012                 [Page 67]
3752
3753Internet-Draft              HTTP/1.1, Part 2                January 2012
3754
3755
3756   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/255>: "Clarify
3757      status code for rate limiting" (change backed out because a new
3758      status code is being defined for this purpose)
3759
3760   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/312>: "should there
3761      be a permanent variant of 307"
3762
3763   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/325>: "When are
3764      Location's semantics triggered?"
3765
3766   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/327>: "'expect'
3767      grammar missing OWS"
3768
3769   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/329>: "header field
3770      considerations: quoted-string vs use of double quotes"
3771
3772Index
3773
3774   1
3775      100 Continue (status code)  26
3776      100-continue (expect value)  44
3777      101 Switching Protocols (status code)  26
3778
3779   2
3780      200 OK (status code)  27
3781      201 Created (status code)  27
3782      202 Accepted (status code)  28
3783      203 Non-Authoritative Information (status code)  28
3784      204 No Content (status code)  28
3785      205 Reset Content (status code)  29
3786      206 Partial Content (status code)  29
3787
3788   3
3789      300 Multiple Choices (status code)  30
3790      301 Moved Permanently (status code)  31
3791      302 Found (status code)  32
3792      303 See Other (status code)  32
3793      304 Not Modified (status code)  33
3794      305 Use Proxy (status code)  33
3795      306 (Unused) (status code)  33
3796      307 Temporary Redirect (status code)  33
3797
3798   4
3799      400 Bad Request (status code)  34
3800      401 Unauthorized (status code)  34
3801      402 Payment Required (status code)  34
3802      403 Forbidden (status code)  34
3803      404 Not Found (status code)  35
3804
3805
3806
3807Fielding, et al.          Expires July 7, 2012                 [Page 68]
3808
3809Internet-Draft              HTTP/1.1, Part 2                January 2012
3810
3811
3812      405 Method Not Allowed (status code)  35
3813      406 Not Acceptable (status code)  35
3814      407 Proxy Authentication Required (status code)  36
3815      408 Request Timeout (status code)  36
3816      409 Conflict (status code)  36
3817      410 Gone (status code)  36
3818      411 Length Required (status code)  37
3819      412 Precondition Failed (status code)  37
3820      413 Request Representation Too Large (status code)  37
3821      414 URI Too Long (status code)  37
3822      415 Unsupported Media Type (status code)  37
3823      416 Requested Range Not Satisfiable (status code)  38
3824      417 Expectation Failed (status code)  38
3825      426 Upgrade Required (status code)  38
3826
3827   5
3828      500 Internal Server Error (status code)  38
3829      501 Not Implemented (status code)  39
3830      502 Bad Gateway (status code)  39
3831      503 Service Unavailable (status code)  39
3832      504 Gateway Timeout (status code)  39
3833      505 HTTP Version Not Supported (status code)  39
3834
3835   A
3836      Allow header field  42
3837
3838   C
3839      CONNECT method  24
3840
3841   D
3842      Date header field  43
3843      DELETE method  23
3844
3845   E
3846      Expect header field  44
3847      Expect Values
3848         100-continue  44
3849
3850   F
3851      From header field  44
3852
3853   G
3854      GET method  19
3855      Grammar
3856         Allow  42
3857         asctime-date  42
3858         Date  43
3859         date1  41
3860
3861
3862
3863Fielding, et al.          Expires July 7, 2012                 [Page 69]
3864
3865Internet-Draft              HTTP/1.1, Part 2                January 2012
3866
3867
3868         day  41
3869         day-name  41
3870         day-name-l  41
3871         delta-seconds  47
3872         Expect  44
3873         expect-name  44
3874         expect-param  44
3875         expect-value  44
3876         expectation  44
3877         extension-code  13
3878         From  45
3879         GMT  41
3880         hour  41
3881         HTTP-date  40
3882         Location  45
3883         Max-Forwards  46
3884         Method  7
3885         minute  41
3886         month  41
3887         obs-date  41
3888         Reason-Phrase  13
3889         Referer  47
3890         Retry-After  47
3891         rfc850-date  42
3892         rfc1123-date  41
3893         second  41
3894         Server  48
3895         Status-Code  13
3896         time-of-day  41
3897         User-Agent  49
3898         year  41
3899
3900   H
3901      HEAD method  19
3902      Header Fields
3903         Allow  42
3904         Date  43
3905         Expect  44
3906         From  44
3907         Location  45
3908         Max-Forwards  46
3909         Referer  47
3910         Retry-After  47
3911         Server  48
3912         User-Agent  48
3913
3914   I
3915      Idempotent Methods  17
3916
3917
3918
3919Fielding, et al.          Expires July 7, 2012                 [Page 70]
3920
3921Internet-Draft              HTTP/1.1, Part 2                January 2012
3922
3923
3924   L
3925      Location header field  45
3926
3927   M
3928      Max-Forwards header field  46
3929      Methods
3930         CONNECT  24
3931         DELETE  23
3932         GET  19
3933         HEAD  19
3934         OPTIONS  18
3935         POST  20
3936         PUT  21
3937         TRACE  23
3938
3939   O
3940      OPTIONS method  18
3941
3942   P
3943      POST method  20
3944      PUT method  21
3945
3946   R
3947      Referer header field  47
3948      Retry-After header field  47
3949
3950   S
3951      Safe Methods  17
3952      Server header field  48
3953      Status Codes
3954         100 Continue  26
3955         101 Switching Protocols  26
3956         200 OK  27
3957         201 Created  27
3958         202 Accepted  28
3959         203 Non-Authoritative Information  28
3960         204 No Content  28
3961         205 Reset Content  29
3962         206 Partial Content  29
3963         300 Multiple Choices  30
3964         301 Moved Permanently  31
3965         302 Found  32
3966         303 See Other  32
3967         304 Not Modified  33
3968         305 Use Proxy  33
3969         306 (Unused)  33
3970         307 Temporary Redirect  33
3971         400 Bad Request  34
3972
3973
3974
3975Fielding, et al.          Expires July 7, 2012                 [Page 71]
3976
3977Internet-Draft              HTTP/1.1, Part 2                January 2012
3978
3979
3980         401 Unauthorized  34
3981         402 Payment Required  34
3982         403 Forbidden  34
3983         404 Not Found  35
3984         405 Method Not Allowed  35
3985         406 Not Acceptable  35
3986         407 Proxy Authentication Required  36
3987         408 Request Timeout  36
3988         409 Conflict  36
3989         410 Gone  36
3990         411 Length Required  37
3991         412 Precondition Failed  37
3992         413 Request Representation Too Large  37
3993         414 URI Too Long  37
3994         415 Unsupported Media Type  37
3995         416 Requested Range Not Satisfiable  38
3996         417 Expectation Failed  38
3997         426 Upgrade Required  38
3998         500 Internal Server Error  38
3999         501 Not Implemented  39
4000         502 Bad Gateway  39
4001         503 Service Unavailable  39
4002         504 Gateway Timeout  39
4003         505 HTTP Version Not Supported  39
4004
4005   T
4006      TRACE method  23
4007
4008   U
4009      User-Agent header field  48
4010
4011Authors' Addresses
4012
4013   Roy T. Fielding (editor)
4014   Adobe Systems Incorporated
4015   345 Park Ave
4016   San Jose, CA  95110
4017   USA
4018
4019   EMail: fielding@gbiv.com
4020   URI:   http://roy.gbiv.com/
4021
4022
4023
4024
4025
4026
4027
4028
4029
4030
4031Fielding, et al.          Expires July 7, 2012                 [Page 72]
4032
4033Internet-Draft              HTTP/1.1, Part 2                January 2012
4034
4035
4036   Jim Gettys
4037   Alcatel-Lucent Bell Labs
4038   21 Oak Knoll Road
4039   Carlisle, MA  01741
4040   USA
4041
4042   EMail: jg@freedesktop.org
4043   URI:   http://gettys.wordpress.com/
4044
4045
4046   Jeffrey C. Mogul
4047   Hewlett-Packard Company
4048   HP Labs, Large Scale Systems Group
4049   1501 Page Mill Road, MS 1177
4050   Palo Alto, CA  94304
4051   USA
4052
4053   EMail: JeffMogul@acm.org
4054
4055
4056   Henrik Frystyk Nielsen
4057   Microsoft Corporation
4058   1 Microsoft Way
4059   Redmond, WA  98052
4060   USA
4061
4062   EMail: henrikn@microsoft.com
4063
4064
4065   Larry Masinter
4066   Adobe Systems Incorporated
4067   345 Park Ave
4068   San Jose, CA  95110
4069   USA
4070
4071   EMail: LMM@acm.org
4072   URI:   http://larry.masinter.net/
4073
4074
4075   Paul J. Leach
4076   Microsoft Corporation
4077   1 Microsoft Way
4078   Redmond, WA  98052
4079
4080   EMail: paulle@microsoft.com
4081
4082
4083
4084
4085
4086
4087Fielding, et al.          Expires July 7, 2012                 [Page 73]
4088
4089Internet-Draft              HTTP/1.1, Part 2                January 2012
4090
4091
4092   Tim Berners-Lee
4093   World Wide Web Consortium
4094   MIT Computer Science and Artificial Intelligence Laboratory
4095   The Stata Center, Building 32
4096   32 Vassar Street
4097   Cambridge, MA  02139
4098   USA
4099
4100   EMail: timbl@w3.org
4101   URI:   http://www.w3.org/People/Berners-Lee/
4102
4103
4104   Yves Lafon (editor)
4105   World Wide Web Consortium
4106   W3C / ERCIM
4107   2004, rte des Lucioles
4108   Sophia-Antipolis, AM  06902
4109   France
4110
4111   EMail: ylafon@w3.org
4112   URI:   http://www.raubacapeu.net/people/yves/
4113
4114
4115   Julian F. Reschke (editor)
4116   greenbytes GmbH
4117   Hafenweg 16
4118   Muenster, NW  48155
4119   Germany
4120
4121   Phone: +49 251 2807760
4122   Fax:   +49 251 2807761
4123   EMail: julian.reschke@greenbytes.de
4124   URI:   http://greenbytes.de/tech/webdav/
4125
4126
4127
4128
4129
4130
4131
4132
4133
4134
4135
4136
4137
4138
4139
4140
4141
4142
4143Fielding, et al.          Expires July 7, 2012                 [Page 74]
4144
Note: See TracBrowser for help on using the repository browser.