source: draft-ietf-httpbis/07/draft-ietf-httpbis-p2-semantics-07.txt @ 605

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

Prepare release of -07 drafts.

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