source: draft-ietf-httpbis/12/draft-ietf-httpbis-p2-semantics-12.txt @ 1515

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

prepare publication of -12 drafts on 2010-10-25

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