source: draft-ietf-httpbis/14/draft-ietf-httpbis-p2-semantics-14.txt @ 1271

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

-14

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