source: draft-ietf-httpbis/06/draft-ietf-httpbis-p2-semantics-06.txt @ 558

Last change on this file since 558 was 558, checked in by fielding@…, 11 years ago

Draft 06 (as recorded by www.ietf.org)

  • Property svn:eol-style set to native
File size: 117.0 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: September 10, 2009                                           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                                                           March 9, 2009
23
24
25                  HTTP/1.1, part 2: Message Semantics
26                   draft-ietf-httpbis-p2-semantics-06
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 September 10, 2009               [Page 1]
56
57Internet-Draft              HTTP/1.1, Part 2                  March 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 September 10, 2009.
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.7.
100
101
102
103
104
105
106
107
108
109
110
111Fielding, et al.       Expires September 10, 2009               [Page 2]
112
113Internet-Draft              HTTP/1.1, Part 2                  March 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 September 10, 2009               [Page 3]
168
169Internet-Draft              HTTP/1.1, Part 2                  March 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 September 10, 2009               [Page 4]
224
225Internet-Draft              HTTP/1.1, Part 2                  March 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 . . . . . . . . . 47
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 . . . . . . . . . 49
241   Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
242   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 54
243
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 September 10, 2009               [Page 5]
280
281Internet-Draft              HTTP/1.1, Part 2                  March 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 September 10, 2009               [Page 6]
336
337Internet-Draft              HTTP/1.1, Part 2                  March 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.1>
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 September 10, 2009               [Page 7]
392
393Internet-Draft              HTTP/1.1, Part 2                  March 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 September 10, 2009               [Page 8]
448
449Internet-Draft              HTTP/1.1, Part 2                  March 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).  Any document registering new method names
460   should be traceable through statuses of either 'Obsoletes' or
461   'Updates' to this document.
462
463   The registry itself is maintained at
464   <http://www.iana.org/assignments/http-methods>.
465
466
4673.  Request Header Fields
468
469   The request-header fields allow the client to pass additional
470   information about the request, and about the client itself, to the
471   server.  These fields act as request modifiers, with semantics
472   equivalent to the parameters on a programming language method
473   invocation.
474
475     request-header = Accept                   ; [Part3], Section 5.1
476                    / Accept-Charset           ; [Part3], Section 5.2
477                    / Accept-Encoding          ; [Part3], Section 5.3
478                    / Accept-Language          ; [Part3], Section 5.4
479                    / Authorization            ; [Part7], Section 3.1
480                    / Expect                   ; Section 9.2
481                    / From                     ; Section 9.3
482                    / Host                     ; [Part1], Section 8.4
483                    / If-Match                 ; [Part4], Section 6.2
484                    / If-Modified-Since        ; [Part4], Section 6.3
485                    / If-None-Match            ; [Part4], Section 6.4
486                    / If-Range                 ; [Part5], Section 5.3
487                    / If-Unmodified-Since      ; [Part4], Section 6.5
488                    / Max-Forwards             ; Section 9.5
489                    / Proxy-Authorization      ; [Part7], Section 3.3
490                    / Range                    ; [Part5], Section 5.4
491                    / Referer                  ; Section 9.6
492                    / TE                       ; [Part1], Section 8.8
493                    / User-Agent               ; Section 9.9
494
495   Request-header field names can be extended reliably only in
496   combination with a change in the protocol version.  However, new or
497   experimental header fields MAY be given the semantics of request-
498   header fields if all parties in the communication recognize them to
499   be request-header fields.  Unrecognized header fields are treated as
500
501
502
503Fielding, et al.       Expires September 10, 2009               [Page 9]
504
505Internet-Draft              HTTP/1.1, Part 2                  March 2009
506
507
508   entity-header fields.
509
510
5114.  Status Code and Reason Phrase
512
513   The Status-Code element is a 3-digit integer result code of the
514   attempt to understand and satisfy the request.  The status codes
515   listed below are defined in Section 8.  The Reason-Phrase is intended
516   to give a short textual description of the Status-Code.  The Status-
517   Code is intended for use by automata and the Reason-Phrase is
518   intended for the human user.  The client is not required to examine
519   or display the Reason-Phrase.
520
521   The individual values of the numeric status codes defined for
522   HTTP/1.1, and an example set of corresponding Reason-Phrase's, are
523   presented below.  The reason phrases listed here are only
524   recommendations -- they MAY be replaced by local equivalents without
525   affecting the protocol.
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 September 10, 2009              [Page 10]
560
561Internet-Draft              HTTP/1.1, Part 2                  March 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 September 10, 2009              [Page 11]
616
617Internet-Draft              HTTP/1.1, Part 2                  March 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).  Any document registering new status codes
639   should be traceable through statuses of either 'Obsoletes' or
640   'Updates' to this document.
641
642   The registry itself is maintained at
643   <http://www.iana.org/assignments/http-status-codes>.
644
645
6465.  Response Header Fields
647
648   The response-header fields allow the server to pass additional
649   information about the response which cannot be placed in the Status-
650   Line.  These header fields give information about the server and
651   about further access to the resource identified by the request-
652   target.
653
654     response-header = Accept-Ranges           ; [Part5], Section 5.1
655                     / Age                     ; [Part6], Section 3.1
656                     / Allow                   ; Section 9.1
657                     / ETag                    ; [Part4], Section 6.1
658                     / Location                ; Section 9.4
659                     / Proxy-Authenticate      ; [Part7], Section 3.2
660                     / Retry-After             ; Section 9.7
661                     / Server                  ; Section 9.8
662                     / Vary                    ; [Part6], Section 3.5
663                     / WWW-Authenticate        ; [Part7], Section 3.4
664
665   Response-header field names can be extended reliably only in
666   combination with a change in the protocol version.  However, new or
667   experimental header fields MAY be given the semantics of response-
668
669
670
671Fielding, et al.       Expires September 10, 2009              [Page 12]
672
673Internet-Draft              HTTP/1.1, Part 2                  March 2009
674
675
676   header fields if all parties in the communication recognize them to
677   be response-header fields.  Unrecognized header fields are treated as
678   entity-header fields.
679
680
6816.  Entity
682
683   Request and Response messages MAY transfer an entity if not otherwise
684   restricted by the request method or response status code.  An entity
685   consists of entity-header fields and an entity-body, although some
686   responses will only include the entity-headers.  HTTP entity-body and
687   entity-header fields are defined in [Part3].
688
689   An entity-body is only present in a message when a message-body is
690   present, as described in Section 4.3 of [Part1].  The entity-body is
691   obtained from the message-body by decoding any Transfer-Encoding that
692   might have been applied to ensure safe and proper transfer of the
693   message.
694
695
6967.  Method Definitions
697
698   The set of common methods for HTTP/1.1 is defined below.  Although
699   this set can be expanded, additional methods cannot be assumed to
700   share the same semantics for separately extended clients and servers.
701
7027.1.  Safe and Idempotent Methods
703
7047.1.1.  Safe Methods
705
706   Implementors should be aware that the software represents the user in
707   their interactions over the Internet, and should be careful to allow
708   the user to be aware of any actions they might take which may have an
709   unexpected significance to themselves or others.
710
711   In particular, the convention has been established that the GET and
712   HEAD methods SHOULD NOT have the significance of taking an action
713   other than retrieval.  These methods ought to be considered "safe".
714   This allows user agents to represent other methods, such as POST, PUT
715   and DELETE, in a special way, so that the user is made aware of the
716   fact that a possibly unsafe action is being requested.
717
718   Naturally, it is not possible to ensure that the server does not
719   generate side-effects as a result of performing a GET request; in
720   fact, some dynamic resources consider that a feature.  The important
721   distinction here is that the user did not request the side-effects,
722   so therefore cannot be held accountable for them.
723
724
725
726
727Fielding, et al.       Expires September 10, 2009              [Page 13]
728
729Internet-Draft              HTTP/1.1, Part 2                  March 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 September 10, 2009              [Page 14]
784
785Internet-Draft              HTTP/1.1, Part 2                  March 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 September 10, 2009              [Page 15]
840
841Internet-Draft              HTTP/1.1, Part 2                  March 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 September 10, 2009              [Page 16]
896
897Internet-Draft              HTTP/1.1, Part 2                  March 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 September 10, 2009              [Page 17]
952
953Internet-Draft              HTTP/1.1, Part 2                  March 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 September 10, 2009              [Page 18]
1008
1009Internet-Draft              HTTP/1.1, Part 2                  March 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 a description of which
1037   method(s) it can follow and any metainformation required in the
1038   response.
1039
10408.1.  Informational 1xx
1041
1042   This class of status code indicates a provisional response,
1043   consisting only of the Status-Line and optional headers, and is
1044   terminated by an empty line.  There are no required headers for this
1045   class of status code.  Since HTTP/1.0 did not define any 1xx status
1046   codes, servers MUST NOT send a 1xx response to an HTTP/1.0 client
1047   except under experimental conditions.
1048
1049   A client MUST be prepared to accept one or more 1xx status responses
1050   prior to a regular response, even if the client does not expect a 100
1051   (Continue) status message.  Unexpected 1xx status responses MAY be
1052   ignored by a user agent.
1053
1054   Proxies MUST forward 1xx responses, unless the connection between the
1055   proxy and its client has been closed, or unless the proxy itself
1056   requested the generation of the 1xx response.  (For example, if a
1057   proxy adds a "Expect: 100-continue" field when it forwards a request,
1058   then it need not forward the corresponding 100 (Continue)
1059   response(s).)
1060
1061
1062
1063Fielding, et al.       Expires September 10, 2009              [Page 19]
1064
1065Internet-Draft              HTTP/1.1, Part 2                  March 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 September 10, 2009              [Page 20]
1120
1121Internet-Draft              HTTP/1.1, Part 2                  March 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 September 10, 2009              [Page 21]
1176
1177Internet-Draft              HTTP/1.1, Part 2                  March 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 September 10, 2009              [Page 22]
1232
1233Internet-Draft              HTTP/1.1, Part 2                  March 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 September 10, 2009              [Page 23]
1288
1289Internet-Draft              HTTP/1.1, Part 2                  March 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 September 10, 2009              [Page 24]
1344
1345Internet-Draft              HTTP/1.1, Part 2                  March 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 resource 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 September 10, 2009              [Page 25]
1400
1401Internet-Draft              HTTP/1.1, Part 2                  March 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 September 10, 2009              [Page 26]
1456
1457Internet-Draft              HTTP/1.1, Part 2                  March 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 September 10, 2009              [Page 27]
1512
1513Internet-Draft              HTTP/1.1, Part 2                  March 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 September 10, 2009              [Page 28]
1568
1569Internet-Draft              HTTP/1.1, Part 2                  March 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 September 10, 2009              [Page 29]
1624
1625Internet-Draft              HTTP/1.1, Part 2                  March 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 September 10, 2009              [Page 30]
1680
1681Internet-Draft              HTTP/1.1, Part 2                  March 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 September 10, 2009              [Page 31]
1736
1737Internet-Draft              HTTP/1.1, Part 2                  March 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 September 10, 2009              [Page 32]
1792
1793Internet-Draft              HTTP/1.1, Part 2                  March 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 September 10, 2009              [Page 33]
1848
1849Internet-Draft              HTTP/1.1, Part 2                  March 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 September 10, 2009              [Page 34]
1904
1905Internet-Draft              HTTP/1.1, Part 2                  March 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.)  The Referer request-header allows a
1914   server to generate lists of back-links to resources for interest,
1915   logging, optimized caching, etc.  It also allows obsolete or mistyped
1916   links to be traced for maintenance.  The Referer field MUST NOT be
1917   sent if the request-target was obtained from a source that does not
1918   have its own URI, such as input from the user keyboard.
1919
1920     Referer        = "Referer" ":" OWS Referer-v
1921     Referer-v      = absolute-URI / partial-URI
1922
1923   Example:
1924
1925     Referer: http://www.example.org/hypertext/Overview.html
1926
1927   If the field value is a relative URI, it SHOULD be interpreted
1928   relative to the request-target.  The URI MUST NOT include a fragment.
1929   See Section 11.2 for security considerations.
1930
19319.7.  Retry-After
1932
1933   The response-header "Retry-After" field can be used with a 503
1934   (Service Unavailable) response to indicate how long the service is
1935   expected to be unavailable to the requesting client.  This field MAY
1936   also be used with any 3xx (Redirection) response to indicate the
1937   minimum time the user-agent is asked wait before issuing the
1938   redirected request.  The value of this field can be either an HTTP-
1939   date or an integer number of seconds (in decimal) after the time of
1940   the response.
1941
1942     Retry-After   = "Retry-After" ":" OWS Retry-After-v
1943     Retry-After-v = HTTP-date / delta-seconds
1944
1945   Time spans are non-negative decimal integers, representing time in
1946   seconds.
1947
1948     delta-seconds  = 1*DIGIT
1949
1950   Two examples of its use are
1951
1952     Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
1953     Retry-After: 120
1954
1955   In the latter example, the delay is 2 minutes.
1956
1957
1958
1959Fielding, et al.       Expires September 10, 2009              [Page 35]
1960
1961Internet-Draft              HTTP/1.1, Part 2                  March 2009
1962
1963
19649.8.  Server
1965
1966   The response-header field "Server" contains information about the
1967   software used by the origin server to handle the request.  The field
1968   can contain multiple product tokens (Section 3.4 of [Part1]) and
1969   comments identifying the server and any significant subproducts.  The
1970   product tokens are listed in order of their significance for
1971   identifying the application.
1972
1973     Server         = "Server" ":" OWS Server-v
1974     Server-v       = product
1975                      *( RWS ( product / comment ) )
1976
1977   Example:
1978
1979     Server: CERN/3.0 libwww/2.17
1980
1981   If the response is being forwarded through a proxy, the proxy
1982   application MUST NOT modify the Server response-header.  Instead, it
1983   MUST include a Via field (as described in Section 8.9 of [Part1]).
1984
1985      Note: Revealing the specific software version of the server might
1986      allow the server machine to become more vulnerable to attacks
1987      against software that is known to contain security holes.  Server
1988      implementors are encouraged to make this field a configurable
1989      option.
1990
19919.9.  User-Agent
1992
1993   The request-header field "User-Agent" contains information about the
1994   user agent originating the request.  This is for statistical
1995   purposes, the tracing of protocol violations, and automated
1996   recognition of user agents for the sake of tailoring responses to
1997   avoid particular user agent limitations.  User agents SHOULD include
1998   this field with requests.  The field can contain multiple product
1999   tokens (Section 3.4 of [Part1]) and comments identifying the agent
2000   and any subproducts which form a significant part of the user agent.
2001   By convention, the product tokens are listed in order of their
2002   significance for identifying the application.
2003
2004     User-Agent     = "User-Agent" ":" OWS User-Agent-v
2005     User-Agent-v   = product
2006                      *( RWS ( product / comment ) )
2007
2008   Example:
2009
2010     User-Agent: CERN-LineMode/2.15 libwww/2.17b3
2011
2012
2013
2014
2015Fielding, et al.       Expires September 10, 2009              [Page 36]
2016
2017Internet-Draft              HTTP/1.1, Part 2                  March 2009
2018
2019
202010.  IANA Considerations
2021
202210.1.  Method Registry
2023
2024   The registration procedure for HTTP Methods is defined by Section 2.1
2025   of this document.
2026
2027   The HTTP Method Registry located at
2028   <http://www.iana.org/assignments/http-methods> should be populated
2029   with the registrations below:
2030
2031   +---------+------+-------------+
2032   | Method  | Safe | Reference   |
2033   +---------+------+-------------+
2034   | CONNECT | no   | Section 7.9 |
2035   | DELETE  | no   | Section 7.7 |
2036   | GET     | yes  | Section 7.3 |
2037   | HEAD    | yes  | Section 7.4 |
2038   | OPTIONS | yes  | Section 7.2 |
2039   | POST    | no   | Section 7.5 |
2040   | PUT     | no   | Section 7.6 |
2041   | TRACE   | yes  | Section 7.8 |
2042   +---------+------+-------------+
2043
204410.2.  Status Code Registry
2045
2046   The registration procedure for HTTP Status Codes -- previously
2047   defined in Section 7.1 of [RFC2817] -- is now defined by Section 4.1
2048   of this document.
2049
2050   The HTTP Status Code Registry located at
2051   <http://www.iana.org/assignments/http-status-codes> should be updated
2052   with the registrations below:
2053
2054
2055
2056
2057
2058
2059
2060
2061
2062
2063
2064
2065
2066
2067
2068
2069
2070
2071Fielding, et al.       Expires September 10, 2009              [Page 37]
2072
2073Internet-Draft              HTTP/1.1, Part 2                  March 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 September 10, 2009              [Page 38]
2128
2129Internet-Draft              HTTP/1.1, Part 2                  March 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 September 10, 2009              [Page 39]
2184
2185Internet-Draft              HTTP/1.1, Part 2                  March 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 September 10, 2009              [Page 40]
2240
2241Internet-Draft              HTTP/1.1, Part 2                  March 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-06
2266              (work in progress), March 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-06
2272              (work in progress), March 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-06 (work in
2278              progress), March 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-06 (work
2284              in progress), March 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              and J. Reschke, Ed., "HTTP/1.1, part 6: Caching",
2289              draft-ietf-httpbis-p6-cache-06 (work in progress),
2290              March 2009.
2291
2292
2293
2294
2295Fielding, et al.       Expires September 10, 2009              [Page 41]
2296
2297Internet-Draft              HTTP/1.1, Part 2                  March 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-06 (work in progress),
2304              March 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 September 10, 2009              [Page 42]
2352
2353Internet-Draft              HTTP/1.1, Part 2                  March 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 September 10, 2009              [Page 43]
2408
2409Internet-Draft              HTTP/1.1, Part 2                  March 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   In the description of the Server header, the Via field was described
2431   as a SHOULD.  The requirement was and is stated correctly in the
2432   description of the Via header in Section 8.9 of [Part1].
2433   (Section 9.8)
2434
2435
2436Appendix B.  Collected ABNF
2437
2438   Accept = <Accept, defined in [Part3], Section 5.1>
2439   Accept-Charset = <Accept-Charset, defined in [Part3], Section 5.2>
2440   Accept-Encoding = <Accept-Encoding, defined in [Part3], Section 5.3>
2441   Accept-Language = <Accept-Language, defined in [Part3], Section 5.4>
2442   Accept-Ranges = <Accept-Ranges, defined in [Part5], Section 5.1>
2443   Age = <Age, defined in [Part6], Section 3.1>
2444   Allow = "Allow:" OWS Allow-v
2445   Allow-v = [ ( "," / Method ) *( OWS "," [ OWS Method ] ) ]
2446   Authorization = <Authorization, defined in [Part7], Section 3.1>
2447
2448   ETag = <ETag, defined in [Part4], Section 6.1>
2449   Expect = "Expect:" OWS Expect-v
2450   Expect-v = *( "," OWS ) expectation *( OWS "," [ OWS expectation ] )
2451
2452   From = "From:" OWS From-v
2453   From-v = mailbox
2454
2455   HTTP-date = <HTTP-date, defined in [Part1], Section 3.2.1>
2456   Host = <Host, defined in [Part1], Section 2.1>
2457
2458   If-Match = <If-Match, defined in [Part4], Section 6.2>
2459
2460
2461
2462
2463Fielding, et al.       Expires September 10, 2009              [Page 44]
2464
2465Internet-Draft              HTTP/1.1, Part 2                  March 2009
2466
2467
2468   If-Modified-Since =
2469    <If-Modified-Since, defined in [Part4], Section 6.3>
2470   If-None-Match = <If-None-Match, defined in [Part4], Section 6.4>
2471   If-Range = <If-Range, defined in [Part5], Section 5.3>
2472   If-Unmodified-Since =
2473    <If-Unmodified-Since, defined in [Part4], Section 6.5>
2474
2475   Location = "Location:" OWS Location-v
2476   Location-v = absolute-URI [ "#" fragment ]
2477
2478   Max-Forwards = "Max-Forwards:" OWS Max-Forwards-v
2479   Max-Forwards-v = 1*DIGIT
2480   Method = %x4F.50.54.49.4F.4E.53 / %x47.45.54 / %x48.45.41.44 /
2481    %x50.4F.54 / %x50.55.54 / %x44.45.4C.45.54.45 / %x54.52.41.43.45 /
2482    %x43.4E.4E.45.43.54 / extension-method
2483
2484   OWS = <OWS, defined in [Part1], Section 1.2.2>
2485
2486   Proxy-Authenticate =
2487    <Proxy-Authenticate, defined in [Part7], Section 3.2>
2488   Proxy-Authorization =
2489    <Proxy-Authorization, defined in [Part7], Section 3.3>
2490
2491   RWS = <RWS, defined in [Part1], Section 1.2.2>
2492   Range = <Range, defined in [Part5], Section 5.4>
2493   Reason-Phrase = *( WSP / VCHAR / obs-text )
2494   Referer = "Referer:" OWS Referer-v
2495   Referer-v = absolute-URI / partial-URI
2496   Retry-After = "Retry-After:" OWS Retry-After-v
2497   Retry-After-v = HTTP-date / delta-seconds
2498
2499   Server = "Server:" OWS Server-v
2500   Server-v = product *( RWS ( product / comment ) )
2501   Status-Code = "100" / "101" / "200" / "201" / "202" / "203" / "204" /
2502    "205" / "206" / "300" / "301" / "302" / "303" / "304" / "305" /
2503    "307" / "400" / "401" / "402" / "403" / "404" / "405" / "406" /
2504    "407" / "408" / "409" / "410" / "411" / "412" / "413" / "414" /
2505    "415" / "416" / "417" / "500" / "501" / "502" / "503" / "504" /
2506    "505" / extension-code
2507
2508   TE = <TE, defined in [Part1], Section 8.8>
2509
2510   User-Agent = "User-Agent:" OWS User-Agent-v
2511   User-Agent-v = product *( RWS ( product / comment ) )
2512
2513   Vary = <Vary, defined in [Part6], Section 3.5>
2514
2515
2516
2517
2518
2519Fielding, et al.       Expires September 10, 2009              [Page 45]
2520
2521Internet-Draft              HTTP/1.1, Part 2                  March 2009
2522
2523
2524   WWW-Authenticate =
2525    <WWW-Authenticate, defined in [Part7], Section 3.4>
2526
2527   absolute-URI = <absolute-URI, defined in [Part1], Section 2.1>
2528
2529   comment = <comment, defined in [Part1], Section 1.2.2>
2530
2531   delta-seconds = 1*DIGIT
2532
2533   expect-params = ";" token [ "=" ( token / quoted-string ) ]
2534   expectation = "100-continue" / expectation-extension
2535   expectation-extension = token [ "=" ( token / quoted-string )
2536    *expect-params ]
2537   extension-code = 3DIGIT
2538   extension-method = token
2539
2540   fragment = <fragment, defined in [Part1], Section 2.1>
2541
2542   mailbox = <mailbox, defined in [RFC5322], Section 3.4>
2543
2544   obs-text = <obs-text, defined in [Part1], Section 1.2.2>
2545
2546   partial-URI = <partial-URI, defined in [Part1], Section 2.1>
2547   product = <product, defined in [Part1], Section 3.4>
2548
2549   quoted-string = <quoted-string, defined in [Part1], Section 1.2.2>
2550
2551   request-header = Accept / Accept-Charset / Accept-Encoding /
2552    Accept-Language / Authorization / Expect / From / Host / If-Match /
2553    If-Modified-Since / If-None-Match / If-Range / If-Unmodified-Since /
2554    Max-Forwards / Proxy-Authorization / Range / Referer / TE /
2555    User-Agent
2556   response-header = Accept-Ranges / Age / Allow / ETag / Location /
2557    Proxy-Authenticate / Retry-After / Server / Vary / WWW-Authenticate
2558
2559   token = <token, defined in [Part1], Section 1.2.2>
2560
2561
2562
2563   ABNF diagnostics:
2564
2565   ; Reason-Phrase defined but not used
2566   ; Status-Code defined but not used
2567   ; request-header defined but not used
2568   ; response-header defined but not used
2569
2570
2571
2572
2573
2574
2575Fielding, et al.       Expires September 10, 2009              [Page 46]
2576
2577Internet-Draft              HTTP/1.1, Part 2                  March 2009
2578
2579
2580Appendix C.  Change Log (to be removed by RFC Editor before publication)
2581
2582C.1.  Since RFC2616
2583
2584   Extracted relevant partitions from [RFC2616].
2585
2586C.2.  Since draft-ietf-httpbis-p2-semantics-00
2587
2588   Closed issues:
2589
2590   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/5>: "Via is a MUST"
2591      (<http://purl.org/NET/http-errata#via-must>)
2592
2593   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/6>: "Fragments
2594      allowed in Location"
2595      (<http://purl.org/NET/http-errata#location-fragments>)
2596
2597   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/10>: "Safe Methods
2598      vs Redirection" (<http://purl.org/NET/http-errata#saferedirect>)
2599
2600   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/17>: "Revise
2601      description of the POST method"
2602      (<http://purl.org/NET/http-errata#post>)
2603
2604   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and
2605      Informative references"
2606
2607   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/42>: "RFC2606
2608      Compliance"
2609
2610   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/65>: "Informative
2611      references"
2612
2613   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/84>: "Redundant
2614      cross-references"
2615
2616   Other changes:
2617
2618   o  Move definitions of 304 and 412 condition codes to [Part4]
2619
2620C.3.  Since draft-ietf-httpbis-p2-semantics-01
2621
2622   Closed issues:
2623
2624   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/21>: "PUT side
2625      effects"
2626
2627
2628
2629
2630
2631Fielding, et al.       Expires September 10, 2009              [Page 47]
2632
2633Internet-Draft              HTTP/1.1, Part 2                  March 2009
2634
2635
2636   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/91>: "Duplicate Host
2637      header requirements"
2638
2639   Ongoing work on ABNF conversion
2640   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
2641
2642   o  Move "Product Tokens" section (back) into Part 1, as "token" is
2643      used in the definition of the Upgrade header.
2644
2645   o  Add explicit references to BNF syntax and rules imported from
2646      other parts of the specification.
2647
2648   o  Copy definition of delta-seconds from Part6 instead of referencing
2649      it.
2650
2651C.4.  Since draft-ietf-httpbis-p2-semantics-02
2652
2653   Closed issues:
2654
2655   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/24>: "Requiring
2656      Allow in 405 responses"
2657
2658   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/59>: "Status Code
2659      Registry"
2660
2661   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/61>: "Redirection
2662      vs. Location"
2663
2664   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/70>: "Cacheability
2665      of 303 response"
2666
2667   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/76>: "305 Use Proxy"
2668
2669   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/105>:
2670      "Classification for Allow header"
2671
2672   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/112>: "PUT - 'store
2673      under' vs 'store at'"
2674
2675   Ongoing work on IANA Message Header Registration
2676   (<http://tools.ietf.org/wg/httpbis/trac/ticket/40>):
2677
2678   o  Reference RFC 3984, and update header registrations for headers
2679      defined in this document.
2680
2681   Ongoing work on ABNF conversion
2682   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
2683
2684
2685
2686
2687Fielding, et al.       Expires September 10, 2009              [Page 48]
2688
2689Internet-Draft              HTTP/1.1, Part 2                  March 2009
2690
2691
2692   o  Replace string literals when the string really is case-sensitive
2693      (method).
2694
2695C.5.  Since draft-ietf-httpbis-p2-semantics-03
2696
2697   Closed issues:
2698
2699   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/98>: "OPTIONS
2700      request bodies"
2701
2702   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/119>: "Description
2703      of CONNECT should refer to RFC2817"
2704
2705   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/125>: "Location
2706      Content-Location reference request/response mixup"
2707
2708   Ongoing work on Method Registry
2709   (<http://tools.ietf.org/wg/httpbis/trac/ticket/72>):
2710
2711   o  Added initial proposal for registration process, plus initial
2712      content (non-HTTP/1.1 methods to be added by a separate
2713      specification).
2714
2715C.6.  Since draft-ietf-httpbis-p2-semantics-04
2716
2717   Closed issues:
2718
2719   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/103>: "Content-*"
2720
2721   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/132>: "RFC 2822 is
2722      updated by RFC 5322"
2723
2724   Ongoing work on ABNF conversion
2725   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
2726
2727   o  Use "/" instead of "|" for alternatives.
2728
2729   o  Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
2730      whitespace ("OWS") and required whitespace ("RWS").
2731
2732   o  Rewrite ABNFs to spell out whitespace rules, factor out header
2733      value format definitions.
2734
2735C.7.  Since draft-ietf-httpbis-p2-semantics-05
2736
2737   Closed issues:
2738
2739
2740
2741
2742
2743Fielding, et al.       Expires September 10, 2009              [Page 49]
2744
2745Internet-Draft              HTTP/1.1, Part 2                  March 2009
2746
2747
2748   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/94>: "Reason-Phrase
2749      BNF"
2750
2751   Final work on ABNF conversion
2752   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
2753
2754   o  Add appendix containing collected and expanded ABNF, reorganize
2755      ABNF introduction.
2756
2757
2758Index
2759
2760   1
2761      100 Continue (status code)  20
2762      101 Switching Protocols (status code)  20
2763
2764   2
2765      200 OK (status code)  20
2766      201 Created (status code)  21
2767      202 Accepted (status code)  21
2768      203 Non-Authoritative Information (status code)  21
2769      204 No Content (status code)  22
2770      205 Reset Content (status code)  22
2771      206 Partial Content (status code)  22
2772
2773   3
2774      300 Multiple Choices (status code)  23
2775      301 Moved Permanently (status code)  23
2776      302 Found (status code)  24
2777      303 See Other (status code)  24
2778      304 Not Modified (status code)  25
2779      305 Use Proxy (status code)  25
2780      306 (Unused) (status code)  25
2781      307 Temporary Redirect (status code)  25
2782
2783   4
2784      400 Bad Request (status code)  26
2785      401 Unauthorized (status code)  26
2786      402 Payment Required (status code)  26
2787      403 Forbidden (status code)  26
2788      404 Not Found (status code)  27
2789      405 Method Not Allowed (status code)  27
2790      406 Not Acceptable (status code)  27
2791      407 Proxy Authentication Required (status code)  27
2792      408 Request Timeout (status code)  28
2793      409 Conflict (status code)  28
2794      410 Gone (status code)  28
2795      411 Length Required (status code)  29
2796
2797
2798
2799Fielding, et al.       Expires September 10, 2009              [Page 50]
2800
2801Internet-Draft              HTTP/1.1, Part 2                  March 2009
2802
2803
2804      412 Precondition Failed (status code)  29
2805      413 Request Entity Too Large (status code)  29
2806      414 URI Too Long (status code)  29
2807      415 Unsupported Media Type (status code)  29
2808      416 Requested Range Not Satisfiable (status code)  29
2809      417 Expectation Failed (status code)  30
2810
2811   5
2812      500 Internal Server Error (status code)  30
2813      501 Not Implemented (status code)  30
2814      502 Bad Gateway (status code)  30
2815      503 Service Unavailable (status code)  30
2816      504 Gateway Timeout (status code)  31
2817      505 HTTP Version Not Supported (status code)  31
2818
2819   A
2820      Allow header  31
2821
2822   C
2823      CONNECT method  19
2824
2825   D
2826      DELETE method  18
2827
2828   E
2829      Expect header  32
2830
2831   F
2832      From header  33
2833
2834   G
2835      GET method  15
2836      Grammar
2837         Allow  31
2838         Allow-v  31
2839         delta-seconds  35
2840         Expect  32
2841         expect-params  32
2842         Expect-v  32
2843         expectation  32
2844         expectation-extension  32
2845         extension-code  11
2846         extension-method  8
2847         From  33
2848         From-v  33
2849         Location  33
2850         Location-v  33
2851         Max-Forwards  34
2852
2853
2854
2855Fielding, et al.       Expires September 10, 2009              [Page 51]
2856
2857Internet-Draft              HTTP/1.1, Part 2                  March 2009
2858
2859
2860         Max-Forwards-v  34
2861         Method  8
2862         Reason-Phrase  11
2863         Referer  35
2864         Referer-v  35
2865         request-header  9
2866         response-header  12
2867         Retry-After  35
2868         Retry-After-v  35
2869         Server  36
2870         Server-v  36
2871         Status-Code  11
2872         User-Agent  36
2873         User-Agent-v  36
2874
2875   H
2876      HEAD method  16
2877      Headers
2878         Allow  31
2879         Expect  32
2880         From  33
2881         Location  33
2882         Max-Forwards  34
2883         Referer  35
2884         Retry-After  35
2885         Server  36
2886         User-Agent  36
2887
2888   I
2889      Idempotent Methods  14
2890
2891   L
2892      LINK method  43
2893      Location header  33
2894
2895   M
2896      Max-Forwards header  34
2897      Methods
2898         CONNECT  19
2899         DELETE  18
2900         GET  15
2901         HEAD  16
2902         LINK  43
2903         OPTIONS  14
2904         PATCH  43
2905         POST  16
2906         PUT  17
2907         TRACE  18
2908
2909
2910
2911Fielding, et al.       Expires September 10, 2009              [Page 52]
2912
2913Internet-Draft              HTTP/1.1, Part 2                  March 2009
2914
2915
2916         UNLINK  43
2917
2918   O
2919      OPTIONS method  14
2920
2921   P
2922      PATCH method  43
2923      POST method  16
2924      PUT method  17
2925
2926   R
2927      Referer header  35
2928      Retry-After header  35
2929
2930   S
2931      Safe Methods  13
2932      Server header  36
2933      Status Codes
2934         100 Continue  20
2935         101 Switching Protocols  20
2936         200 OK  20
2937         201 Created  21
2938         202 Accepted  21
2939         203 Non-Authoritative Information  21
2940         204 No Content  22
2941         205 Reset Content  22
2942         206 Partial Content  22
2943         300 Multiple Choices  23
2944         301 Moved Permanently  23
2945         302 Found  24
2946         303 See Other  24
2947         304 Not Modified  25
2948         305 Use Proxy  25
2949         306 (Unused)  25
2950         307 Temporary Redirect  25
2951         400 Bad Request  26
2952         401 Unauthorized  26
2953         402 Payment Required  26
2954         403 Forbidden  26
2955         404 Not Found  27
2956         405 Method Not Allowed  27
2957         406 Not Acceptable  27
2958         407 Proxy Authentication Required  27
2959         408 Request Timeout  28
2960         409 Conflict  28
2961         410 Gone  28
2962         411 Length Required  29
2963         412 Precondition Failed  29
2964
2965
2966
2967Fielding, et al.       Expires September 10, 2009              [Page 53]
2968
2969Internet-Draft              HTTP/1.1, Part 2                  March 2009
2970
2971
2972         413 Request Entity Too Large  29
2973         414 URI Too Long  29
2974         415 Unsupported Media Type  29
2975         416 Requested Range Not Satisfiable  29
2976         417 Expectation Failed  30
2977         500 Internal Server Error  30
2978         501 Not Implemented  30
2979         502 Bad Gateway  30
2980         503 Service Unavailable  30
2981         504 Gateway Timeout  31
2982         505 HTTP Version Not Supported  31
2983
2984   T
2985      TRACE method  18
2986
2987   U
2988      UNLINK method  43
2989      User-Agent header  36
2990
2991
2992Authors' Addresses
2993
2994   Roy T. Fielding (editor)
2995   Day Software
2996   23 Corporate Plaza DR, Suite 280
2997   Newport Beach, CA  92660
2998   USA
2999
3000   Phone: +1-949-706-5300
3001   Fax:   +1-949-706-5305
3002   Email: fielding@gbiv.com
3003   URI:   http://roy.gbiv.com/
3004
3005
3006   Jim Gettys
3007   One Laptop per Child
3008   21 Oak Knoll Road
3009   Carlisle, MA  01741
3010   USA
3011
3012   Email: jg@laptop.org
3013   URI:   http://www.laptop.org/
3014
3015
3016
3017
3018
3019
3020
3021
3022
3023Fielding, et al.       Expires September 10, 2009              [Page 54]
3024
3025Internet-Draft              HTTP/1.1, Part 2                  March 2009
3026
3027
3028   Jeffrey C. Mogul
3029   Hewlett-Packard Company
3030   HP Labs, Large Scale Systems Group
3031   1501 Page Mill Road, MS 1177
3032   Palo Alto, CA  94304
3033   USA
3034
3035   Email: JeffMogul@acm.org
3036
3037
3038   Henrik Frystyk Nielsen
3039   Microsoft Corporation
3040   1 Microsoft Way
3041   Redmond, WA  98052
3042   USA
3043
3044   Email: henrikn@microsoft.com
3045
3046
3047   Larry Masinter
3048   Adobe Systems, Incorporated
3049   345 Park Ave
3050   San Jose, CA  95110
3051   USA
3052
3053   Email: LMM@acm.org
3054   URI:   http://larry.masinter.net/
3055
3056
3057   Paul J. Leach
3058   Microsoft Corporation
3059   1 Microsoft Way
3060   Redmond, WA  98052
3061
3062   Email: paulle@microsoft.com
3063
3064
3065   Tim Berners-Lee
3066   World Wide Web Consortium
3067   MIT Computer Science and Artificial Intelligence Laboratory
3068   The Stata Center, Building 32
3069   32 Vassar Street
3070   Cambridge, MA  02139
3071   USA
3072
3073   Email: timbl@w3.org
3074   URI:   http://www.w3.org/People/Berners-Lee/
3075
3076
3077
3078
3079Fielding, et al.       Expires September 10, 2009              [Page 55]
3080
3081Internet-Draft              HTTP/1.1, Part 2                  March 2009
3082
3083
3084   Yves Lafon (editor)
3085   World Wide Web Consortium
3086   W3C / ERCIM
3087   2004, rte des Lucioles
3088   Sophia-Antipolis, AM  06902
3089   France
3090
3091   Email: ylafon@w3.org
3092   URI:   http://www.raubacapeu.net/people/yves/
3093
3094
3095   Julian F. Reschke (editor)
3096   greenbytes GmbH
3097   Hafenweg 16
3098   Muenster, NW  48155
3099   Germany
3100
3101   Phone: +49 251 2807760
3102   Fax:   +49 251 2807761
3103   Email: julian.reschke@greenbytes.de
3104   URI:   http://greenbytes.de/tech/webdav/
3105
3106
3107
3108
3109
3110
3111
3112
3113
3114
3115
3116
3117
3118
3119
3120
3121
3122
3123
3124
3125
3126
3127
3128
3129
3130
3131
3132
3133
3134
3135Fielding, et al.       Expires September 10, 2009              [Page 56]
3136
Note: See TracBrowser for help on using the repository browser.