source: draft-ietf-httpbis/15/draft-ietf-httpbis-p2-semantics-15.txt @ 1391

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

Prepare publication of -15 on 2011-07-11

  • Property svn:eol-style set to native
  • Property svn:executable set to *
File size: 134.8 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: January 12, 2012                                             HP
10                                                              H. Frystyk
11                                                               Microsoft
12                                                             L. Masinter
13                                                                   Adobe
14                                                                P. Leach
15                                                               Microsoft
16                                                          T. Berners-Lee
17                                                                 W3C/MIT
18                                                           Y. Lafon, Ed.
19                                                                     W3C
20                                                         J. Reschke, Ed.
21                                                              greenbytes
22                                                           July 11, 2011
23
24
25                  HTTP/1.1, part 2: Message Semantics
26                   draft-ietf-httpbis-p2-semantics-15
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.16.
52
53
54
55Fielding, et al.        Expires January 12, 2012                [Page 1]
56
57Internet-Draft              HTTP/1.1, Part 2                   July 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 January 12, 2012.
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 January 12, 2012                [Page 2]
112
113Internet-Draft              HTTP/1.1, Part 2                   July 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 January 12, 2012                [Page 3]
168
169Internet-Draft              HTTP/1.1, Part 2                   July 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 Representation Too Large . . . . . . . . . 33
190       8.4.15. 414 URI Too Long . . . . . . . . . . . . . . . . . . . 33
191       8.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . . 34
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  . . . . . . . . . . . . . . 35
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 . . . . . . . . . . . . 36
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  . . . . . . . . . . . . . . . . . . . . . 42
213     10.1. Method Registry  . . . . . . . . . . . . . . . . . . . . . 42
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 January 12, 2012                [Page 4]
224
225Internet-Draft              HTTP/1.1, Part 2                   July 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     C.16. Since draft-ietf-httpbis-p2-semantics-14 . . . . . . . . . 58
253   Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
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 January 12, 2012                [Page 5]
280
281Internet-Draft              HTTP/1.1, Part 2                   July 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 January 12, 2012                [Page 6]
336
337Internet-Draft              HTTP/1.1, Part 2                   July 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.7>
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.7>
361     product       = <product, defined in [Part1], Section 6.3>
362     URI-reference = <URI-reference, defined in [Part1], Section 2.7>
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 January 12, 2012                [Page 7]
392
393Internet-Draft              HTTP/1.1, Part 2                   July 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 January 12, 2012                [Page 8]
448
449Internet-Draft              HTTP/1.1, Part 2                   July 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 January 12, 2012                [Page 9]
504
505Internet-Draft              HTTP/1.1, Part 2                   July 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 January 12, 2012               [Page 10]
560
561Internet-Draft              HTTP/1.1, Part 2                   July 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 Representation Too   | Section 8.4.14       |
603   |             | Large                        |                      |
604   | 414         | URI Too Long                 | Section 8.4.15       |
605   | 415         | Unsupported Media Type       | Section 8.4.16       |
606   | 416         | Requested range not          | Section 3.2 of       |
607   |             | satisfiable                  | [Part5]              |
608   | 417         | Expectation Failed           | Section 8.4.18       |
609   | 426         | Upgrade Required             | Section 8.4.19       |
610   | 500         | Internal Server Error        | Section 8.5.1        |
611   | 501         | Not Implemented              | Section 8.5.2        |
612
613
614
615Fielding, et al.        Expires January 12, 2012               [Page 11]
616
617Internet-Draft              HTTP/1.1, Part 2                   July 2011
618
619
620   | 502         | Bad Gateway                  | Section 8.5.3        |
621   | 503         | Service Unavailable          | Section 8.5.4        |
622   | 504         | Gateway Time-out             | Section 8.5.5        |
623   | 505         | HTTP Version not supported   | Section 8.5.6        |
624   +-------------+------------------------------+----------------------+
625
626   Note that this list is not exhaustive -- it does not include
627   extension status codes defined in other specifications.
628
6294.2.  Status Code Registry
630
631   The HTTP Status Code Registry defines the name space for the Status-
632   Code token in the Status-Line of an HTTP response.
633
634   Values to be added to this name space are subject to IETF review
635   ([RFC5226], Section 4.1).
636
637   The registry itself is maintained at
638   <http://www.iana.org/assignments/http-status-codes>.
639
6404.2.1.  Considerations for New Status Codes
641
642   When it is necessary to express new semantics for a HTTP response
643   that aren't specific to a single application or media type, and
644   currently defined status codes are inadequate, a new status code can
645   be registered.
646
647   HTTP status codes are generic; that is, they are potentially
648   applicable to any resource, not just one particular media type,
649   "type" of resource, or application.  As such, it is preferred that
650   new HTTP status codes be registered in a document that isn't specific
651   to a single application, so that this is clear.
652
653   Definitions of new HTTP status codes typically explain the request
654   conditions that produce a response containing the status code (e.g.,
655   combinations of request headers and/or method(s)), along with any
656   interactions with response headers (e.g., those that are required,
657   those that modify the semantics of the response).
658
659   New HTTP status codes are required to fall under one of the
660   categories defined in Section 8.  To allow existing parsers to
661   properly handle them, new status codes cannot disallow a response
662   body, although they can mandate a zero-length response body.  They
663   can require the presence of one or more particular HTTP response
664   header(s).
665
666   Likewise, their definitions can specify that caches are allowed to
667   use heuristics to determine their freshness (see [Part6]; by default,
668
669
670
671Fielding, et al.        Expires January 12, 2012               [Page 12]
672
673Internet-Draft              HTTP/1.1, Part 2                   July 2011
674
675
676   it is not allowed), and can define how to determine the resource
677   which they carry a representation for (see Section 6.1; by default,
678   it is anonymous).
679
6805.  Response Header Fields
681
682   The response header fields allow the server to pass additional
683   information about the response which cannot be placed in the Status-
684   Line.  These header fields give information about the server and
685   about further access to the target resource (Section 4.3 of [Part1]).
686
687   +--------------------+------------------------+
688   | Header Field Name  | Defined in...          |
689   +--------------------+------------------------+
690   | Accept-Ranges      | Section 5.1 of [Part5] |
691   | Age                | Section 3.1 of [Part6] |
692   | Allow              | Section 9.1            |
693   | ETag               | Section 2.2 of [Part4] |
694   | Location           | Section 9.4            |
695   | Proxy-Authenticate | Section 4.2 of [Part7] |
696   | Retry-After        | Section 9.7            |
697   | Server             | Section 9.8            |
698   | Vary               | Section 3.5 of [Part6] |
699   | WWW-Authenticate   | Section 4.4 of [Part7] |
700   +--------------------+------------------------+
701
7026.  Representation
703
704   Request and Response messages MAY transfer a representation if not
705   otherwise restricted by the request method or response status code.
706   A representation consists of metadata (representation header fields)
707   and data (representation body).  When a complete or partial
708   representation is enclosed in an HTTP message, it is referred to as
709   the payload of the message.  HTTP representations are defined in
710   [Part3].
711
712   A representation body is only present in a message when a message-
713   body is present, as described in Section 3.3 of [Part1].  The
714   representation body is obtained from the message-body by decoding any
715   Transfer-Encoding that might have been applied to ensure safe and
716   proper transfer of the message.
717
7186.1.  Identifying the Resource Associated with a Representation
719
720   It is sometimes necessary to determine an identifier for the resource
721   associated with a representation.
722
723   An HTTP request representation, when present, is always associated
724
725
726
727Fielding, et al.        Expires January 12, 2012               [Page 13]
728
729Internet-Draft              HTTP/1.1, Part 2                   July 2011
730
731
732   with an anonymous (i.e., unidentified) resource.
733
734   In the common case, an HTTP response is a representation of the
735   target resource (see Section 4.3 of [Part1]).  However, this is not
736   always the case.  To determine the URI of the resource a response is
737   associated with, the following rules are used (with the first
738   applicable one being selected):
739
740   1.  If the response status code is 200 or 203 and the request method
741       was GET, the response payload is a representation of the target
742       resource.
743
744   2.  If the response status code is 204, 206, or 304 and the request
745       method was GET or HEAD, the response payload is a partial
746       representation of the target resource (see Section 2.8 of
747       [Part6]).
748
749   3.  If the response has a Content-Location header field, and that URI
750       is the same as the effective request URI, the response payload is
751       a representation of the target resource.
752
753   4.  If the response has a Content-Location header field, and that URI
754       is not the same as the effective request URI, then the response
755       asserts that its payload is a representation of the resource
756       identified by the Content-Location URI.  However, such an
757       assertion cannot be trusted unless it can be verified by other
758       means (not defined by HTTP).
759
760   5.  Otherwise, the response is a representation of an anonymous
761       (i.e., unidentified) resource.
762
763   [[TODO-req-uri: The comparison function is going to have to be
764   defined somewhere, because we already need to compare URIs for things
765   like cache invalidation.]]
766
7677.  Method Definitions
768
769   The set of common request methods for HTTP/1.1 is defined below.
770   Although this set can be expanded, additional methods cannot be
771   assumed to share the same semantics for separately extended clients
772   and servers.
773
7747.1.  Safe and Idempotent Methods
775
7767.1.1.  Safe Methods
777
778   Implementors need to be aware that the software represents the user
779   in their interactions over the Internet, and need to allow the user
780
781
782
783Fielding, et al.        Expires January 12, 2012               [Page 14]
784
785Internet-Draft              HTTP/1.1, Part 2                   July 2011
786
787
788   to be aware of any actions they take which might have an unexpected
789   significance to themselves or others.
790
791   In particular, the convention has been established that the GET,
792   HEAD, OPTIONS, and TRACE request methods SHOULD NOT have the
793   significance of taking an action other than retrieval.  These request
794   methods ought to be considered "safe".  This allows user agents to
795   represent other methods, such as POST, PUT and DELETE, in a special
796   way, so that the user is made aware of the fact that a possibly
797   unsafe action is being requested.
798
799   Naturally, it is not possible to ensure that the server does not
800   generate side-effects as a result of performing a GET request; in
801   fact, some dynamic resources consider that a feature.  The important
802   distinction here is that the user did not request the side-effects,
803   so therefore cannot be held accountable for them.
804
8057.1.2.  Idempotent Methods
806
807   Request methods can also have the property of "idempotence" in that,
808   aside from error or expiration issues, the intended effect of
809   multiple identical requests is the same as for a single request.
810   PUT, DELETE, and all safe request methods are idempotent.  It is
811   important to note that idempotence refers only to changes requested
812   by the client: a server is free to change its state due to multiple
813   requests for the purpose of tracking those requests, versioning of
814   results, etc.
815
8167.2.  OPTIONS
817
818   The OPTIONS method requests information about the communication
819   options available on the request/response chain identified by the
820   effective request URI.  This method allows a client to determine the
821   options and/or requirements associated with a resource, or the
822   capabilities of a server, without implying a resource action or
823   initiating a resource retrieval.
824
825   Responses to the OPTIONS method are not cacheable.
826
827   If the OPTIONS request includes a message-body (as indicated by the
828   presence of Content-Length or Transfer-Encoding), then the media type
829   MUST be indicated by a Content-Type field.  Although this
830   specification does not define any use for such a body, future
831   extensions to HTTP might use the OPTIONS body to make more detailed
832   queries on the server.
833
834   If the request-target is an asterisk ("*"), the OPTIONS request is
835   intended to apply to the server in general rather than to a specific
836
837
838
839Fielding, et al.        Expires January 12, 2012               [Page 15]
840
841Internet-Draft              HTTP/1.1, Part 2                   July 2011
842
843
844   resource.  Since a server's communication options typically depend on
845   the resource, the "*" request is only useful as a "ping" or "no-op"
846   type of method; it does nothing beyond allowing the client to test
847   the capabilities of the server.  For example, this can be used to
848   test a proxy for HTTP/1.1 compliance (or lack thereof).
849
850   If the request-target is not an asterisk, the OPTIONS request applies
851   only to the options that are available when communicating with that
852   resource.
853
854   A 200 response SHOULD include any header fields that indicate
855   optional features implemented by the server and applicable to that
856   resource (e.g., Allow), possibly including extensions not defined by
857   this specification.  The response body, if any, SHOULD also include
858   information about the communication options.  The format for such a
859   body is not defined by this specification, but might be defined by
860   future extensions to HTTP.  Content negotiation MAY be used to select
861   the appropriate response format.  If no response body is included,
862   the response MUST include a Content-Length field with a field-value
863   of "0".
864
865   The Max-Forwards header field MAY be used to target a specific proxy
866   in the request chain (see Section 9.5).  If no Max-Forwards field is
867   present in the request, then the forwarded request MUST NOT include a
868   Max-Forwards field.
869
8707.3.  GET
871
872   The GET method requests transfer of a current representation of the
873   target resource.
874
875   If the target resource is a data-producing process, it is the
876   produced data which shall be returned as the representation in the
877   response and not the source text of the process, unless that text
878   happens to be the output of the process.
879
880   The semantics of the GET method change to a "conditional GET" if the
881   request message includes an If-Modified-Since, If-Unmodified-Since,
882   If-Match, If-None-Match, or If-Range header field.  A conditional GET
883   requests that the representation be transferred only under the
884   circumstances described by the conditional header field(s).  The
885   conditional GET request is intended to reduce unnecessary network
886   usage by allowing cached representations to be refreshed without
887   requiring multiple requests or transferring data already held by the
888   client.
889
890   The semantics of the GET method change to a "partial GET" if the
891   request message includes a Range header field.  A partial GET
892
893
894
895Fielding, et al.        Expires January 12, 2012               [Page 16]
896
897Internet-Draft              HTTP/1.1, Part 2                   July 2011
898
899
900   requests that only part of the representation be transferred, as
901   described in Section 5.4 of [Part5].  The partial GET request is
902   intended to reduce unnecessary network usage by allowing partially-
903   retrieved representations to be completed without transferring data
904   already held by the client.
905
906   Bodies on GET requests have no defined semantics.  Note that sending
907   a body on a GET request might cause some existing implementations to
908   reject the request.
909
910   The response to a GET request is cacheable and MAY be used to satisfy
911   subsequent GET and HEAD requests (see [Part6]).
912
913   See Section 11.2 for security considerations when used for forms.
914
9157.4.  HEAD
916
917   The HEAD method is identical to GET except that the server MUST NOT
918   return a message-body in the response.  The metadata contained in the
919   HTTP header fields in response to a HEAD request SHOULD be identical
920   to the information sent in response to a GET request.  This method
921   can be used for obtaining metadata about the representation implied
922   by the request without transferring the representation body.  This
923   method is often used for testing hypertext links for validity,
924   accessibility, and recent modification.
925
926   The response to a HEAD request is cacheable and MAY be used to
927   satisfy a subsequent HEAD request; see [Part6].  It also MAY be used
928   to update a previously cached representation from that resource; if
929   the new field values indicate that the cached representation differs
930   from the current representation (as would be indicated by a change in
931   Content-Length, Content-MD5, ETag or Last-Modified), then the cache
932   MUST treat the cache entry as stale.
933
934   Bodies on HEAD requests have no defined semantics.  Note that sending
935   a body on a HEAD request might cause some existing implementations to
936   reject the request.
937
9387.5.  POST
939
940   The POST method requests that the origin server accept the
941   representation enclosed in the request as data to be processed by the
942   target resource.  POST is designed to allow a uniform method to cover
943   the following functions:
944
945   o  Annotation of existing resources;
946
947
948
949
950
951Fielding, et al.        Expires January 12, 2012               [Page 17]
952
953Internet-Draft              HTTP/1.1, Part 2                   July 2011
954
955
956   o  Posting a message to a bulletin board, newsgroup, mailing list, or
957      similar group of articles;
958
959   o  Providing a block of data, such as the result of submitting a
960      form, to a data-handling process;
961
962   o  Extending a database through an append operation.
963
964   The actual function performed by the POST method is determined by the
965   server and is usually dependent on the effective request URI.
966
967   The action performed by the POST method might not result in a
968   resource that can be identified by a URI.  In this case, either 200
969   (OK) or 204 (No Content) is the appropriate response status code,
970   depending on whether or not the response includes a representation
971   that describes the result.
972
973   If a resource has been created on the origin server, the response
974   SHOULD be 201 (Created) and contain a representation which describes
975   the status of the request and refers to the new resource, and a
976   Location header field (see Section 9.4).
977
978   Responses to POST requests are only cacheable when they include
979   explicit freshness information (see Section 2.3.1 of [Part6]).  A
980   cached POST response with a Content-Location header field (see
981   Section 6.7 of [Part3]) whose value is the effective Request URI MAY
982   be used to satisfy subsequent GET and HEAD requests.
983
984   Note that POST caching is not widely implemented.  However, the 303
985   (See Other) response can be used to direct the user agent to retrieve
986   a cacheable resource.
987
9887.6.  PUT
989
990   The PUT method requests that the state of the target resource be
991   created or replaced with the state defined by the representation
992   enclosed in the request message payload.  A successful PUT of a given
993   representation would suggest that a subsequent GET on that same
994   target resource will result in an equivalent representation being
995   returned in a 200 (OK) response.  However, there is no guarantee that
996   such a state change will be observable, since the target resource
997   might be acted upon by other user agents in parallel, or might be
998   subject to dynamic processing by the origin server, before any
999   subsequent GET is received.  A successful response only implies that
1000   the user agent's intent was achieved at the time of its processing by
1001   the origin server.
1002
1003   If the target resource does not have a current representation and the
1004
1005
1006
1007Fielding, et al.        Expires January 12, 2012               [Page 18]
1008
1009Internet-Draft              HTTP/1.1, Part 2                   July 2011
1010
1011
1012   PUT successfully creates one, then the origin server MUST inform the
1013   user agent by sending a 201 (Created) response.  If the target
1014   resource does have a current representation and that representation
1015   is successfully modified in accordance with the state of the enclosed
1016   representation, then either a 200 (OK) or 204 (No Content) response
1017   SHOULD be sent to indicate successful completion of the request.
1018
1019   Unrecognized header fields SHOULD be ignored (i.e., not saved as part
1020   of the resource state).
1021
1022   An origin server SHOULD verify that the PUT representation is
1023   consistent with any constraints which the server has for the target
1024   resource that cannot or will not be changed by the PUT.  This is
1025   particularly important when the origin server uses internal
1026   configuration information related to the URI in order to set the
1027   values for representation metadata on GET responses.  When a PUT
1028   representation is inconsistent with the target resource, the origin
1029   server SHOULD either make them consistent, by transforming the
1030   representation or changing the resource configuration, or respond
1031   with an appropriate error message containing sufficient information
1032   to explain why the representation is unsuitable.  The 409 (Conflict)
1033   or 415 (Unsupported Media Type) status codes are suggested, with the
1034   latter being specific to constraints on Content-Type values.
1035
1036   For example, if the target resource is configured to always have a
1037   Content-Type of "text/html" and the representation being PUT has a
1038   Content-Type of "image/jpeg", then the origin server SHOULD do one
1039   of: (a) reconfigure the target resource to reflect the new media
1040   type; (b) transform the PUT representation to a format consistent
1041   with that of the resource before saving it as the new resource state;
1042   or, (c) reject the request with a 415 response indicating that the
1043   target resource is limited to "text/html", perhaps including a link
1044   to a different resource that would be a suitable target for the new
1045   representation.
1046
1047   HTTP does not define exactly how a PUT method affects the state of an
1048   origin server beyond what can be expressed by the intent of the user
1049   agent request and the semantics of the origin server response.  It
1050   does not define what a resource might be, in any sense of that word,
1051   beyond the interface provided via HTTP.  It does not define how
1052   resource state is "stored", nor how such storage might change as a
1053   result of a change in resource state, nor how the origin server
1054   translates resource state into representations.  Generally speaking,
1055   all implementation details behind the resource interface are
1056   intentionally hidden by the server.
1057
1058   The fundamental difference between the POST and PUT methods is
1059   highlighted by the different intent for the target resource.  The
1060
1061
1062
1063Fielding, et al.        Expires January 12, 2012               [Page 19]
1064
1065Internet-Draft              HTTP/1.1, Part 2                   July 2011
1066
1067
1068   target resource in a POST request is intended to handle the enclosed
1069   representation as a data-accepting process, such as for a gateway to
1070   some other protocol or a document that accepts annotations.  In
1071   contrast, the target resource in a PUT request is intended to take
1072   the enclosed representation as a new or replacement value.  Hence,
1073   the intent of PUT is idempotent and visible to intermediaries, even
1074   though the exact effect is only known by the origin server.
1075
1076   Proper interpretation of a PUT request presumes that the user agent
1077   knows what target resource is desired.  A service that is intended to
1078   select a proper URI on behalf of the client, after receiving a state-
1079   changing request, SHOULD be implemented using the POST method rather
1080   than PUT.  If the origin server will not make the requested PUT state
1081   change to the target resource and instead wishes to have it applied
1082   to a different resource, such as when the resource has been moved to
1083   a different URI, then the origin server MUST send a 301 (Moved
1084   Permanently) response; the user agent MAY then make its own decision
1085   regarding whether or not to redirect the request.
1086
1087   A PUT request applied to the target resource MAY have side-effects on
1088   other resources.  For example, an article might have a URI for
1089   identifying "the current version" (a resource) which is separate from
1090   the URIs identifying each particular version (different resources
1091   that at one point shared the same state as the current version
1092   resource).  A successful PUT request on "the current version" URI
1093   might therefore create a new version resource in addition to changing
1094   the state of the target resource, and might also cause links to be
1095   added between the related resources.
1096
1097   An origin server SHOULD reject any PUT request that contains a
1098   Content-Range header field, since it might be misinterpreted as
1099   partial content (or might be partial content that is being mistakenly
1100   PUT as a full representation).  Partial content updates are possible
1101   by targeting a separately identified resource with state that
1102   overlaps a portion of the larger resource, or by using a different
1103   method that has been specifically defined for partial updates (for
1104   example, the PATCH method defined in [RFC5789]).
1105
1106   Responses to the PUT method are not cacheable.  If a PUT request
1107   passes through a cache that has one or more stored responses for the
1108   effective request URI, those stored responses will be invalidated
1109   (see Section 2.5 of [Part6]).
1110
11117.7.  DELETE
1112
1113   The DELETE method requests that the origin server delete the target
1114   resource.  This method MAY be overridden by human intervention (or
1115   other means) on the origin server.  The client cannot be guaranteed
1116
1117
1118
1119Fielding, et al.        Expires January 12, 2012               [Page 20]
1120
1121Internet-Draft              HTTP/1.1, Part 2                   July 2011
1122
1123
1124   that the operation has been carried out, even if the status code
1125   returned from the origin server indicates that the action has been
1126   completed successfully.  However, the server SHOULD NOT indicate
1127   success unless, at the time the response is given, it intends to
1128   delete the resource or move it to an inaccessible location.
1129
1130   A successful response SHOULD be 200 (OK) if the response includes an
1131   representation describing the status, 202 (Accepted) if the action
1132   has not yet been enacted, or 204 (No Content) if the action has been
1133   enacted but the response does not include a representation.
1134
1135   Bodies on DELETE requests have no defined semantics.  Note that
1136   sending a body on a DELETE request might cause some existing
1137   implementations to reject the request.
1138
1139   Responses to the DELETE method are not cacheable.  If a DELETE
1140   request passes through a cache that has one or more stored responses
1141   for the effective request URI, those stored responses will be
1142   invalidated (see Section 2.5 of [Part6]).
1143
11447.8.  TRACE
1145
1146   The TRACE method requests a remote, application-layer loop-back of
1147   the request message.  The final recipient of the request SHOULD
1148   reflect the message received back to the client as the message-body
1149   of a 200 (OK) response.  The final recipient is either the origin
1150   server or the first proxy to receive a Max-Forwards value of zero (0)
1151   in the request (see Section 9.5).  A TRACE request MUST NOT include a
1152   message-body.
1153
1154   TRACE allows the client to see what is being received at the other
1155   end of the request chain and use that data for testing or diagnostic
1156   information.  The value of the Via header field (Section 9.9 of
1157   [Part1]) is of particular interest, since it acts as a trace of the
1158   request chain.  Use of the Max-Forwards header field allows the
1159   client to limit the length of the request chain, which is useful for
1160   testing a chain of proxies forwarding messages in an infinite loop.
1161
1162   If the request is valid, the response SHOULD have a Content-Type of
1163   "message/http" (see Section 10.3.1 of [Part1]) and contain a message-
1164   body that encloses a copy of the entire request message.  Responses
1165   to the TRACE method are not cacheable.
1166
11677.9.  CONNECT
1168
1169   The CONNECT method requests that the proxy establish a tunnel to the
1170   request-target and then restrict its behavior to blind forwarding of
1171   packets until the connection is closed.
1172
1173
1174
1175Fielding, et al.        Expires January 12, 2012               [Page 21]
1176
1177Internet-Draft              HTTP/1.1, Part 2                   July 2011
1178
1179
1180   When using CONNECT, the request-target MUST use the authority form
1181   (Section 4.1.2 of [Part1]); i.e., the request-target consists of only
1182   the host name and port number of the tunnel destination, separated by
1183   a colon.  For example,
1184
1185     CONNECT server.example.com:80 HTTP/1.1
1186     Host: server.example.com:80
1187
1188
1189   Other HTTP mechanisms can be used normally with the CONNECT method --
1190   except end-to-end protocol Upgrade requests, since the tunnel must be
1191   established first.
1192
1193   For example, proxy authentication might be used to establish the
1194   authority to create a tunnel:
1195
1196     CONNECT server.example.com:80 HTTP/1.1
1197     Host: server.example.com:80
1198     Proxy-Authorization: basic aGVsbG86d29ybGQ=
1199
1200
1201   Bodies on CONNECT requests have no defined semantics.  Note that
1202   sending a body on a CONNECT request might cause some existing
1203   implementations to reject the request.
1204
1205   Like any other pipelined HTTP/1.1 request, data to be tunnel may be
1206   sent immediately after the blank line.  The usual caveats also apply:
1207   data may be discarded if the eventual response is negative, and the
1208   connection may be reset with no response if more than one TCP segment
1209   is outstanding.
1210
12117.9.1.  Establishing a Tunnel with CONNECT
1212
1213   Any successful (2xx) response to a CONNECT request indicates that the
1214   proxy has established a connection to the requested host and port,
1215   and has switched to tunneling the current connection to that server
1216   connection.
1217
1218   It may be the case that the proxy itself can only reach the requested
1219   origin server through another proxy.  In this case, the first proxy
1220   SHOULD make a CONNECT request of that next proxy, requesting a tunnel
1221   to the authority.  A proxy MUST NOT respond with any 2xx status code
1222   unless it has either a direct or tunnel connection established to the
1223   authority.
1224
1225   An origin server which receives a CONNECT request for itself MAY
1226   respond with a 2xx status code to indicate that a connection is
1227   established.
1228
1229
1230
1231Fielding, et al.        Expires January 12, 2012               [Page 22]
1232
1233Internet-Draft              HTTP/1.1, Part 2                   July 2011
1234
1235
1236   If at any point either one of the peers gets disconnected, any
1237   outstanding data that came from that peer will be passed to the other
1238   one, and after that also the other connection will be terminated by
1239   the proxy.  If there is outstanding data to that peer undelivered,
1240   that data will be discarded.
1241
12428.  Status Code Definitions
1243
1244   Each Status-Code is described below, including any metadata required
1245   in the response.
1246
12478.1.  Informational 1xx
1248
1249   This class of status code indicates a provisional response,
1250   consisting only of the Status-Line and optional header fields, and is
1251   terminated by an empty line.  There are no required header fields for
1252   this class of status code.  Since HTTP/1.0 did not define any 1xx
1253   status codes, servers MUST NOT send a 1xx response to an HTTP/1.0
1254   client except under experimental conditions.
1255
1256   A client MUST be prepared to accept one or more 1xx status responses
1257   prior to a regular response, even if the client does not expect a 100
1258   (Continue) status message.  Unexpected 1xx status responses MAY be
1259   ignored by a user agent.
1260
1261   Proxies MUST forward 1xx responses, unless the connection between the
1262   proxy and its client has been closed, or unless the proxy itself
1263   requested the generation of the 1xx response.  (For example, if a
1264   proxy adds a "Expect: 100-continue" field when it forwards a request,
1265   then it need not forward the corresponding 100 (Continue)
1266   response(s).)
1267
12688.1.1.  100 Continue
1269
1270   The client SHOULD continue with its request.  This interim response
1271   is used to inform the client that the initial part of the request has
1272   been received and has not yet been rejected by the server.  The
1273   client SHOULD continue by sending the remainder of the request or, if
1274   the request has already been completed, ignore this response.  The
1275   server MUST send a final response after the request has been
1276   completed.  See Section 7.2.3 of [Part1] for detailed discussion of
1277   the use and handling of this status code.
1278
12798.1.2.  101 Switching Protocols
1280
1281   The server understands and is willing to comply with the client's
1282   request, via the Upgrade message header field (Section 9.8 of
1283   [Part1]), for a change in the application protocol being used on this
1284
1285
1286
1287Fielding, et al.        Expires January 12, 2012               [Page 23]
1288
1289Internet-Draft              HTTP/1.1, Part 2                   July 2011
1290
1291
1292   connection.  The server will switch protocols to those defined by the
1293   response's Upgrade header field immediately after the empty line
1294   which terminates the 101 response.
1295
1296   The protocol SHOULD be switched only when it is advantageous to do
1297   so.  For example, switching to a newer version of HTTP is
1298   advantageous over older versions, and switching to a real-time,
1299   synchronous protocol might be advantageous when delivering resources
1300   that use such features.
1301
13028.2.  Successful 2xx
1303
1304   This class of status code indicates that the client's request was
1305   successfully received, understood, and accepted.
1306
13078.2.1.  200 OK
1308
1309   The request has succeeded.  The payload returned with the response is
1310   dependent on the method used in the request, for example:
1311
1312   GET  a representation of the target resource is sent in the response;
1313
1314   HEAD  the same representation as GET, except without the message-
1315      body;
1316
1317   POST  a representation describing or containing the result of the
1318      action;
1319
1320   TRACE  a representation containing the request message as received by
1321      the end server.
1322
1323   Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to
1324   determine freshness for 200 responses.
1325
13268.2.2.  201 Created
1327
1328   The request has been fulfilled and has resulted in a new resource
1329   being created.  The newly created resource can be referenced by the
1330   URI(s) returned in the payload of the response, with the most
1331   specific URI for the resource given by a Location header field.  The
1332   response SHOULD include a payload containing a list of resource
1333   characteristics and location(s) from which the user or user agent can
1334   choose the one most appropriate.  The payload format is specified by
1335   the media type given in the Content-Type header field.  The origin
1336   server MUST create the resource before returning the 201 status code.
1337   If the action cannot be carried out immediately, the server SHOULD
1338   respond with 202 (Accepted) response instead.
1339
1340
1341
1342
1343Fielding, et al.        Expires January 12, 2012               [Page 24]
1344
1345Internet-Draft              HTTP/1.1, Part 2                   July 2011
1346
1347
1348   A 201 response MAY contain an ETag response header field indicating
1349   the current value of the entity-tag for the representation of the
1350   resource just created (see Section 2.2 of [Part4]).
1351
13528.2.3.  202 Accepted
1353
1354   The request has been accepted for processing, but the processing has
1355   not been completed.  The request might or might not eventually be
1356   acted upon, as it might be disallowed when processing actually takes
1357   place.  There is no facility for re-sending a status code from an
1358   asynchronous operation such as this.
1359
1360   The 202 response is intentionally non-committal.  Its purpose is to
1361   allow a server to accept a request for some other process (perhaps a
1362   batch-oriented process that is only run once per day) without
1363   requiring that the user agent's connection to the server persist
1364   until the process is completed.  The representation returned with
1365   this response SHOULD include an indication of the request's current
1366   status and either a pointer to a status monitor or some estimate of
1367   when the user can expect the request to be fulfilled.
1368
13698.2.4.  203 Non-Authoritative Information
1370
1371   The representation in the response has been transformed or otherwise
1372   modified by a transforming proxy (Section 2.4 of [Part1]).  Note that
1373   the behaviour of transforming intermediaries is controlled by the no-
1374   transform Cache-Control directive (Section 3.2 of [Part6]).
1375
1376   This status code is only appropriate when the response status code
1377   would have been 200 (OK) otherwise.  When the status code before
1378   transformation would have been different, the 214 Transformation
1379   Applied warn-code (Section 3.6 of [Part6]) is appropriate.
1380
1381   Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to
1382   determine freshness for 203 responses.
1383
13848.2.5.  204 No Content
1385
1386   The 204 (No Content) status code indicates that the server has
1387   successfully fulfilled the request and that there is no additional
1388   content to return in the response payload body.  Metadata in the
1389   response header fields refer to the target resource and its current
1390   representation after the requested action.
1391
1392   For example, if a 204 status code is received in response to a PUT
1393   request and the response contains an ETag header field, then the PUT
1394   was successful and the ETag field-value contains the entity-tag for
1395   the new representation of that target resource.
1396
1397
1398
1399Fielding, et al.        Expires January 12, 2012               [Page 25]
1400
1401Internet-Draft              HTTP/1.1, Part 2                   July 2011
1402
1403
1404   The 204 response allows a server to indicate that the action has been
1405   successfully applied to the target resource while implying that the
1406   user agent SHOULD NOT traverse away from its current "document view"
1407   (if any).  The server assumes that the user agent will provide some
1408   indication of the success to its user, in accord with its own
1409   interface, and apply any new or updated metadata in the response to
1410   the active representation.
1411
1412   For example, a 204 status code is commonly used with document editing
1413   interfaces corresponding to a "save" action, such that the document
1414   being saved remains available to the user for editing.  It is also
1415   frequently used with interfaces that expect automated data transfers
1416   to be prevalent, such as within distributed version control systems.
1417
1418   The 204 response MUST NOT include a message-body, and thus is always
1419   terminated by the first empty line after the header fields.
1420
14218.2.6.  205 Reset Content
1422
1423   The server has fulfilled the request and the user agent SHOULD reset
1424   the document view which caused the request to be sent.  This response
1425   is primarily intended to allow input for actions to take place via
1426   user input, followed by a clearing of the form in which the input is
1427   given so that the user can easily initiate another input action.
1428
1429   The message-body included with the response MUST be empty.  Note that
1430   receivers still need to parse the response according to the algorithm
1431   defined in Section 3.3 of [Part1].
1432
14338.2.7.  206 Partial Content
1434
1435   The server has fulfilled the partial GET request for the resource and
1436   the enclosed payload is a partial representation as defined in
1437   Section 3.1 of [Part5].
1438
1439   Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to
1440   determine freshness for 206 responses.
1441
14428.3.  Redirection 3xx
1443
1444   This class of status code indicates that further action needs to be
1445   taken by the user agent in order to fulfill the request.  The action
1446   required MAY be carried out by the user agent without interaction
1447   with the user if and only if the method used in the second request is
1448   known to be "safe", as defined in Section 7.1.1.  A client SHOULD
1449   detect infinite redirection loops, since such loops generate network
1450   traffic for each redirection.
1451
1452
1453
1454
1455Fielding, et al.        Expires January 12, 2012               [Page 26]
1456
1457Internet-Draft              HTTP/1.1, Part 2                   July 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 January 12, 2012               [Page 27]
1512
1513Internet-Draft              HTTP/1.1, Part 2                   July 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 January 12, 2012               [Page 28]
1568
1569Internet-Draft              HTTP/1.1, Part 2                   July 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 January 12, 2012               [Page 29]
1624
1625Internet-Draft              HTTP/1.1, Part 2                   July 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 refuses to authorize it.
1675   Providing different user authentication credentials might be
1676
1677
1678
1679Fielding, et al.        Expires January 12, 2012               [Page 30]
1680
1681Internet-Draft              HTTP/1.1, Part 2                   July 2011
1682
1683
1684   successful, but any credentials that were provided in the request are
1685   insufficient.  The request SHOULD NOT be repeated with the same
1686   credentials.
1687
1688   If the request method was not HEAD and the server wishes to make
1689   public why the request has not been fulfilled, it SHOULD describe the
1690   reason for the refusal in the representation.  If the server does not
1691   wish to make this information available to the client, the status
1692   code 404 (Not Found) MAY be used instead.
1693
16948.4.5.  404 Not Found
1695
1696   The server has not found anything matching the effective request URI.
1697   No indication is given of whether the condition is temporary or
1698   permanent.  The 410 (Gone) status code SHOULD be used if the server
1699   knows, through some internally configurable mechanism, that an old
1700   resource is permanently unavailable and has no forwarding address.
1701   This status code is commonly used when the server does not wish to
1702   reveal exactly why the request has been refused, or when no other
1703   response is applicable.
1704
17058.4.6.  405 Method Not Allowed
1706
1707   The method specified in the Request-Line is not allowed for the
1708   target resource.  The response MUST include an Allow header field
1709   containing a list of valid methods for the requested resource.
1710
17118.4.7.  406 Not Acceptable
1712
1713   The resource identified by the request is only capable of generating
1714   response representations which have content characteristics not
1715   acceptable according to the accept header fields sent in the request.
1716
1717   Unless it was a HEAD request, the response SHOULD include a
1718   representation containing a list of available representation
1719   characteristics and location(s) from which the user or user agent can
1720   choose the one most appropriate.  The data format is specified by the
1721   media type given in the Content-Type header field.  Depending upon
1722   the format and the capabilities of the user agent, selection of the
1723   most appropriate choice MAY be performed automatically.  However,
1724   this specification does not define any standard for such automatic
1725   selection.
1726
1727      Note: HTTP/1.1 servers are allowed to return responses which are
1728      not acceptable according to the accept header fields sent in the
1729      request.  In some cases, this might even be preferable to sending
1730      a 406 response.  User agents are encouraged to inspect the header
1731      fields of an incoming response to determine if it is acceptable.
1732
1733
1734
1735Fielding, et al.        Expires January 12, 2012               [Page 31]
1736
1737Internet-Draft              HTTP/1.1, Part 2                   July 2011
1738
1739
1740   If the response could be unacceptable, a user agent SHOULD
1741   temporarily stop receipt of more data and query the user for a
1742   decision on further actions.
1743
17448.4.8.  407 Proxy Authentication Required
1745
1746   This code is similar to 401 (Unauthorized), but indicates that the
1747   client must first authenticate itself with the proxy (see Section 3.2
1748   of [Part7]).
1749
17508.4.9.  408 Request Timeout
1751
1752   The client did not produce a request within the time that the server
1753   was prepared to wait.  The client MAY repeat the request without
1754   modifications at any later time.
1755
17568.4.10.  409 Conflict
1757
1758   The request could not be completed due to a conflict with the current
1759   state of the resource.  This code is only allowed in situations where
1760   it is expected that the user might be able to resolve the conflict
1761   and resubmit the request.  The response body SHOULD include enough
1762   information for the user to recognize the source of the conflict.
1763   Ideally, the response representation would include enough information
1764   for the user or user agent to fix the problem; however, that might
1765   not be possible and is not required.
1766
1767   Conflicts are most likely to occur in response to a PUT request.  For
1768   example, if versioning were being used and the representation being
1769   PUT included changes to a resource which conflict with those made by
1770   an earlier (third-party) request, the server might use the 409
1771   response to indicate that it can't complete the request.  In this
1772   case, the response representation would likely contain a list of the
1773   differences between the two versions in a format defined by the
1774   response Content-Type.
1775
17768.4.11.  410 Gone
1777
1778   The target resource is no longer available at the server and no
1779   forwarding address is known.  This condition is expected to be
1780   considered permanent.  Clients with link editing capabilities SHOULD
1781   delete references to the effective request URI after user approval.
1782   If the server does not know, or has no facility to determine, whether
1783   or not the condition is permanent, the status code 404 (Not Found)
1784   SHOULD be used instead.
1785
1786   The 410 response is primarily intended to assist the task of web
1787   maintenance by notifying the recipient that the resource is
1788
1789
1790
1791Fielding, et al.        Expires January 12, 2012               [Page 32]
1792
1793Internet-Draft              HTTP/1.1, Part 2                   July 2011
1794
1795
1796   intentionally unavailable and that the server owners desire that
1797   remote links to that resource be removed.  Such an event is common
1798   for limited-time, promotional services and for resources belonging to
1799   individuals no longer working at the server's site.  It is not
1800   necessary to mark all permanently unavailable resources as "gone" or
1801   to keep the mark for any length of time -- that is left to the
1802   discretion of the server owner.
1803
1804   Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to
1805   determine freshness for 410 responses.
1806
18078.4.12.  411 Length Required
1808
1809   The server refuses to accept the request without a defined Content-
1810   Length.  The client MAY repeat the request if it adds a valid
1811   Content-Length header field containing the length of the message-body
1812   in the request message.
1813
18148.4.13.  412 Precondition Failed
1815
1816   The precondition given in one or more of the header fields evaluated
1817   to false when it was tested on the server, as defined in Section 4.2
1818   of [Part4].
1819
18208.4.14.  413 Request Representation Too Large
1821
1822   The server is refusing to process a request because the request
1823   representation is larger than the server is willing or able to
1824   process.  The server MAY close the connection to prevent the client
1825   from continuing the request.
1826
1827   If the condition is temporary, the server SHOULD include a Retry-
1828   After header field to indicate that it is temporary and after what
1829   time the client MAY try again.
1830
18318.4.15.  414 URI Too Long
1832
1833   The server is refusing to service the request because the effective
1834   request URI is longer than the server is willing to interpret.  This
1835   rare condition is only likely to occur when a client has improperly
1836   converted a POST request to a GET request with long query
1837   information, when the client has descended into a URI "black hole" of
1838   redirection (e.g., a redirected URI prefix that points to a suffix of
1839   itself), or when the server is under attack by a client attempting to
1840   exploit security holes present in some servers using fixed-length
1841   buffers for reading or manipulating the effective request URI.
1842
1843
1844
1845
1846
1847Fielding, et al.        Expires January 12, 2012               [Page 33]
1848
1849Internet-Draft              HTTP/1.1, Part 2                   July 2011
1850
1851
18528.4.16.  415 Unsupported Media Type
1853
1854   The server is refusing to service the request because the request
1855   payload is in a format not supported by this request method on the
1856   target resource.
1857
18588.4.17.  416 Requested Range Not Satisfiable
1859
1860   The request included a Range header field (Section 5.4 of [Part5])
1861   and none of the range-specifier values in this field overlap the
1862   current extent of the selected resource.  See Section 3.2 of [Part5].
1863
18648.4.18.  417 Expectation Failed
1865
1866   The expectation given in an Expect header field (see Section 9.2)
1867   could not be met by this server, or, if the server is a proxy, the
1868   server has unambiguous evidence that the request could not be met by
1869   the next-hop server.
1870
18718.4.19.  426 Upgrade Required
1872
1873   The request can not be completed without a prior protocol upgrade.
1874   This response MUST include an Upgrade header field (Section 9.8 of
1875   [Part1]) specifying the required protocols.
1876
1877   Example:
1878
1879     HTTP/1.1 426 Upgrade Required
1880     Upgrade: HTTP/2.0
1881     Connection: Upgrade
1882
1883
1884   The server SHOULD include a message body in the 426 response which
1885   indicates in human readable form the reason for the error and
1886   describes any alternative courses which may be available to the user.
1887
18888.5.  Server Error 5xx
1889
1890   Response status codes beginning with the digit "5" indicate cases in
1891   which the server is aware that it has erred or is incapable of
1892   performing the request.  Except when responding to a HEAD request,
1893   the server SHOULD include a representation containing an explanation
1894   of the error situation, and whether it is a temporary or permanent
1895   condition.  User agents SHOULD display any included representation to
1896   the user.  These response codes are applicable to any request method.
1897
1898
1899
1900
1901
1902
1903Fielding, et al.        Expires January 12, 2012               [Page 34]
1904
1905Internet-Draft              HTTP/1.1, Part 2                   July 2011
1906
1907
19088.5.1.  500 Internal Server Error
1909
1910   The server encountered an unexpected condition which prevented it
1911   from fulfilling the request.
1912
19138.5.2.  501 Not Implemented
1914
1915   The server does not support the functionality required to fulfill the
1916   request.  This is the appropriate response when the server does not
1917   recognize the request method and is not capable of supporting it for
1918   any resource.
1919
19208.5.3.  502 Bad Gateway
1921
1922   The server, while acting as a gateway or proxy, received an invalid
1923   response from the upstream server it accessed in attempting to
1924   fulfill the request.
1925
19268.5.4.  503 Service Unavailable
1927
1928   The server is currently unable or unwilling to handle the request due
1929   to reasons such as temporary overloading, maintenance of the server,
1930   or rate limiting of the client.
1931
1932   The implication is that this is a temporary condition which will be
1933   alleviated after some delay.  If known, the length of the delay MAY
1934   be indicated in a Retry-After header field (Section 9.7).  If no
1935   Retry-After is given, the client SHOULD handle the response as it
1936   would for a 500 response.
1937
1938      Note: The existence of the 503 status code does not imply that a
1939      server must use it when becoming overloaded.  Some servers might
1940      wish to simply refuse the connection.
1941
19428.5.5.  504 Gateway Timeout
1943
1944   The server, while acting as a gateway or proxy, did not receive a
1945   timely response from the upstream server specified by the URI (e.g.,
1946   HTTP, FTP, LDAP) or some other auxiliary server (e.g., DNS) it needed
1947   to access in attempting to complete the request.
1948
1949      Note to implementors: some deployed proxies are known to return
1950      400 or 500 when DNS lookups time out.
1951
1952
1953
1954
1955
1956
1957
1958
1959Fielding, et al.        Expires January 12, 2012               [Page 35]
1960
1961Internet-Draft              HTTP/1.1, Part 2                   July 2011
1962
1963
19648.5.6.  505 HTTP Version Not Supported
1965
1966   The server does not support, or refuses to support, the protocol
1967   version that was used in the request message.  The server is
1968   indicating that it is unable or unwilling to complete the request
1969   using the same major version as the client, as described in Section
1970   2.6 of [Part1], other than with this error message.  The response
1971   SHOULD contain a representation describing why that version is not
1972   supported and what other protocols are supported by that server.
1973
19749.  Header Field Definitions
1975
1976   This section defines the syntax and semantics of HTTP/1.1 header
1977   fields related to request and response semantics.
1978
19799.1.  Allow
1980
1981   The "Allow" header field lists the set of methods advertised as
1982   supported by the target resource.  The purpose of this field is
1983   strictly to inform the recipient of valid request methods associated
1984   with the resource.
1985
1986     Allow = #Method
1987
1988   Example of use:
1989
1990     Allow: GET, HEAD, PUT
1991
1992   The actual set of allowed methods is defined by the origin server at
1993   the time of each request.
1994
1995   A proxy MUST NOT modify the Allow header field -- it does not need to
1996   understand all the methods specified in order to handle them
1997   according to the generic message handling rules.
1998
19999.2.  Expect
2000
2001   The "Expect" header field is used to indicate that particular server
2002   behaviors are required by the client.
2003
2004     Expect       = 1#expectation
2005
2006     expectation  = "100-continue" / expectation-extension
2007     expectation-extension = token [ "=" ( token / quoted-string )
2008                              *expect-params ]
2009     expect-params = ";" token [ "=" ( token / quoted-string ) ]
2010
2011   A server that does not understand or is unable to comply with any of
2012
2013
2014
2015Fielding, et al.        Expires January 12, 2012               [Page 36]
2016
2017Internet-Draft              HTTP/1.1, Part 2                   July 2011
2018
2019
2020   the expectation values in the Expect field of a request MUST respond
2021   with appropriate error status code.  The server MUST respond with a
2022   417 (Expectation Failed) status code if any of the expectations
2023   cannot be met or, if there are other problems with the request, some
2024   other 4xx status code.
2025
2026   This header field is defined with extensible syntax to allow for
2027   future extensions.  If a server receives a request containing an
2028   Expect field that includes an expectation-extension that it does not
2029   support, it MUST respond with a 417 (Expectation Failed) status code.
2030
2031   Comparison of expectation values is case-insensitive for unquoted
2032   tokens (including the 100-continue token), and is case-sensitive for
2033   quoted-string expectation-extensions.
2034
2035   The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy MUST
2036   return a 417 (Expectation Failed) status code if it receives a
2037   request with an expectation that it cannot meet.  However, the Expect
2038   header field itself is end-to-end; it MUST be forwarded if the
2039   request is forwarded.
2040
2041   Many older HTTP/1.0 and HTTP/1.1 applications do not understand the
2042   Expect header field.
2043
2044   See Section 7.2.3 of [Part1] for the use of the 100 (Continue) status
2045   code.
2046
20479.3.  From
2048
2049   The "From" header field, if given, SHOULD contain an Internet e-mail
2050   address for the human user who controls the requesting user agent.
2051   The address SHOULD be machine-usable, as defined by "mailbox" in
2052   Section 3.4 of [RFC5322]:
2053
2054     From    = mailbox
2055
2056     mailbox = <mailbox, defined in [RFC5322], Section 3.4>
2057
2058   An example is:
2059
2060     From: webmaster@example.org
2061
2062   This header field MAY be used for logging purposes and as a means for
2063   identifying the source of invalid or unwanted requests.  It SHOULD
2064   NOT be used as an insecure form of access protection.  The
2065   interpretation of this field is that the request is being performed
2066   on behalf of the person given, who accepts responsibility for the
2067   method performed.  In particular, robot agents SHOULD include this
2068
2069
2070
2071Fielding, et al.        Expires January 12, 2012               [Page 37]
2072
2073Internet-Draft              HTTP/1.1, Part 2                   July 2011
2074
2075
2076   header field so that the person responsible for running the robot can
2077   be contacted if problems occur on the receiving end.
2078
2079   The Internet e-mail address in this field MAY be separate from the
2080   Internet host which issued the request.  For example, when a request
2081   is passed through a proxy the original issuer's address SHOULD be
2082   used.
2083
2084   The client SHOULD NOT send the From header field without the user's
2085   approval, as it might conflict with the user's privacy interests or
2086   their site's security policy.  It is strongly recommended that the
2087   user be able to disable, enable, and modify the value of this field
2088   at any time prior to a request.
2089
20909.4.  Location
2091
2092   The "Location" header field is used to identify a newly created
2093   resource, or to redirect the recipient to a different location for
2094   completion of the request.
2095
2096   For 201 (Created) responses, the Location is the URI of the new
2097   resource which was created by the request.  For 3xx responses, the
2098   location SHOULD indicate the server's preferred URI for automatic
2099   redirection to the resource.
2100
2101   The field value consists of a single URI-reference.  When it has the
2102   form of a relative reference ([RFC3986], Section 4.2), the final
2103   value is computed by resolving it against the effective request URI
2104   ([RFC3986], Section 5).
2105
2106     Location = URI-reference
2107
2108   Examples are:
2109
2110     Location: http://www.example.org/pub/WWW/People.html#tim
2111
2112     Location: /index.html
2113
2114   There are circumstances in which a fragment identifier in a Location
2115   URI would not be appropriate.  For instance, when it appears in a 201
2116   Created response, where the Location header field specifies the URI
2117   for the entire created resource.
2118
2119      Note: This specification does not define precedence rules for the
2120      case where the original URI, as navigated to by the user agent,
2121      and the Location header field value both contain fragment
2122      identifiers.  Thus be aware that including fragment identifiers
2123      might inconvenience anyone relying on the semantics of the
2124
2125
2126
2127Fielding, et al.        Expires January 12, 2012               [Page 38]
2128
2129Internet-Draft              HTTP/1.1, Part 2                   July 2011
2130
2131
2132      original URI's fragment identifier.
2133
2134      Note: The Content-Location header field (Section 6.7 of [Part3])
2135      differs from Location in that the Content-Location identifies the
2136      most specific resource corresponding to the enclosed
2137      representation.  It is therefore possible for a response to
2138      contain header fields for both Location and Content-Location.
2139
21409.5.  Max-Forwards
2141
2142   The "Max-Forwards" header field provides a mechanism with the TRACE
2143   (Section 7.8) and OPTIONS (Section 7.2) methods to limit the number
2144   of times that the request is forwarded by proxies.  This can be
2145   useful when the client is attempting to trace a request which appears
2146   to be failing or looping in mid-chain.
2147
2148     Max-Forwards = 1*DIGIT
2149
2150   The Max-Forwards value is a decimal integer indicating the remaining
2151   number of times this request message can be forwarded.
2152
2153   Each recipient of a TRACE or OPTIONS request containing a Max-
2154   Forwards header field MUST check and update its value prior to
2155   forwarding the request.  If the received value is zero (0), the
2156   recipient MUST NOT forward the request; instead, it MUST respond as
2157   the final recipient.  If the received Max-Forwards value is greater
2158   than zero, then the forwarded message MUST contain an updated Max-
2159   Forwards field with a value decremented by one (1).
2160
2161   The Max-Forwards header field MAY be ignored for all other request
2162   methods.
2163
21649.6.  Referer
2165
2166   The "Referer" [sic] header field allows the client to specify the URI
2167   of the resource from which the effective request URI was obtained
2168   (the "referrer", although the header field is misspelled.).
2169
2170   The Referer header field allows servers to generate lists of back-
2171   links to resources for interest, logging, optimized caching, etc.  It
2172   also allows obsolete or mistyped links to be traced for maintenance.
2173   Some servers use Referer as a means of controlling where they allow
2174   links from (so-called "deep linking"), but legitimate requests do not
2175   always contain a Referer header field.
2176
2177   If the effective request URI was obtained from a source that does not
2178   have its own URI (e.g., input from the user keyboard), the Referer
2179   field MUST either be sent with the value "about:blank", or not be
2180
2181
2182
2183Fielding, et al.        Expires January 12, 2012               [Page 39]
2184
2185Internet-Draft              HTTP/1.1, Part 2                   July 2011
2186
2187
2188   sent at all.  Note that this requirement does not apply to sources
2189   with non-HTTP URIs (e.g., FTP).
2190
2191     Referer = absolute-URI / partial-URI
2192
2193   Example:
2194
2195     Referer: http://www.example.org/hypertext/Overview.html
2196
2197   If the field value is a relative URI, it SHOULD be interpreted
2198   relative to the effective request URI.  The URI MUST NOT include a
2199   fragment.  See Section 11.2 for security considerations.
2200
22019.7.  Retry-After
2202
2203   The header "Retry-After" field can be used with a 503 (Service
2204   Unavailable) response to indicate how long the service is expected to
2205   be unavailable to the requesting client.  This field MAY also be used
2206   with any 3xx (Redirection) response to indicate the minimum time the
2207   user-agent is asked wait before issuing the redirected request.
2208
2209   The value of this field can be either an HTTP-date or an integer
2210   number of seconds (in decimal) after the time of the response.
2211
2212     Retry-After = HTTP-date / delta-seconds
2213
2214   Time spans are non-negative decimal integers, representing time in
2215   seconds.
2216
2217     delta-seconds  = 1*DIGIT
2218
2219   Two examples of its use are
2220
2221     Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
2222     Retry-After: 120
2223
2224   In the latter example, the delay is 2 minutes.
2225
22269.8.  Server
2227
2228   The "Server" header field contains information about the software
2229   used by the origin server to handle the request.
2230
2231   The field can contain multiple product tokens (Section 6.3 of
2232   [Part1]) and comments (Section 3.2 of [Part1]) identifying the server
2233   and any significant subproducts.  The product tokens are listed in
2234   order of their significance for identifying the application.
2235
2236
2237
2238
2239Fielding, et al.        Expires January 12, 2012               [Page 40]
2240
2241Internet-Draft              HTTP/1.1, Part 2                   July 2011
2242
2243
2244     Server = product *( RWS ( product / comment ) )
2245
2246   Example:
2247
2248     Server: CERN/3.0 libwww/2.17
2249
2250   If the response is being forwarded through a proxy, the proxy
2251   application MUST NOT modify the Server header field.  Instead, it
2252   MUST include a Via field (as described in Section 9.9 of [Part1]).
2253
2254      Note: Revealing the specific software version of the server might
2255      allow the server machine to become more vulnerable to attacks
2256      against software that is known to contain security holes.  Server
2257      implementors are encouraged to make this field a configurable
2258      option.
2259
22609.9.  User-Agent
2261
2262   The "User-Agent" header field contains information about the user
2263   agent originating the request.  User agents SHOULD include this field
2264   with requests.
2265
2266   Typically, it is used for statistical purposes, the tracing of
2267   protocol violations, and tailoring responses to avoid particular user
2268   agent limitations.
2269
2270   The field can contain multiple product tokens (Section 6.3 of
2271   [Part1]) and comments (Section 3.2 of [Part1]) identifying the agent
2272   and its significant subproducts.  By convention, the product tokens
2273   are listed in order of their significance for identifying the
2274   application.
2275
2276   Because this field is usually sent on every request a user agent
2277   makes, implementations are encouraged not to include needlessly fine-
2278   grained detail, and to limit (or even prohibit) the addition of
2279   subproducts by third parties.  Overly long and detailed User-Agent
2280   field values make requests larger and can also be used to identify
2281   ("fingerprint") the user against their wishes.
2282
2283   Likewise, implementations are encouraged not to use the product
2284   tokens of other implementations in order to declare compatibility
2285   with them, as this circumvents the purpose of the field.  Finally,
2286   they are encouraged not to use comments to identify products; doing
2287   so makes the field value more difficult to parse.
2288
2289     User-Agent = product *( RWS ( product / comment ) )
2290
2291   Example:
2292
2293
2294
2295Fielding, et al.        Expires January 12, 2012               [Page 41]
2296
2297Internet-Draft              HTTP/1.1, Part 2                   July 2011
2298
2299
2300     User-Agent: CERN-LineMode/2.15 libwww/2.17b3
2301
230210.  IANA Considerations
2303
230410.1.  Method Registry
2305
2306   The registration procedure for HTTP request methods is defined by
2307   Section 2.2 of this document.
2308
2309   The HTTP Method Registry shall be created at
2310   <http://www.iana.org/assignments/http-methods> and be populated with
2311   the registrations below:
2312
2313   +---------+------+-------------+
2314   | Method  | Safe | Reference   |
2315   +---------+------+-------------+
2316   | CONNECT | no   | Section 7.9 |
2317   | DELETE  | no   | Section 7.7 |
2318   | GET     | yes  | Section 7.3 |
2319   | HEAD    | yes  | Section 7.4 |
2320   | OPTIONS | yes  | Section 7.2 |
2321   | POST    | no   | Section 7.5 |
2322   | PUT     | no   | Section 7.6 |
2323   | TRACE   | yes  | Section 7.8 |
2324   +---------+------+-------------+
2325
232610.2.  Status Code Registry
2327
2328   The registration procedure for HTTP Status Codes -- previously
2329   defined in Section 7.1 of [RFC2817] -- is now defined by Section 4.2
2330   of this document.
2331
2332   The HTTP Status Code Registry located at
2333   <http://www.iana.org/assignments/http-status-codes> shall be updated
2334   with the registrations below:
2335
2336
2337
2338
2339
2340
2341
2342
2343
2344
2345
2346
2347
2348
2349
2350
2351Fielding, et al.        Expires January 12, 2012               [Page 42]
2352
2353Internet-Draft              HTTP/1.1, Part 2                   July 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 Representation 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 January 12, 2012               [Page 43]
2408
2409Internet-Draft              HTTP/1.1, Part 2                   July 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 January 12, 2012               [Page 44]
2464
2465Internet-Draft              HTTP/1.1, Part 2                   July 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 January 12, 2012               [Page 45]
2520
2521Internet-Draft              HTTP/1.1, Part 2                   July 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-15
2555              (work in progress), July 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-15
2561              (work in progress), July 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-15 (work in
2567              progress), July 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 January 12, 2012               [Page 46]
2576
2577Internet-Draft              HTTP/1.1, Part 2                   July 2011
2578
2579
2580              Partial Responses", draft-ietf-httpbis-p5-range-15 (work
2581              in progress), July 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-15 (work in
2587              progress), July 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-15 (work in progress),
2593              July 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 January 12, 2012               [Page 47]
2632
2633Internet-Draft              HTTP/1.1, Part 2                   July 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   Broadened the definition of 203 (Non-Authoritative Information) to
2655   include cases of payload transformations as well.  (Section 8.2.4)
2656
2657   Failed to consider that there are many other request methods that are
2658   safe to automatically redirect, and further that the user agent is
2659   able to make that determination based on the request method
2660   semantics.  (Sections 8.3.2, 8.3.3 and 8.3.8)
2661
2662   Deprecate 305 Use Proxy status code, because user agents did not
2663   implement it.  It used to indicate that the target resource must be
2664   accessed through the proxy given by the Location field.  The Location
2665   field gave the URI of the proxy.  The recipient was expected to
2666   repeat this single request via the proxy.  (Section 8.3.6)
2667
2668   Define status 426 (Upgrade Required) (this was incorporated from
2669   [RFC2817]).  (Section 8.4.19)
2670
2671   Change ABNF productions for header fields to only define the field
2672   value.  (Section 9)
2673
2674   Reclassify "Allow" as response header field, removing the option to
2675   specify it in a PUT request.  Relax the server requirement on the
2676   contents of the Allow header field and remove requirement on clients
2677   to always trust the header field value.  (Section 9.1)
2678
2679   Correct syntax of Location header field to allow URI references
2680   (including relative references and fragments), as referred symbol
2681   "absoluteURI" wasn't what was expected, and add some clarifications
2682   as to when use of fragments would not be appropriate.  (Section 9.4)
2683
2684
2685
2686
2687Fielding, et al.        Expires January 12, 2012               [Page 48]
2688
2689Internet-Draft              HTTP/1.1, Part 2                   July 2011
2690
2691
2692   Restrict Max-Forwards header field to OPTIONS and TRACE (previously,
2693   extension methods could have used it as well).  (Section 9.5)
2694
2695   Allow Referer field value of "about:blank" as alternative to not
2696   specifying it.  (Section 9.6)
2697
2698   In the description of the Server header field, the Via field was
2699   described as a SHOULD.  The requirement was and is stated correctly
2700   in the description of the Via header field in Section 9.9 of [Part1].
2701   (Section 9.8)
2702
2703Appendix B.  Collected ABNF
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 January 12, 2012               [Page 49]
2744
2745Internet-Draft              HTTP/1.1, Part 2                   July 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.7>
2772   User-Agent = product *( RWS ( product / comment ) )
2773
2774   absolute-URI = <absolute-URI, defined in [Part1], Section 2.7>
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.7>
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 January 12, 2012               [Page 50]
2800
2801Internet-Draft              HTTP/1.1, Part 2                   July 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 January 12, 2012               [Page 51]
2856
2857Internet-Draft              HTTP/1.1, Part 2                   July 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 January 12, 2012               [Page 52]
2912
2913Internet-Draft              HTTP/1.1, Part 2                   July 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 January 12, 2012               [Page 53]
2968
2969Internet-Draft              HTTP/1.1, Part 2                   July 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 January 12, 2012               [Page 54]
3024
3025Internet-Draft              HTTP/1.1, Part 2                   July 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 January 12, 2012               [Page 55]
3080
3081Internet-Draft              HTTP/1.1, Part 2                   July 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 January 12, 2012               [Page 56]
3136
3137Internet-Draft              HTTP/1.1, Part 2                   July 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 January 12, 2012               [Page 57]
3192
3193Internet-Draft              HTTP/1.1, Part 2                   July 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
3206C.16.  Since draft-ietf-httpbis-p2-semantics-14
3207
3208   Closed issues:
3209
3210   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/255>: "Clarify
3211      status code for rate limiting"
3212
3213   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/294>: "clarify 403
3214      forbidden"
3215
3216   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/296>: "Clarify 203
3217      Non-Authoritative Information"
3218
3219   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/298>: "update
3220      default reason phrase for 413"
3221
3222Index
3223
3224   1
3225      100 Continue (status code)  23
3226      101 Switching Protocols (status code)  23
3227
3228   2
3229      200 OK (status code)  24
3230      201 Created (status code)  24
3231      202 Accepted (status code)  25
3232      203 Non-Authoritative Information (status code)  25
3233      204 No Content (status code)  25
3234      205 Reset Content (status code)  26
3235      206 Partial Content (status code)  26
3236
3237   3
3238      300 Multiple Choices (status code)  27
3239      301 Moved Permanently (status code)  27
3240      302 Found (status code)  28
3241      303 See Other (status code)  28
3242      304 Not Modified (status code)  29
3243      305 Use Proxy (status code)  29
3244
3245
3246
3247Fielding, et al.        Expires January 12, 2012               [Page 58]
3248
3249Internet-Draft              HTTP/1.1, Part 2                   July 2011
3250
3251
3252      306 (Unused) (status code)  29
3253      307 Temporary Redirect (status code)  29
3254
3255   4
3256      400 Bad Request (status code)  30
3257      401 Unauthorized (status code)  30
3258      402 Payment Required (status code)  30
3259      403 Forbidden (status code)  30
3260      404 Not Found (status code)  31
3261      405 Method Not Allowed (status code)  31
3262      406 Not Acceptable (status code)  31
3263      407 Proxy Authentication Required (status code)  32
3264      408 Request Timeout (status code)  32
3265      409 Conflict (status code)  32
3266      410 Gone (status code)  32
3267      411 Length Required (status code)  33
3268      412 Precondition Failed (status code)  33
3269      413 Request Representation Too Large (status code)  33
3270      414 URI Too Long (status code)  33
3271      415 Unsupported Media Type (status code)  34
3272      416 Requested Range Not Satisfiable (status code)  34
3273      417 Expectation Failed (status code)  34
3274      426 Upgrade Required (status code)  34
3275
3276   5
3277      500 Internal Server Error (status code)  35
3278      501 Not Implemented (status code)  35
3279      502 Bad Gateway (status code)  35
3280      503 Service Unavailable (status code)  35
3281      504 Gateway Timeout (status code)  35
3282      505 HTTP Version Not Supported (status code)  36
3283
3284   A
3285      Allow header field  36
3286
3287   C
3288      CONNECT method  21
3289
3290   D
3291      DELETE method  20
3292
3293   E
3294      Expect header field  36
3295
3296   F
3297      From header field  37
3298
3299   G
3300
3301
3302
3303Fielding, et al.        Expires January 12, 2012               [Page 59]
3304
3305Internet-Draft              HTTP/1.1, Part 2                   July 2011
3306
3307
3308      GET method  16
3309      Grammar
3310         Allow  36
3311         delta-seconds  40
3312         Expect  36
3313         expect-params  36
3314         expectation  36
3315         expectation-extension  36
3316         extension-code  10
3317         From  37
3318         Location  38
3319         Max-Forwards  39
3320         Method  7
3321         Reason-Phrase  10
3322         Referer  40
3323         Retry-After  40
3324         Server  40
3325         Status-Code  10
3326         User-Agent  41
3327
3328   H
3329      HEAD method  17
3330      Header Fields
3331         Allow  36
3332         Expect  36
3333         From  37
3334         Location  38
3335         Max-Forwards  39
3336         Referer  39
3337         Retry-After  40
3338         Server  40
3339         User-Agent  41
3340
3341   I
3342      Idempotent Methods  15
3343
3344   L
3345      Location header field  38
3346
3347   M
3348      Max-Forwards header field  39
3349      Methods
3350         CONNECT  21
3351         DELETE  20
3352         GET  16
3353         HEAD  17
3354         OPTIONS  15
3355         POST  17
3356
3357
3358
3359Fielding, et al.        Expires January 12, 2012               [Page 60]
3360
3361Internet-Draft              HTTP/1.1, Part 2                   July 2011
3362
3363
3364         PUT  18
3365         TRACE  21
3366
3367   O
3368      OPTIONS method  15
3369
3370   P
3371      POST method  17
3372      PUT method  18
3373
3374   R
3375      Referer header field  39
3376      Retry-After header field  40
3377
3378   S
3379      Safe Methods  14
3380      Server header field  40
3381      Status Codes
3382         100 Continue  23
3383         101 Switching Protocols  23
3384         200 OK  24
3385         201 Created  24
3386         202 Accepted  25
3387         203 Non-Authoritative Information  25
3388         204 No Content  25
3389         205 Reset Content  26
3390         206 Partial Content  26
3391         300 Multiple Choices  27
3392         301 Moved Permanently  27
3393         302 Found  28
3394         303 See Other  28
3395         304 Not Modified  29
3396         305 Use Proxy  29
3397         306 (Unused)  29
3398         307 Temporary Redirect  29
3399         400 Bad Request  30
3400         401 Unauthorized  30
3401         402 Payment Required  30
3402         403 Forbidden  30
3403         404 Not Found  31
3404         405 Method Not Allowed  31
3405         406 Not Acceptable  31
3406         407 Proxy Authentication Required  32
3407         408 Request Timeout  32
3408         409 Conflict  32
3409         410 Gone  32
3410         411 Length Required  33
3411         412 Precondition Failed  33
3412
3413
3414
3415Fielding, et al.        Expires January 12, 2012               [Page 61]
3416
3417Internet-Draft              HTTP/1.1, Part 2                   July 2011
3418
3419
3420         413 Request Representation Too Large  33
3421         414 URI Too Long  33
3422         415 Unsupported Media Type  34
3423         416 Requested Range Not Satisfiable  34
3424         417 Expectation Failed  34
3425         426 Upgrade Required  34
3426         500 Internal Server Error  35
3427         501 Not Implemented  35
3428         502 Bad Gateway  35
3429         503 Service Unavailable  35
3430         504 Gateway Timeout  35
3431         505 HTTP Version Not Supported  36
3432
3433   T
3434      TRACE method  21
3435
3436   U
3437      User-Agent header field  41
3438
3439Authors' Addresses
3440
3441   Roy T. Fielding (editor)
3442   Adobe Systems Incorporated
3443   345 Park Ave
3444   San Jose, CA  95110
3445   USA
3446
3447   EMail: fielding@gbiv.com
3448   URI:   http://roy.gbiv.com/
3449
3450
3451   Jim Gettys
3452   Alcatel-Lucent Bell Labs
3453   21 Oak Knoll Road
3454   Carlisle, MA  01741
3455   USA
3456
3457   EMail: jg@freedesktop.org
3458   URI:   http://gettys.wordpress.com/
3459
3460
3461
3462
3463
3464
3465
3466
3467
3468
3469
3470
3471Fielding, et al.        Expires January 12, 2012               [Page 62]
3472
3473Internet-Draft              HTTP/1.1, Part 2                   July 2011
3474
3475
3476   Jeffrey C. Mogul
3477   Hewlett-Packard Company
3478   HP Labs, Large Scale Systems Group
3479   1501 Page Mill Road, MS 1177
3480   Palo Alto, CA  94304
3481   USA
3482
3483   EMail: JeffMogul@acm.org
3484
3485
3486   Henrik Frystyk Nielsen
3487   Microsoft Corporation
3488   1 Microsoft Way
3489   Redmond, WA  98052
3490   USA
3491
3492   EMail: henrikn@microsoft.com
3493
3494
3495   Larry Masinter
3496   Adobe Systems Incorporated
3497   345 Park Ave
3498   San Jose, CA  95110
3499   USA
3500
3501   EMail: LMM@acm.org
3502   URI:   http://larry.masinter.net/
3503
3504
3505   Paul J. Leach
3506   Microsoft Corporation
3507   1 Microsoft Way
3508   Redmond, WA  98052
3509
3510   EMail: paulle@microsoft.com
3511
3512
3513   Tim Berners-Lee
3514   World Wide Web Consortium
3515   MIT Computer Science and Artificial Intelligence Laboratory
3516   The Stata Center, Building 32
3517   32 Vassar Street
3518   Cambridge, MA  02139
3519   USA
3520
3521   EMail: timbl@w3.org
3522   URI:   http://www.w3.org/People/Berners-Lee/
3523
3524
3525
3526
3527Fielding, et al.        Expires January 12, 2012               [Page 63]
3528
3529Internet-Draft              HTTP/1.1, Part 2                   July 2011
3530
3531
3532   Yves Lafon (editor)
3533   World Wide Web Consortium
3534   W3C / ERCIM
3535   2004, rte des Lucioles
3536   Sophia-Antipolis, AM  06902
3537   France
3538
3539   EMail: ylafon@w3.org
3540   URI:   http://www.raubacapeu.net/people/yves/
3541
3542
3543   Julian F. Reschke (editor)
3544   greenbytes GmbH
3545   Hafenweg 16
3546   Muenster, NW  48155
3547   Germany
3548
3549   Phone: +49 251 2807760
3550   Fax:   +49 251 2807761
3551   EMail: julian.reschke@greenbytes.de
3552   URI:   http://greenbytes.de/tech/webdav/
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 January 12, 2012               [Page 64]
3584
Note: See TracBrowser for help on using the repository browser.