source: draft-ietf-httpbis/13/draft-ietf-httpbis-p2-semantics-13.txt @ 2438

Last change on this file since 2438 was 1180, checked in by julian.reschke@…, 10 years ago

prepare publication of -13

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