source: draft-ietf-httpbis/05/draft-ietf-httpbis-p2-semantics-05.txt @ 877

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

remove executable and set eol-style for earlier drafts

  • Property svn:eol-style set to native
File size: 112.0 KB
Line 
1
2
3
4Network 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: May 20, 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                                                       November 16, 2008
23
24
25                  HTTP/1.1, part 2: Message Semantics
26                   draft-ietf-httpbis-p2-semantics-05
27
28Status of this Memo
29
30   By submitting this Internet-Draft, each author represents that any
31   applicable patent or other IPR claims of which he or she is aware
32   have been or will be disclosed, and any of which he or she becomes
33   aware will be disclosed, in accordance with Section 6 of BCP 79.
34
35   Internet-Drafts are working documents of the Internet Engineering
36   Task Force (IETF), its areas, and its working groups.  Note that
37   other groups may also distribute working documents as Internet-
38   Drafts.
39
40   Internet-Drafts are draft documents valid for a maximum of six months
41   and may be updated, replaced, or obsoleted by other documents at any
42   time.  It is inappropriate to use Internet-Drafts as reference
43   material or to cite them other than as "work in progress."
44
45   The list of current Internet-Drafts can be accessed at
46   http://www.ietf.org/ietf/1id-abstracts.txt.
47
48   The list of Internet-Draft Shadow Directories can be accessed at
49   http://www.ietf.org/shadow.html.
50
51   This Internet-Draft will expire on May 20, 2009.
52
53
54
55Fielding, et al.          Expires May 20, 2009                  [Page 1]
56
57Internet-Draft              HTTP/1.1, Part 2               November 2008
58
59
60Abstract
61
62   The Hypertext Transfer Protocol (HTTP) is an application-level
63   protocol for distributed, collaborative, hypermedia information
64   systems.  HTTP has been in use by the World Wide Web global
65   information initiative since 1990.  This document is Part 2 of the
66   seven-part specification that defines the protocol referred to as
67   "HTTP/1.1" and, taken together, obsoletes RFC 2616.  Part 2 defines
68   the semantics of HTTP messages as expressed by request methods,
69   request-header fields, response status codes, and response-header
70   fields.
71
72Editorial Note (To be removed by RFC Editor)
73
74   Discussion of this draft should take place on the HTTPBIS working
75   group mailing list (ietf-http-wg@w3.org).  The current issues list is
76   at <http://tools.ietf.org/wg/httpbis/trac/report/11> and related
77   documents (including fancy diffs) can be found at
78   <http://tools.ietf.org/wg/httpbis/>.
79
80   The changes in this draft are summarized in Appendix B.6.
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111Fielding, et al.          Expires May 20, 2009                  [Page 2]
112
113Internet-Draft              HTTP/1.1, Part 2               November 2008
114
115
116Table of Contents
117
118   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  6
119     1.1.  Requirements . . . . . . . . . . . . . . . . . . . . . . .  6
120   2.  Notational Conventions and Generic Grammar . . . . . . . . . .  6
121   3.  Method . . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
122     3.1.  Method Registry  . . . . . . . . . . . . . . . . . . . . .  8
123   4.  Request Header Fields  . . . . . . . . . . . . . . . . . . . .  9
124   5.  Status Code and Reason Phrase  . . . . . . . . . . . . . . . . 10
125     5.1.  Status Code Registry . . . . . . . . . . . . . . . . . . . 12
126   6.  Response Header Fields . . . . . . . . . . . . . . . . . . . . 12
127   7.  Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
128   8.  Method Definitions . . . . . . . . . . . . . . . . . . . . . . 13
129     8.1.  Safe and Idempotent Methods  . . . . . . . . . . . . . . . 13
130       8.1.1.  Safe Methods . . . . . . . . . . . . . . . . . . . . . 13
131       8.1.2.  Idempotent Methods . . . . . . . . . . . . . . . . . . 14
132     8.2.  OPTIONS  . . . . . . . . . . . . . . . . . . . . . . . . . 14
133     8.3.  GET  . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
134     8.4.  HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
135     8.5.  POST . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
136     8.6.  PUT  . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
137     8.7.  DELETE . . . . . . . . . . . . . . . . . . . . . . . . . . 18
138     8.8.  TRACE  . . . . . . . . . . . . . . . . . . . . . . . . . . 18
139     8.9.  CONNECT  . . . . . . . . . . . . . . . . . . . . . . . . . 19
140   9.  Status Code Definitions  . . . . . . . . . . . . . . . . . . . 19
141     9.1.  Informational 1xx  . . . . . . . . . . . . . . . . . . . . 19
142       9.1.1.  100 Continue . . . . . . . . . . . . . . . . . . . . . 19
143       9.1.2.  101 Switching Protocols  . . . . . . . . . . . . . . . 20
144     9.2.  Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 20
145       9.2.1.  200 OK . . . . . . . . . . . . . . . . . . . . . . . . 20
146       9.2.2.  201 Created  . . . . . . . . . . . . . . . . . . . . . 20
147       9.2.3.  202 Accepted . . . . . . . . . . . . . . . . . . . . . 21
148       9.2.4.  203 Non-Authoritative Information  . . . . . . . . . . 21
149       9.2.5.  204 No Content . . . . . . . . . . . . . . . . . . . . 21
150       9.2.6.  205 Reset Content  . . . . . . . . . . . . . . . . . . 22
151       9.2.7.  206 Partial Content  . . . . . . . . . . . . . . . . . 22
152     9.3.  Redirection 3xx  . . . . . . . . . . . . . . . . . . . . . 22
153       9.3.1.  300 Multiple Choices . . . . . . . . . . . . . . . . . 22
154       9.3.2.  301 Moved Permanently  . . . . . . . . . . . . . . . . 23
155       9.3.3.  302 Found  . . . . . . . . . . . . . . . . . . . . . . 23
156       9.3.4.  303 See Other  . . . . . . . . . . . . . . . . . . . . 24
157       9.3.5.  304 Not Modified . . . . . . . . . . . . . . . . . . . 25
158       9.3.6.  305 Use Proxy  . . . . . . . . . . . . . . . . . . . . 25
159       9.3.7.  306 (Unused) . . . . . . . . . . . . . . . . . . . . . 25
160       9.3.8.  307 Temporary Redirect . . . . . . . . . . . . . . . . 25
161     9.4.  Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 25
162       9.4.1.  400 Bad Request  . . . . . . . . . . . . . . . . . . . 26
163       9.4.2.  401 Unauthorized . . . . . . . . . . . . . . . . . . . 26
164
165
166
167Fielding, et al.          Expires May 20, 2009                  [Page 3]
168
169Internet-Draft              HTTP/1.1, Part 2               November 2008
170
171
172       9.4.3.  402 Payment Required . . . . . . . . . . . . . . . . . 26
173       9.4.4.  403 Forbidden  . . . . . . . . . . . . . . . . . . . . 26
174       9.4.5.  404 Not Found  . . . . . . . . . . . . . . . . . . . . 26
175       9.4.6.  405 Method Not Allowed . . . . . . . . . . . . . . . . 27
176       9.4.7.  406 Not Acceptable . . . . . . . . . . . . . . . . . . 27
177       9.4.8.  407 Proxy Authentication Required  . . . . . . . . . . 27
178       9.4.9.  408 Request Timeout  . . . . . . . . . . . . . . . . . 27
179       9.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 27
180       9.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 28
181       9.4.12. 411 Length Required  . . . . . . . . . . . . . . . . . 28
182       9.4.13. 412 Precondition Failed  . . . . . . . . . . . . . . . 28
183       9.4.14. 413 Request Entity Too Large . . . . . . . . . . . . . 29
184       9.4.15. 414 Request-URI Too Long . . . . . . . . . . . . . . . 29
185       9.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . . 29
186       9.4.17. 416 Requested Range Not Satisfiable  . . . . . . . . . 29
187       9.4.18. 417 Expectation Failed . . . . . . . . . . . . . . . . 29
188     9.5.  Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 29
189       9.5.1.  500 Internal Server Error  . . . . . . . . . . . . . . 30
190       9.5.2.  501 Not Implemented  . . . . . . . . . . . . . . . . . 30
191       9.5.3.  502 Bad Gateway  . . . . . . . . . . . . . . . . . . . 30
192       9.5.4.  503 Service Unavailable  . . . . . . . . . . . . . . . 30
193       9.5.5.  504 Gateway Timeout  . . . . . . . . . . . . . . . . . 30
194       9.5.6.  505 HTTP Version Not Supported . . . . . . . . . . . . 31
195   10. Header Field Definitions . . . . . . . . . . . . . . . . . . . 31
196     10.1. Allow  . . . . . . . . . . . . . . . . . . . . . . . . . . 31
197     10.2. Expect . . . . . . . . . . . . . . . . . . . . . . . . . . 31
198     10.3. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
199     10.4. Location . . . . . . . . . . . . . . . . . . . . . . . . . 33
200     10.5. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . . 34
201     10.6. Referer  . . . . . . . . . . . . . . . . . . . . . . . . . 34
202     10.7. Retry-After  . . . . . . . . . . . . . . . . . . . . . . . 35
203     10.8. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 35
204     10.9. User-Agent . . . . . . . . . . . . . . . . . . . . . . . . 36
205   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 36
206     11.1. Method Registry  . . . . . . . . . . . . . . . . . . . . . 36
207     11.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 37
208     11.3. Message Header Registration  . . . . . . . . . . . . . . . 39
209   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 39
210     12.1. Transfer of Sensitive Information  . . . . . . . . . . . . 39
211     12.2. Encoding Sensitive Information in URIs . . . . . . . . . . 40
212     12.3. Location Headers and Spoofing  . . . . . . . . . . . . . . 41
213   13. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 41
214   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41
215     14.1. Normative References . . . . . . . . . . . . . . . . . . . 41
216     14.2. Informative References . . . . . . . . . . . . . . . . . . 42
217   Appendix A.  Compatibility with Previous Versions  . . . . . . . . 42
218     A.1.  Changes from RFC 2068  . . . . . . . . . . . . . . . . . . 42
219     A.2.  Changes from RFC 2616  . . . . . . . . . . . . . . . . . . 43
220
221
222
223Fielding, et al.          Expires May 20, 2009                  [Page 4]
224
225Internet-Draft              HTTP/1.1, Part 2               November 2008
226
227
228   Appendix B.  Change Log (to be removed by RFC Editor before
229                publication)  . . . . . . . . . . . . . . . . . . . . 44
230     B.1.  Since RFC2616  . . . . . . . . . . . . . . . . . . . . . . 44
231     B.2.  Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 44
232     B.3.  Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . . 45
233     B.4.  Since draft-ietf-httpbis-p2-semantics-02 . . . . . . . . . 45
234     B.5.  Since draft-ietf-httpbis-p2-semantics-03 . . . . . . . . . 46
235     B.6.  Since draft-ietf-httpbis-p2-semantics-04 . . . . . . . . . 46
236   Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
237   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51
238   Intellectual Property and Copyright Statements . . . . . . . . . . 54
239
240
241
242
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 May 20, 2009                  [Page 5]
280
281Internet-Draft              HTTP/1.1, Part 2               November 2008
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
321
3222.  Notational Conventions and Generic Grammar
323
324   This specification uses the ABNF syntax defined in Section 2.1 of
325   [Part1] and the core rules defined in Section 2.2 of [Part1]:
326
327     DIGIT         = <DIGIT, defined in [Part1], Section 2.2>
328
329
330
331
332
333
334
335Fielding, et al.          Expires May 20, 2009                  [Page 6]
336
337Internet-Draft              HTTP/1.1, Part 2               November 2008
338
339
340     comment       = <comment, defined in [Part1], Section 2.2>
341     quoted-string = <quoted-string, defined in [Part1], Section 2.2>
342     token         = <token, defined in [Part1], Section 2.2>
343     OWS           = <OWS, defined in [Part1], Section 2.2>
344     RWS           = <RWS, defined in [Part1], Section 2.2>
345
346   The ABNF rules below are defined in other parts:
347
348     absolute-URI  = <absolute-URI, defined in [Part1], Section 3.2>
349     fragment      = <fragment, defined in [Part1], Section 3.2>
350     Host          = <Host, defined in [Part1], Section 3.2>
351     HTTP-date     = <HTTP-date, defined in [Part1], Section 3.3.1>
352     product       = <product, defined in [Part1], Section 3.5>
353     relativeURI   = <relativeURI, defined in [Part1], Section 3.2>
354     TE            = <TE, defined in [Part1], Section 8.8>
355
356
357     Accept        = <Accept, defined in [Part3], Section 6.1>
358     Accept-Charset =
359                <Accept-Charset, defined in [Part3], Section 6.2>
360     Accept-Encoding =
361                <Accept-Encoding, defined in [Part3], Section 6.3>
362     Accept-Language =
363                <Accept-Language, defined in [Part3], Section 6.4>
364
365
366     ETag          = <ETag, defined in [Part4], Section 7.1>
367     If-Match      = <If-Match, defined in [Part4], Section 7.2>
368     If-Modified-Since =
369                <If-Modified-Since, defined in [Part4], Section 7.3>
370     If-None-Match = <If-None-Match, defined in [Part4], Section 7.4>
371     If-Unmodified-Since =
372                <If-Unmodified-Since, defined in [Part4], Section 7.5>
373
374
375     Accept-Ranges = <Accept-Ranges, defined in [Part5], Section 6.1>
376     If-Range      = <If-Range, defined in [Part5], Section 6.3>
377     Range         = <Range, defined in [Part5], Section 6.4>
378
379
380     Age           = <Age, defined in [Part6], Section 16.1>
381     Vary          = <Vary, defined in [Part6], Section 16.5>
382
383
384
385
386
387
388
389
390
391Fielding, et al.          Expires May 20, 2009                  [Page 7]
392
393Internet-Draft              HTTP/1.1, Part 2               November 2008
394
395
396     Authorization = <Authorization, defined in [Part7], Section 4.1>
397     Proxy-Authenticate =
398                <Proxy-Authenticate, defined in [Part7], Section 4.2>
399     Proxy-Authorization =
400                <Proxy-Authorization, defined in [Part7], Section 4.3>
401     WWW-Authenticate =
402                <WWW-Authenticate, defined in [Part7], Section 4.4>
403
404
4053.  Method
406
407   The Method token indicates the method to be performed on the resource
408   identified by the Request-URI.  The method is case-sensitive.
409
410     Method         = %x4F.50.54.49.4F.4E.53   ; "OPTIONS", Section 8.2
411                    / %x47.45.54               ; "GET", Section 8.3
412                    / %x48.45.41.44            ; "HEAD", Section 8.4
413                    / %x50.4F.53.54            ; "POST", Section 8.5
414                    / %x50.55.54               ; "PUT", Section 8.6
415                    / %x44.45.4C.45.54.45      ; "DELETE", Section 8.7
416                    / %x54.52.41.43.45         ; "TRACE", Section 8.8
417                    / %x43.4F.4E.4E.45.43.54   ; "CONNECT", Section 8.9
418                    / extension-method
419     extension-method = token
420
421   The list of methods allowed by a resource can be specified in an
422   Allow header field (Section 10.1).  The return code of the response
423   always notifies the client whether a method is currently allowed on a
424   resource, since the set of allowed methods can change dynamically.
425   An origin server SHOULD return the status code 405 (Method Not
426   Allowed) if the method is known by the origin server but not allowed
427   for the requested resource, and 501 (Not Implemented) if the method
428   is unrecognized or not implemented by the origin server.  The methods
429   GET and HEAD MUST be supported by all general-purpose servers.  All
430   other methods are OPTIONAL; however, if the above methods are
431   implemented, they MUST be implemented with the same semantics as
432   those specified in Section 8.
433
4343.1.  Method Registry
435
436   The HTTP Method Registry defines the name space for the Method token
437   in the Request line of an HTTP request.
438
439   Registrations MUST include the following fields:
440
441   o  Method Name (see Section 3)
442
443
444
445
446
447Fielding, et al.          Expires May 20, 2009                  [Page 8]
448
449Internet-Draft              HTTP/1.1, Part 2               November 2008
450
451
452   o  Safe ("yes" or "no", see Section 8.1.1)
453
454   o  Pointer to specification text
455
456   Values to be added to this name space are subject to IETF review
457   ([RFC5226], Section 4.1).  Any document registering new method names
458   should be traceable through statuses of either 'Obsoletes' or
459   'Updates' to this document.
460
461   The registry itself is maintained at
462   <http://www.iana.org/assignments/http-methods>.
463
464
4654.  Request Header Fields
466
467   The request-header fields allow the client to pass additional
468   information about the request, and about the client itself, to the
469   server.  These fields act as request modifiers, with semantics
470   equivalent to the parameters on a programming language method
471   invocation.
472
473     request-header = Accept                   ; [Part3], Section 6.1
474                    / Accept-Charset           ; [Part3], Section 6.2
475                    / Accept-Encoding          ; [Part3], Section 6.3
476                    / Accept-Language          ; [Part3], Section 6.4
477                    / Authorization            ; [Part7], Section 4.1
478                    / Expect                   ; Section 10.2
479                    / From                     ; Section 10.3
480                    / Host                     ; [Part1], Section 8.4
481                    / If-Match                 ; [Part4], Section 7.2
482                    / If-Modified-Since        ; [Part4], Section 7.3
483                    / If-None-Match            ; [Part4], Section 7.4
484                    / If-Range                 ; [Part5], Section 6.3
485                    / If-Unmodified-Since      ; [Part4], Section 7.5
486                    / Max-Forwards             ; Section 10.5
487                    / Proxy-Authorization      ; [Part7], Section 4.3
488                    / Range                    ; [Part5], Section 6.4
489                    / Referer                  ; Section 10.6
490                    / TE                       ; [Part1], Section 8.8
491                    / User-Agent               ; Section 10.9
492
493   Request-header field names can be extended reliably only in
494   combination with a change in the protocol version.  However, new or
495   experimental header fields MAY be given the semantics of request-
496   header fields if all parties in the communication recognize them to
497   be request-header fields.  Unrecognized header fields are treated as
498   entity-header fields.
499
500
501
502
503Fielding, et al.          Expires May 20, 2009                  [Page 9]
504
505Internet-Draft              HTTP/1.1, Part 2               November 2008
506
507
5085.  Status Code and Reason Phrase
509
510   The Status-Code element is a 3-digit integer result code of the
511   attempt to understand and satisfy the request.  The status codes
512   listed below are defined in Section 9.  The Reason-Phrase is intended
513   to give a short textual description of the Status-Code.  The Status-
514   Code is intended for use by automata and the Reason-Phrase is
515   intended for the human user.  The client is not required to examine
516   or display the Reason-Phrase.
517
518   The individual values of the numeric status codes defined for
519   HTTP/1.1, and an example set of corresponding Reason-Phrase's, are
520   presented below.  The reason phrases listed here are only
521   recommendations -- they MAY be replaced by local equivalents without
522   affecting the protocol.
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559Fielding, et al.          Expires May 20, 2009                 [Page 10]
560
561Internet-Draft              HTTP/1.1, Part 2               November 2008
562
563
564     Status-Code    =
565            "100"  ; Section 9.1.1: Continue
566          / "101"  ; Section 9.1.2: Switching Protocols
567          / "200"  ; Section 9.2.1: OK
568          / "201"  ; Section 9.2.2: Created
569          / "202"  ; Section 9.2.3: Accepted
570          / "203"  ; Section 9.2.4: Non-Authoritative Information
571          / "204"  ; Section 9.2.5: No Content
572          / "205"  ; Section 9.2.6: Reset Content
573          / "206"  ; Section 9.2.7: Partial Content
574          / "300"  ; Section 9.3.1: Multiple Choices
575          / "301"  ; Section 9.3.2: Moved Permanently
576          / "302"  ; Section 9.3.3: Found
577          / "303"  ; Section 9.3.4: See Other
578          / "304"  ; Section 9.3.5: Not Modified
579          / "305"  ; Section 9.3.6: Use Proxy
580          / "307"  ; Section 9.3.8: Temporary Redirect
581          / "400"  ; Section 9.4.1: Bad Request
582          / "401"  ; Section 9.4.2: Unauthorized
583          / "402"  ; Section 9.4.3: Payment Required
584          / "403"  ; Section 9.4.4: Forbidden
585          / "404"  ; Section 9.4.5: Not Found
586          / "405"  ; Section 9.4.6: Method Not Allowed
587          / "406"  ; Section 9.4.7: Not Acceptable
588          / "407"  ; Section 9.4.8: Proxy Authentication Required
589          / "408"  ; Section 9.4.9: Request Time-out
590          / "409"  ; Section 9.4.10: Conflict
591          / "410"  ; Section 9.4.11: Gone
592          / "411"  ; Section 9.4.12: Length Required
593          / "412"  ; Section 9.4.13: Precondition Failed
594          / "413"  ; Section 9.4.14: Request Entity Too Large
595          / "414"  ; Section 9.4.15: Request-URI Too Large
596          / "415"  ; Section 9.4.16: Unsupported Media Type
597          / "416"  ; Section 9.4.17: Requested range not satisfiable
598          / "417"  ; Section 9.4.18: Expectation Failed
599          / "500"  ; Section 9.5.1: Internal Server Error
600          / "501"  ; Section 9.5.2: Not Implemented
601          / "502"  ; Section 9.5.3: Bad Gateway
602          / "503"  ; Section 9.5.4: Service Unavailable
603          / "504"  ; Section 9.5.5: Gateway Time-out
604          / "505"  ; Section 9.5.6: HTTP Version not supported
605          / extension-code
606
607     extension-code = 3DIGIT
608     Reason-Phrase  = *<TEXT, excluding CR, LF>
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 May 20, 2009                 [Page 11]
616
617Internet-Draft              HTTP/1.1, Part 2               November 2008
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
6325.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
6466.  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-URI.
652
653     response-header = Accept-Ranges           ; [Part5], Section 6.1
654                     / Age                     ; [Part6], Section 16.1
655                     / Allow                   ; Section 10.1
656                     / ETag                    ; [Part4], Section 7.1
657                     / Location                ; Section 10.4
658                     / Proxy-Authenticate      ; [Part7], Section 4.2
659                     / Retry-After             ; Section 10.7
660                     / Server                  ; Section 10.8
661                     / Vary                    ; [Part6], Section 16.5
662                     / WWW-Authenticate        ; [Part7], Section 4.4
663
664   Response-header field names can be extended reliably only in
665   combination with a change in the protocol version.  However, new or
666   experimental header fields MAY be given the semantics of response-
667   header fields if all parties in the communication recognize them to
668
669
670
671Fielding, et al.          Expires May 20, 2009                 [Page 12]
672
673Internet-Draft              HTTP/1.1, Part 2               November 2008
674
675
676   be response-header fields.  Unrecognized header fields are treated as
677   entity-header fields.
678
679
6807.  Entity
681
682   Request and Response messages MAY transfer an entity if not otherwise
683   restricted by the request method or response status code.  An entity
684   consists of entity-header fields and an entity-body, although some
685   responses will only include the entity-headers.  HTTP entity-body and
686   entity-header fields are defined in [Part3].
687
688   An entity-body is only present in a message when a message-body is
689   present, as described in Section 4.3 of [Part1].  The entity-body is
690   obtained from the message-body by decoding any Transfer-Encoding that
691   might have been applied to ensure safe and proper transfer of the
692   message.
693
694
6958.  Method Definitions
696
697   The set of common methods for HTTP/1.1 is defined below.  Although
698   this set can be expanded, additional methods cannot be assumed to
699   share the same semantics for separately extended clients and servers.
700
7018.1.  Safe and Idempotent Methods
702
7038.1.1.  Safe Methods
704
705   Implementors should be aware that the software represents the user in
706   their interactions over the Internet, and should be careful to allow
707   the user to be aware of any actions they might take which may have an
708   unexpected significance to themselves or others.
709
710   In particular, the convention has been established that the GET and
711   HEAD methods SHOULD NOT have the significance of taking an action
712   other than retrieval.  These methods ought to be considered "safe".
713   This allows user agents to represent other methods, such as POST, PUT
714   and DELETE, in a special way, so that the user is made aware of the
715   fact that a possibly unsafe action is being requested.
716
717   Naturally, it is not possible to ensure that the server does not
718   generate side-effects as a result of performing a GET request; in
719   fact, some dynamic resources consider that a feature.  The important
720   distinction here is that the user did not request the side-effects,
721   so therefore cannot be held accountable for them.
722
723
724
725
726
727Fielding, et al.          Expires May 20, 2009                 [Page 13]
728
729Internet-Draft              HTTP/1.1, Part 2               November 2008
730
731
7328.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
7528.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-URI.  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-URI 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-URI 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 May 20, 2009                 [Page 14]
784
785Internet-Draft              HTTP/1.1, Part 2               November 2008
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
8138.3.  GET
814
815   The GET method means retrieve whatever information (in the form of an
816   entity) is identified by the Request-URI.  If the Request-URI refers
817   to a data-producing process, it is the produced data which shall be
818   returned as the entity in the response and not the source text of the
819   process, unless that text happens to be the output of the process.
820
821   The semantics of the GET method change to a "conditional GET" if the
822   request message includes an If-Modified-Since, If-Unmodified-Since,
823   If-Match, If-None-Match, or If-Range header field.  A conditional GET
824   method requests that the entity be transferred only under the
825   circumstances described by the conditional header field(s).  The
826   conditional GET method is intended to reduce unnecessary network
827   usage by allowing cached entities to be refreshed without requiring
828   multiple requests or transferring data already held by the client.
829
830   The semantics of the GET method change to a "partial GET" if the
831   request message includes a Range header field.  A partial GET
832   requests that only part of the entity be transferred, as described in
833   Section 6.4 of [Part5].  The partial GET method is intended to reduce
834   unnecessary network usage by allowing partially-retrieved entities to
835   be completed without transferring data already held by the client.
836
837
838
839Fielding, et al.          Expires May 20, 2009                 [Page 15]
840
841Internet-Draft              HTTP/1.1, Part 2               November 2008
842
843
844   The response to a GET request is cacheable if and only if it meets
845   the requirements for HTTP caching described in [Part6].
846
847   See Section 12.2 for security considerations when used for forms.
848
8498.4.  HEAD
850
851   The HEAD method is identical to GET except that the server MUST NOT
852   return a message-body in the response.  The metainformation contained
853   in the HTTP headers in response to a HEAD request SHOULD be identical
854   to the information sent in response to a GET request.  This method
855   can be used for obtaining metainformation about the entity implied by
856   the request without transferring the entity-body itself.  This method
857   is often used for testing hypertext links for validity,
858   accessibility, and recent modification.
859
860   The response to a HEAD request MAY be cacheable in the sense that the
861   information contained in the response MAY be used to update a
862   previously cached entity from that resource.  If the new field values
863   indicate that the cached entity differs from the current entity (as
864   would be indicated by a change in Content-Length, Content-MD5, ETag
865   or Last-Modified), then the cache MUST treat the cache entry as
866   stale.
867
8688.5.  POST
869
870   The POST method is used to request that the origin server accept the
871   entity enclosed in the request as data to be processed by the
872   resource identified by the Request-URI in the Request-Line.  POST is
873   designed to allow a uniform method to cover the following functions:
874
875   o  Annotation of existing resources;
876
877   o  Posting a message to a bulletin board, newsgroup, mailing list, or
878      similar group of articles;
879
880   o  Providing a block of data, such as the result of submitting a
881      form, to a data-handling process;
882
883   o  Extending a database through an append operation.
884
885   The actual function performed by the POST method is determined by the
886   server and is usually dependent on the Request-URI.
887
888   The action performed by the POST method might not result in a
889   resource that can be identified by a URI.  In this case, either 200
890   (OK) or 204 (No Content) is the appropriate response status,
891   depending on whether or not the response includes an entity that
892
893
894
895Fielding, et al.          Expires May 20, 2009                 [Page 16]
896
897Internet-Draft              HTTP/1.1, Part 2               November 2008
898
899
900   describes the result.
901
902   If a resource has been created on the origin server, the response
903   SHOULD be 201 (Created) and contain an entity which describes the
904   status of the request and refers to the new resource, and a Location
905   header (see Section 10.4).
906
907   Responses to this method are not cacheable, unless the response
908   includes appropriate Cache-Control or Expires header fields.
909   However, the 303 (See Other) response can be used to direct the user
910   agent to retrieve a cacheable resource.
911
9128.6.  PUT
913
914   The PUT method requests that the enclosed entity be stored at the
915   supplied Request-URI.  If the Request-URI refers to an already
916   existing resource, the enclosed entity SHOULD be considered as a
917   modified version of the one residing on the origin server.  If the
918   Request-URI does not point to an existing resource, and that URI is
919   capable of being defined as a new resource by the requesting user
920   agent, the origin server can create the resource with that URI.  If a
921   new resource is created at the Request-URI, the origin server MUST
922   inform the user agent via the 201 (Created) response.  If an existing
923   resource is modified, either the 200 (OK) or 204 (No Content)
924   response codes SHOULD be sent to indicate successful completion of
925   the request.  If the resource could not be created or modified with
926   the Request-URI, an appropriate error response SHOULD be given that
927   reflects the nature of the problem.  The recipient of the entity MUST
928   NOT ignore any Content-* headers (headers starting with the prefix
929   'Content-') that it does not understand or implement and MUST return
930   a 501 (Not Implemented) response in such cases.
931
932   If the request passes through a cache and the Request-URI identifies
933   one or more currently cached entities, those entries SHOULD be
934   treated as stale.  Responses to this method are not cacheable.
935
936   The fundamental difference between the POST and PUT requests is
937   reflected in the different meaning of the Request-URI.  The URI in a
938   POST request identifies the resource that will handle the enclosed
939   entity.  That resource might be a data-accepting process, a gateway
940   to some other protocol, or a separate entity that accepts
941   annotations.  In contrast, the URI in a PUT request identifies the
942   entity enclosed with the request -- the user agent knows what URI is
943   intended and the server MUST NOT attempt to apply the request to some
944   other resource.  If the server desires that the request be applied to
945   a different URI, it MUST send a 301 (Moved Permanently) response; the
946   user agent MAY then make its own decision regarding whether or not to
947   redirect the request.
948
949
950
951Fielding, et al.          Expires May 20, 2009                 [Page 17]
952
953Internet-Draft              HTTP/1.1, Part 2               November 2008
954
955
956   A single resource MAY be identified by many different URIs.  For
957   example, an article might have a URI for identifying "the current
958   version" which is separate from the URI identifying each particular
959   version.  In this case, a PUT request on a general URI might result
960   in several other URIs being defined by the origin server.
961
962   HTTP/1.1 does not define how a PUT method affects the state of an
963   origin server.
964
965   Unless otherwise specified for a particular entity-header, the
966   entity-headers in the PUT request SHOULD be applied to the resource
967   created or modified by the PUT.
968
9698.7.  DELETE
970
971   The DELETE method requests that the origin server delete the resource
972   identified by the Request-URI.  This method MAY be overridden by
973   human intervention (or other means) on the origin server.  The client
974   cannot be guaranteed that the operation has been carried out, even if
975   the status code returned from the origin server indicates that the
976   action has been completed successfully.  However, the server SHOULD
977   NOT indicate success unless, at the time the response is given, it
978   intends to delete the resource or move it to an inaccessible
979   location.
980
981   A successful response SHOULD be 200 (OK) if the response includes an
982   entity describing the status, 202 (Accepted) if the action has not
983   yet been enacted, or 204 (No Content) if the action has been enacted
984   but the response does not include an entity.
985
986   If the request passes through a cache and the Request-URI identifies
987   one or more currently cached entities, those entries SHOULD be
988   treated as stale.  Responses to this method are not cacheable.
989
9908.8.  TRACE
991
992   The TRACE method is used to invoke a remote, application-layer loop-
993   back of the request message.  The final recipient of the request
994   SHOULD reflect the message received back to the client as the entity-
995   body of a 200 (OK) response.  The final recipient is either the
996   origin server or the first proxy or gateway to receive a Max-Forwards
997   value of zero (0) in the request (see Section 10.5).  A TRACE request
998   MUST NOT include an entity.
999
1000   TRACE allows the client to see what is being received at the other
1001   end of the request chain and use that data for testing or diagnostic
1002   information.  The value of the Via header field (Section 8.9 of
1003   [Part1]) is of particular interest, since it acts as a trace of the
1004
1005
1006
1007Fielding, et al.          Expires May 20, 2009                 [Page 18]
1008
1009Internet-Draft              HTTP/1.1, Part 2               November 2008
1010
1011
1012   request chain.  Use of the Max-Forwards header field allows the
1013   client to limit the length of the request chain, which is useful for
1014   testing a chain of proxies forwarding messages in an infinite loop.
1015
1016   If the request is valid, the response SHOULD contain the entire
1017   request message in the entity-body, with a Content-Type of "message/
1018   http" (see Section 9.3.1 of [Part1]).  Responses to this method MUST
1019   NOT be cached.
1020
10218.9.  CONNECT
1022
1023   This specification reserves the method name CONNECT for use with a
1024   proxy that can dynamically switch to being a tunnel (e.g.  SSL
1025   tunneling [RFC2817]).
1026
1027
10289.  Status Code Definitions
1029
1030   Each Status-Code is described below, including a description of which
1031   method(s) it can follow and any metainformation required in the
1032   response.
1033
10349.1.  Informational 1xx
1035
1036   This class of status code indicates a provisional response,
1037   consisting only of the Status-Line and optional headers, and is
1038   terminated by an empty line.  There are no required headers for this
1039   class of status code.  Since HTTP/1.0 did not define any 1xx status
1040   codes, servers MUST NOT send a 1xx response to an HTTP/1.0 client
1041   except under experimental conditions.
1042
1043   A client MUST be prepared to accept one or more 1xx status responses
1044   prior to a regular response, even if the client does not expect a 100
1045   (Continue) status message.  Unexpected 1xx status responses MAY be
1046   ignored by a user agent.
1047
1048   Proxies MUST forward 1xx responses, unless the connection between the
1049   proxy and its client has been closed, or unless the proxy itself
1050   requested the generation of the 1xx response.  (For example, if a
1051   proxy adds a "Expect: 100-continue" field when it forwards a request,
1052   then it need not forward the corresponding 100 (Continue)
1053   response(s).)
1054
10559.1.1.  100 Continue
1056
1057   The client SHOULD continue with its request.  This interim response
1058   is used to inform the client that the initial part of the request has
1059   been received and has not yet been rejected by the server.  The
1060
1061
1062
1063Fielding, et al.          Expires May 20, 2009                 [Page 19]
1064
1065Internet-Draft              HTTP/1.1, Part 2               November 2008
1066
1067
1068   client SHOULD continue by sending the remainder of the request or, if
1069   the request has already been completed, ignore this response.  The
1070   server MUST send a final response after the request has been
1071   completed.  See Section 7.2.3 of [Part1] for detailed discussion of
1072   the use and handling of this status code.
1073
10749.1.2.  101 Switching Protocols
1075
1076   The server understands and is willing to comply with the client's
1077   request, via the Upgrade message header field (Section 6.4 of
1078   [Part5]), for a change in the application protocol being used on this
1079   connection.  The server will switch protocols to those defined by the
1080   response's Upgrade header field immediately after the empty line
1081   which terminates the 101 response.
1082
1083   The protocol SHOULD be switched only when it is advantageous to do
1084   so.  For example, switching to a newer version of HTTP is
1085   advantageous over older versions, and switching to a real-time,
1086   synchronous protocol might be advantageous when delivering resources
1087   that use such features.
1088
10899.2.  Successful 2xx
1090
1091   This class of status code indicates that the client's request was
1092   successfully received, understood, and accepted.
1093
10949.2.1.  200 OK
1095
1096   The request has succeeded.  The information returned with the
1097   response is dependent on the method used in the request, for example:
1098
1099   GET  an entity corresponding to the requested resource is sent in the
1100      response;
1101
1102   HEAD  the entity-header fields corresponding to the requested
1103      resource are sent in the response without any message-body;
1104
1105   POST  an entity describing or containing the result of the action;
1106
1107   TRACE  an entity containing the request message as received by the
1108      end server.
1109
11109.2.2.  201 Created
1111
1112   The request has been fulfilled and resulted in a new resource being
1113   created.  The newly created resource can be referenced by the URI(s)
1114   returned in the entity of the response, with the most specific URI
1115   for the resource given by a Location header field.  The response
1116
1117
1118
1119Fielding, et al.          Expires May 20, 2009                 [Page 20]
1120
1121Internet-Draft              HTTP/1.1, Part 2               November 2008
1122
1123
1124   SHOULD include an entity containing a list of resource
1125   characteristics and location(s) from which the user or user agent can
1126   choose the one most appropriate.  The entity format is specified by
1127   the media type given in the Content-Type header field.  The origin
1128   server MUST create the resource before returning the 201 status code.
1129   If the action cannot be carried out immediately, the server SHOULD
1130   respond with 202 (Accepted) response instead.
1131
1132   A 201 response MAY contain an ETag response header field indicating
1133   the current value of the entity tag for the requested variant just
1134   created, see Section 7.1 of [Part4].
1135
11369.2.3.  202 Accepted
1137
1138   The request has been accepted for processing, but the processing has
1139   not been completed.  The request might or might not eventually be
1140   acted upon, as it might be disallowed when processing actually takes
1141   place.  There is no facility for re-sending a status code from an
1142   asynchronous operation such as this.
1143
1144   The 202 response is intentionally non-committal.  Its purpose is to
1145   allow a server to accept a request for some other process (perhaps a
1146   batch-oriented process that is only run once per day) without
1147   requiring that the user agent's connection to the server persist
1148   until the process is completed.  The entity returned with this
1149   response SHOULD include an indication of the request's current status
1150   and either a pointer to a status monitor or some estimate of when the
1151   user can expect the request to be fulfilled.
1152
11539.2.4.  203 Non-Authoritative Information
1154
1155   The returned metainformation in the entity-header is not the
1156   definitive set as available from the origin server, but is gathered
1157   from a local or a third-party copy.  The set presented MAY be a
1158   subset or superset of the original version.  For example, including
1159   local annotation information about the resource might result in a
1160   superset of the metainformation known by the origin server.  Use of
1161   this response code is not required and is only appropriate when the
1162   response would otherwise be 200 (OK).
1163
11649.2.5.  204 No Content
1165
1166   The server has fulfilled the request but does not need to return an
1167   entity-body, and might want to return updated metainformation.  The
1168   response MAY include new or updated metainformation in the form of
1169   entity-headers, which if present SHOULD be associated with the
1170   requested variant.
1171
1172
1173
1174
1175Fielding, et al.          Expires May 20, 2009                 [Page 21]
1176
1177Internet-Draft              HTTP/1.1, Part 2               November 2008
1178
1179
1180   If the client is a user agent, it SHOULD NOT change its document view
1181   from that which caused the request to be sent.  This response is
1182   primarily intended to allow input for actions to take place without
1183   causing a change to the user agent's active document view, although
1184   any new or updated metainformation SHOULD be applied to the document
1185   currently in the user agent's active view.
1186
1187   The 204 response MUST NOT include a message-body, and thus is always
1188   terminated by the first empty line after the header fields.
1189
11909.2.6.  205 Reset Content
1191
1192   The server has fulfilled the request and the user agent SHOULD reset
1193   the document view which caused the request to be sent.  This response
1194   is primarily intended to allow input for actions to take place via
1195   user input, followed by a clearing of the form in which the input is
1196   given so that the user can easily initiate another input action.  The
1197   response MUST NOT include an entity.
1198
11999.2.7.  206 Partial Content
1200
1201   The server has fulfilled the partial GET request for the resource and
1202   the enclosed entity is a partial representation as defined in
1203   [Part5].
1204
12059.3.  Redirection 3xx
1206
1207   This class of status code indicates that further action needs to be
1208   taken by the user agent in order to fulfill the request.  The action
1209   required MAY be carried out by the user agent without interaction
1210   with the user if and only if the method used in the second request is
1211   GET or HEAD.  A client SHOULD detect infinite redirection loops,
1212   since such loops generate network traffic for each redirection.
1213
1214      Note: previous versions of this specification recommended a
1215      maximum of five redirections.  Content developers should be aware
1216      that there might be clients that implement such a fixed
1217      limitation.
1218
12199.3.1.  300 Multiple Choices
1220
1221   The requested resource corresponds to any one of a set of
1222   representations, each with its own specific location, and agent-
1223   driven negotiation information (Section 5 of [Part3]) is being
1224   provided so that the user (or user agent) can select a preferred
1225   representation and redirect its request to that location.
1226
1227   Unless it was a HEAD request, the response SHOULD include an entity
1228
1229
1230
1231Fielding, et al.          Expires May 20, 2009                 [Page 22]
1232
1233Internet-Draft              HTTP/1.1, Part 2               November 2008
1234
1235
1236   containing a list of resource characteristics and location(s) from
1237   which the user or user agent can choose the one most appropriate.
1238   The entity format is specified by the media type given in the
1239   Content-Type header field.  Depending upon the format and the
1240   capabilities of the user agent, selection of the most appropriate
1241   choice MAY be performed automatically.  However, this specification
1242   does not define any standard for such automatic selection.
1243
1244   If the server has a preferred choice of representation, it SHOULD
1245   include the specific URI for that representation in the Location
1246   field; user agents MAY use the Location field value for automatic
1247   redirection.  This response is cacheable unless indicated otherwise.
1248
12499.3.2.  301 Moved Permanently
1250
1251   The requested resource has been assigned a new permanent URI and any
1252   future references to this resource SHOULD use one of the returned
1253   URIs.  Clients with link editing capabilities ought to automatically
1254   re-link references to the Request-URI to one or more of the new
1255   references returned by the server, where possible.  This response is
1256   cacheable unless indicated otherwise.
1257
1258   The new permanent URI SHOULD be given by the Location field in the
1259   response.  Unless the request method was HEAD, the entity of the
1260   response SHOULD contain a short hypertext note with a hyperlink to
1261   the new URI(s).
1262
1263   If the 301 status code is received in response to a request method
1264   that is known to be "safe", as defined in Section 8.1.1, then the
1265   request MAY be automatically redirected by the user agent without
1266   confirmation.  Otherwise, the user agent MUST NOT automatically
1267   redirect the request unless it can be confirmed by the user, since
1268   this might change the conditions under which the request was issued.
1269
1270      Note: When automatically redirecting a POST request after
1271      receiving a 301 status code, some existing HTTP/1.0 user agents
1272      will erroneously change it into a GET request.
1273
12749.3.3.  302 Found
1275
1276   The requested resource resides temporarily under a different URI.
1277   Since the redirection might be altered on occasion, the client SHOULD
1278   continue to use the Request-URI for future requests.  This response
1279   is only cacheable if indicated by a Cache-Control or Expires header
1280   field.
1281
1282   The temporary URI SHOULD be given by the Location field in the
1283   response.  Unless the request method was HEAD, the entity of the
1284
1285
1286
1287Fielding, et al.          Expires May 20, 2009                 [Page 23]
1288
1289Internet-Draft              HTTP/1.1, Part 2               November 2008
1290
1291
1292   response SHOULD contain a short hypertext note with a hyperlink to
1293   the new URI(s).
1294
1295   If the 302 status code is received in response to a request method
1296   that is known to be "safe", as defined in Section 8.1.1, then the
1297   request MAY be automatically redirected by the user agent without
1298   confirmation.  Otherwise, the user agent MUST NOT automatically
1299   redirect the request unless it can be confirmed by the user, since
1300   this might change the conditions under which the request was issued.
1301
1302      Note: [RFC1945] and [RFC2068] specify that the client is not
1303      allowed to change the method on the redirected request.  However,
1304      most existing user agent implementations treat 302 as if it were a
1305      303 response, performing a GET on the Location field-value
1306      regardless of the original request method.  The status codes 303
1307      and 307 have been added for servers that wish to make
1308      unambiguously clear which kind of reaction is expected of the
1309      client.
1310
13119.3.4.  303 See Other
1312
1313   The server directs the user agent to a different resource, indicated
1314   by a URI in the Location header field, that provides an indirect
1315   response to the original request.  The user agent MAY perform a GET
1316   request on the URI in the Location field in order to obtain a
1317   representation corresponding to the response, be redirected again, or
1318   end with an error status.  The Location URI is not a substitute
1319   reference for the originally requested resource.
1320
1321   The 303 status is generally applicable to any HTTP method.  It is
1322   primarily used to allow the output of a POST action to redirect the
1323   user agent to a selected resource, since doing so provides the
1324   information corresponding to the POST response in a form that can be
1325   separately identified, bookmarked, and cached independent of the
1326   original request.
1327
1328   A 303 response to a GET request indicates that the requested resource
1329   does not have a representation of its own that can be transferred by
1330   the server over HTTP.  The Location URI indicates a resource that is
1331   descriptive of the requested resource such that the follow-on
1332   representation may be useful without implying that it adequately
1333   represents the previously requested resource.  Note that answers to
1334   the questions of what can be represented, what representations are
1335   adequate, and what might be a useful description are outside the
1336   scope of HTTP and thus entirely determined by the resource owner(s).
1337
1338   A 303 response SHOULD NOT be cached unless it is indicated as
1339   cacheable by Cache-Control or Expires header fields.  Except for
1340
1341
1342
1343Fielding, et al.          Expires May 20, 2009                 [Page 24]
1344
1345Internet-Draft              HTTP/1.1, Part 2               November 2008
1346
1347
1348   responses to a HEAD request, the entity of a 303 response SHOULD
1349   contain a short hypertext note with a hyperlink to the Location URI.
1350
13519.3.5.  304 Not Modified
1352
1353   The response to the request has not been modified since the
1354   conditions indicated by the client's conditional GET request, as
1355   defined in [Part4].
1356
13579.3.6.  305 Use Proxy
1358
1359   The 305 status was defined in a previous version of this
1360   specification (see Appendix A.2), and is now deprecated.
1361
13629.3.7.  306 (Unused)
1363
1364   The 306 status code was used in a previous version of the
1365   specification, is no longer used, and the code is reserved.
1366
13679.3.8.  307 Temporary Redirect
1368
1369   The requested resource resides temporarily under a different URI.
1370   Since the redirection MAY be altered on occasion, the client SHOULD
1371   continue to use the Request-URI for future requests.  This response
1372   is only cacheable if indicated by a Cache-Control or Expires header
1373   field.
1374
1375   The temporary URI SHOULD be given by the Location field in the
1376   response.  Unless the request method was HEAD, the entity of the
1377   response SHOULD contain a short hypertext note with a hyperlink to
1378   the new URI(s) , since many pre-HTTP/1.1 user agents do not
1379   understand the 307 status.  Therefore, the note SHOULD contain the
1380   information necessary for a user to repeat the original request on
1381   the new URI.
1382
1383   If the 307 status code is received in response to a request method
1384   that is known to be "safe", as defined in Section 8.1.1, then the
1385   request MAY be automatically redirected by the user agent without
1386   confirmation.  Otherwise, the user agent MUST NOT automatically
1387   redirect the request unless it can be confirmed by the user, since
1388   this might change the conditions under which the request was issued.
1389
13909.4.  Client Error 4xx
1391
1392   The 4xx class of status code is intended for cases in which the
1393   client seems to have erred.  Except when responding to a HEAD
1394   request, the server SHOULD include an entity containing an
1395   explanation of the error situation, and whether it is a temporary or
1396
1397
1398
1399Fielding, et al.          Expires May 20, 2009                 [Page 25]
1400
1401Internet-Draft              HTTP/1.1, Part 2               November 2008
1402
1403
1404   permanent condition.  These status codes are applicable to any
1405   request method.  User agents SHOULD display any included entity to
1406   the user.
1407
1408   If the client is sending data, a server implementation using TCP
1409   SHOULD be careful to ensure that the client acknowledges receipt of
1410   the packet(s) containing the response, before the server closes the
1411   input connection.  If the client continues sending data to the server
1412   after the close, the server's TCP stack will send a reset packet to
1413   the client, which may erase the client's unacknowledged input buffers
1414   before they can be read and interpreted by the HTTP application.
1415
14169.4.1.  400 Bad Request
1417
1418   The request could not be understood by the server due to malformed
1419   syntax.  The client SHOULD NOT repeat the request without
1420   modifications.
1421
14229.4.2.  401 Unauthorized
1423
1424   The request requires user authentication (see [Part7]).
1425
14269.4.3.  402 Payment Required
1427
1428   This code is reserved for future use.
1429
14309.4.4.  403 Forbidden
1431
1432   The server understood the request, but is refusing to fulfill it.
1433   Authorization will not help and the request SHOULD NOT be repeated.
1434   If the request method was not HEAD and the server wishes to make
1435   public why the request has not been fulfilled, it SHOULD describe the
1436   reason for the refusal in the entity.  If the server does not wish to
1437   make this information available to the client, the status code 404
1438   (Not Found) can be used instead.
1439
14409.4.5.  404 Not Found
1441
1442   The server has not found anything matching the Request-URI.  No
1443   indication is given of whether the condition is temporary or
1444   permanent.  The 410 (Gone) status code SHOULD be used if the server
1445   knows, through some internally configurable mechanism, that an old
1446   resource is permanently unavailable and has no forwarding address.
1447   This status code is commonly used when the server does not wish to
1448   reveal exactly why the request has been refused, or when no other
1449   response is applicable.
1450
1451
1452
1453
1454
1455Fielding, et al.          Expires May 20, 2009                 [Page 26]
1456
1457Internet-Draft              HTTP/1.1, Part 2               November 2008
1458
1459
14609.4.6.  405 Method Not Allowed
1461
1462   The method specified in the Request-Line is not allowed for the
1463   resource identified by the Request-URI.  The response MUST include an
1464   Allow header containing a list of valid methods for the requested
1465   resource.
1466
14679.4.7.  406 Not Acceptable
1468
1469   The resource identified by the request is only capable of generating
1470   response entities which have content characteristics not acceptable
1471   according to the accept headers sent in the request.
1472
1473   Unless it was a HEAD request, the response SHOULD include an entity
1474   containing a list of available entity characteristics and location(s)
1475   from which the user or user agent can choose the one most
1476   appropriate.  The entity format is specified by the media type given
1477   in the Content-Type header field.  Depending upon the format and the
1478   capabilities of the user agent, selection of the most appropriate
1479   choice MAY be performed automatically.  However, this specification
1480   does not define any standard for such automatic selection.
1481
1482      Note: HTTP/1.1 servers are allowed to return responses which are
1483      not acceptable according to the accept headers sent in the
1484      request.  In some cases, this may even be preferable to sending a
1485      406 response.  User agents are encouraged to inspect the headers
1486      of an incoming response to determine if it is acceptable.
1487
1488   If the response could be unacceptable, a user agent SHOULD
1489   temporarily stop receipt of more data and query the user for a
1490   decision on further actions.
1491
14929.4.8.  407 Proxy Authentication Required
1493
1494   This code is similar to 401 (Unauthorized), but indicates that the
1495   client must first authenticate itself with the proxy (see [Part7]).
1496
14979.4.9.  408 Request Timeout
1498
1499   The client did not produce a request within the time that the server
1500   was prepared to wait.  The client MAY repeat the request without
1501   modifications at any later time.
1502
15039.4.10.  409 Conflict
1504
1505   The request could not be completed due to a conflict with the current
1506   state of the resource.  This code is only allowed in situations where
1507   it is expected that the user might be able to resolve the conflict
1508
1509
1510
1511Fielding, et al.          Expires May 20, 2009                 [Page 27]
1512
1513Internet-Draft              HTTP/1.1, Part 2               November 2008
1514
1515
1516   and resubmit the request.  The response body SHOULD include enough
1517   information for the user to recognize the source of the conflict.
1518   Ideally, the response entity would include enough information for the
1519   user or user agent to fix the problem; however, that might not be
1520   possible and is not required.
1521
1522   Conflicts are most likely to occur in response to a PUT request.  For
1523   example, if versioning were being used and the entity being PUT
1524   included changes to a resource which conflict with those made by an
1525   earlier (third-party) request, the server might use the 409 response
1526   to indicate that it can't complete the request.  In this case, the
1527   response entity would likely contain a list of the differences
1528   between the two versions in a format defined by the response Content-
1529   Type.
1530
15319.4.11.  410 Gone
1532
1533   The requested resource is no longer available at the server and no
1534   forwarding address is known.  This condition is expected to be
1535   considered permanent.  Clients with link editing capabilities SHOULD
1536   delete references to the Request-URI after user approval.  If the
1537   server does not know, or has no facility to determine, whether or not
1538   the condition is permanent, the status code 404 (Not Found) SHOULD be
1539   used instead.  This response is cacheable unless indicated otherwise.
1540
1541   The 410 response is primarily intended to assist the task of web
1542   maintenance by notifying the recipient that the resource is
1543   intentionally unavailable and that the server owners desire that
1544   remote links to that resource be removed.  Such an event is common
1545   for limited-time, promotional services and for resources belonging to
1546   individuals no longer working at the server's site.  It is not
1547   necessary to mark all permanently unavailable resources as "gone" or
1548   to keep the mark for any length of time -- that is left to the
1549   discretion of the server owner.
1550
15519.4.12.  411 Length Required
1552
1553   The server refuses to accept the request without a defined Content-
1554   Length.  The client MAY repeat the request if it adds a valid
1555   Content-Length header field containing the length of the message-body
1556   in the request message.
1557
15589.4.13.  412 Precondition Failed
1559
1560   The precondition given in one or more of the request-header fields
1561   evaluated to false when it was tested on the server, as defined in
1562   [Part4].
1563
1564
1565
1566
1567Fielding, et al.          Expires May 20, 2009                 [Page 28]
1568
1569Internet-Draft              HTTP/1.1, Part 2               November 2008
1570
1571
15729.4.14.  413 Request Entity Too Large
1573
1574   The server is refusing to process a request because the request
1575   entity is larger than the server is willing or able to process.  The
1576   server MAY close the connection to prevent the client from continuing
1577   the request.
1578
1579   If the condition is temporary, the server SHOULD include a Retry-
1580   After header field to indicate that it is temporary and after what
1581   time the client MAY try again.
1582
15839.4.15.  414 Request-URI Too Long
1584
1585   The server is refusing to service the request because the Request-URI
1586   is longer than the server is willing to interpret.  This rare
1587   condition is only likely to occur when a client has improperly
1588   converted a POST request to a GET request with long query
1589   information, when the client has descended into a URI "black hole" of
1590   redirection (e.g., a redirected URI prefix that points to a suffix of
1591   itself), or when the server is under attack by a client attempting to
1592   exploit security holes present in some servers using fixed-length
1593   buffers for reading or manipulating the Request-URI.
1594
15959.4.16.  415 Unsupported Media Type
1596
1597   The server is refusing to service the request because the entity of
1598   the request is in a format not supported by the requested resource
1599   for the requested method.
1600
16019.4.17.  416 Requested Range Not Satisfiable
1602
1603   The request included a Range request-header field (Section 6.4 of
1604   [Part5]) and none of the range-specifier values in this field overlap
1605   the current extent of the selected resource.
1606
16079.4.18.  417 Expectation Failed
1608
1609   The expectation given in an Expect request-header field (see
1610   Section 10.2) could not be met by this server, or, if the server is a
1611   proxy, the server has unambiguous evidence that the request could not
1612   be met by the next-hop server.
1613
16149.5.  Server Error 5xx
1615
1616   Response status codes beginning with the digit "5" indicate cases in
1617   which the server is aware that it has erred or is incapable of
1618   performing the request.  Except when responding to a HEAD request,
1619   the server SHOULD include an entity containing an explanation of the
1620
1621
1622
1623Fielding, et al.          Expires May 20, 2009                 [Page 29]
1624
1625Internet-Draft              HTTP/1.1, Part 2               November 2008
1626
1627
1628   error situation, and whether it is a temporary or permanent
1629   condition.  User agents SHOULD display any included entity to the
1630   user.  These response codes are applicable to any request method.
1631
16329.5.1.  500 Internal Server Error
1633
1634   The server encountered an unexpected condition which prevented it
1635   from fulfilling the request.
1636
16379.5.2.  501 Not Implemented
1638
1639   The server does not support the functionality required to fulfill the
1640   request.  This is the appropriate response when the server does not
1641   recognize the request method and is not capable of supporting it for
1642   any resource.
1643
16449.5.3.  502 Bad Gateway
1645
1646   The server, while acting as a gateway or proxy, received an invalid
1647   response from the upstream server it accessed in attempting to
1648   fulfill the request.
1649
16509.5.4.  503 Service Unavailable
1651
1652   The server is currently unable to handle the request due to a
1653   temporary overloading or maintenance of the server.  The implication
1654   is that this is a temporary condition which will be alleviated after
1655   some delay.  If known, the length of the delay MAY be indicated in a
1656   Retry-After header.  If no Retry-After is given, the client SHOULD
1657   handle the response as it would for a 500 response.
1658
1659      Note: The existence of the 503 status code does not imply that a
1660      server must use it when becoming overloaded.  Some servers may
1661      wish to simply refuse the connection.
1662
16639.5.5.  504 Gateway Timeout
1664
1665   The server, while acting as a gateway or proxy, did not receive a
1666   timely response from the upstream server specified by the URI (e.g.
1667   HTTP, FTP, LDAP) or some other auxiliary server (e.g.  DNS) it needed
1668   to access in attempting to complete the request.
1669
1670      Note: Note to implementors: some deployed proxies are known to
1671      return 400 or 500 when DNS lookups time out.
1672
1673
1674
1675
1676
1677
1678
1679Fielding, et al.          Expires May 20, 2009                 [Page 30]
1680
1681Internet-Draft              HTTP/1.1, Part 2               November 2008
1682
1683
16849.5.6.  505 HTTP Version Not Supported
1685
1686   The server does not support, or refuses to support, the protocol
1687   version that was used in the request message.  The server is
1688   indicating that it is unable or unwilling to complete the request
1689   using the same major version as the client, as described in Section
1690   3.1 of [Part1], other than with this error message.  The response
1691   SHOULD contain an entity describing why that version is not supported
1692   and what other protocols are supported by that server.
1693
1694
169510.  Header Field Definitions
1696
1697   This section defines the syntax and semantics of HTTP/1.1 header
1698   fields related to request and response semantics.
1699
1700   For entity-header fields, both sender and recipient refer to either
1701   the client or the server, depending on who sends and who receives the
1702   entity.
1703
170410.1.  Allow
1705
1706   The response-header field "Allow" lists the set of methods advertised
1707   as supported by the resource identified by the Request-URI.  The
1708   purpose of this field is strictly to inform the recipient of valid
1709   methods associated with the resource.  An Allow header field MUST be
1710   present in a 405 (Method Not Allowed) response.
1711
1712     Allow   = "Allow" ":" OWS Allow-v
1713     Allow-v = #Method
1714
1715   Example of use:
1716
1717     Allow: GET, HEAD, PUT
1718
1719   The actual set of allowed methods is defined by the origin server at
1720   the time of each request.
1721
1722   A proxy MUST NOT modify the Allow header field even if it does not
1723   understand all the methods specified, since the user agent might have
1724   other means of communicating with the origin server.
1725
172610.2.  Expect
1727
1728   The request-header field "Expect" is used to indicate that particular
1729   server behaviors are required by the client.
1730
1731
1732
1733
1734
1735Fielding, et al.          Expires May 20, 2009                 [Page 31]
1736
1737Internet-Draft              HTTP/1.1, Part 2               November 2008
1738
1739
1740     Expect       = "Expect" ":" OWS Expect-v
1741     Expect-v     = 1#expectation
1742
1743     expectation  = "100-continue" / expectation-extension
1744     expectation-extension = token [ "=" ( token / quoted-string )
1745                              *expect-params ]
1746     expect-params = ";" token [ "=" ( token / quoted-string ) ]
1747
1748   A server that does not understand or is unable to comply with any of
1749   the expectation values in the Expect field of a request MUST respond
1750   with appropriate error status.  The server MUST respond with a 417
1751   (Expectation Failed) status if any of the expectations cannot be met
1752   or, if there are other problems with the request, some other 4xx
1753   status.
1754
1755   This header field is defined with extensible syntax to allow for
1756   future extensions.  If a server receives a request containing an
1757   Expect field that includes an expectation-extension that it does not
1758   support, it MUST respond with a 417 (Expectation Failed) status.
1759
1760   Comparison of expectation values is case-insensitive for unquoted
1761   tokens (including the 100-continue token), and is case-sensitive for
1762   quoted-string expectation-extensions.
1763
1764   The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy MUST
1765   return a 417 (Expectation Failed) status if it receives a request
1766   with an expectation that it cannot meet.  However, the Expect
1767   request-header itself is end-to-end; it MUST be forwarded if the
1768   request is forwarded.
1769
1770   Many older HTTP/1.0 and HTTP/1.1 applications do not understand the
1771   Expect header.
1772
1773   See Section 7.2.3 of [Part1] for the use of the 100 (Continue)
1774   status.
1775
177610.3.  From
1777
1778   The request-header field "From", if given, SHOULD contain an Internet
1779   e-mail address for the human user who controls the requesting user
1780   agent.  The address SHOULD be machine-usable, as defined by "mailbox"
1781   in Section 3.4 of [RFC5322]:
1782
1783     From    = "From" ":" OWS From-v
1784     From-v  = mailbox
1785
1786     mailbox = <mailbox, defined in [RFC5322], Section 3.4>
1787
1788
1789
1790
1791Fielding, et al.          Expires May 20, 2009                 [Page 32]
1792
1793Internet-Draft              HTTP/1.1, Part 2               November 2008
1794
1795
1796   An example is:
1797
1798     From: webmaster@example.org
1799
1800   This header field MAY be used for logging purposes and as a means for
1801   identifying the source of invalid or unwanted requests.  It SHOULD
1802   NOT be used as an insecure form of access protection.  The
1803   interpretation of this field is that the request is being performed
1804   on behalf of the person given, who accepts responsibility for the
1805   method performed.  In particular, robot agents SHOULD include this
1806   header so that the person responsible for running the robot can be
1807   contacted if problems occur on the receiving end.
1808
1809   The Internet e-mail address in this field MAY be separate from the
1810   Internet host which issued the request.  For example, when a request
1811   is passed through a proxy the original issuer's address SHOULD be
1812   used.
1813
1814   The client SHOULD NOT send the From header field without the user's
1815   approval, as it might conflict with the user's privacy interests or
1816   their site's security policy.  It is strongly recommended that the
1817   user be able to disable, enable, and modify the value of this field
1818   at any time prior to a request.
1819
182010.4.  Location
1821
1822   The response-header field "Location" is used for the identification
1823   of a new resource or to redirect the recipient to a location other
1824   than the Request-URI for completion of the request.  For 201
1825   (Created) responses, the Location is that of the new resource which
1826   was created by the request.  For 3xx responses, the location SHOULD
1827   indicate the server's preferred URI for automatic redirection to the
1828   resource.  The field value consists of a single absolute URI.
1829
1830     Location       = "Location" ":" OWS Location-v
1831     Location-v     = absolute-URI [ "#" fragment ]
1832
1833   An example is:
1834
1835     Location: http://www.example.org/pub/WWW/People.html
1836
1837      Note: The Content-Location header field (Section 6.7 of [Part3])
1838      differs from Location in that the Content-Location identifies the
1839      original location of the entity enclosed in the response.  It is
1840      therefore possible for a response to contain header fields for
1841      both Location and Content-Location.
1842
1843   There are circumstances in which a fragment identifier in a Location
1844
1845
1846
1847Fielding, et al.          Expires May 20, 2009                 [Page 33]
1848
1849Internet-Draft              HTTP/1.1, Part 2               November 2008
1850
1851
1852   URL would not be appropriate:
1853
1854   o  With a 201 Created response, because in this usage the Location
1855      header specifies the URL for the entire created resource.
1856
1857   o  With a 300 Multiple Choices, since the choice decision is intended
1858      to be made on resource characteristics and not fragment
1859      characteristics.
1860
1861   o  With 305 Use Proxy.
1862
186310.5.  Max-Forwards
1864
1865   The request-header "Max-Forwards" field provides a mechanism with the
1866   TRACE (Section 8.8) and OPTIONS (Section 8.2) methods to limit the
1867   number of proxies or gateways that can forward the request to the
1868   next inbound server.  This can be useful when the client is
1869   attempting to trace a request chain which appears to be failing or
1870   looping in mid-chain.
1871
1872     Max-Forwards   = "Max-Forwards" ":" OWS Max-Forwards-v
1873     Max-Forwards-v = 1*DIGIT
1874
1875   The Max-Forwards value is a decimal integer indicating the remaining
1876   number of times this request message may be forwarded.
1877
1878   Each proxy or gateway recipient of a TRACE or OPTIONS request
1879   containing a Max-Forwards header field MUST check and update its
1880   value prior to forwarding the request.  If the received value is zero
1881   (0), the recipient MUST NOT forward the request; instead, it MUST
1882   respond as the final recipient.  If the received Max-Forwards value
1883   is greater than zero, then the forwarded message MUST contain an
1884   updated Max-Forwards field with a value decremented by one (1).
1885
1886   The Max-Forwards header field MAY be ignored for all other methods
1887   defined by this specification and for any extension methods for which
1888   it is not explicitly referred to as part of that method definition.
1889
189010.6.  Referer
1891
1892   The request-header field "Referer" [sic] allows the client to
1893   specify, for the server's benefit, the address (URI) of the resource
1894   from which the Request-URI was obtained (the "referrer", although the
1895   header field is misspelled.)  The Referer request-header allows a
1896   server to generate lists of back-links to resources for interest,
1897   logging, optimized caching, etc.  It also allows obsolete or mistyped
1898   links to be traced for maintenance.  The Referer field MUST NOT be
1899   sent if the Request-URI was obtained from a source that does not have
1900
1901
1902
1903Fielding, et al.          Expires May 20, 2009                 [Page 34]
1904
1905Internet-Draft              HTTP/1.1, Part 2               November 2008
1906
1907
1908   its own URI, such as input from the user keyboard.
1909
1910     Referer        = "Referer" ":" OWS Referer-v
1911     Referer-v      = absolute-URI / relativeURI
1912
1913   Example:
1914
1915     Referer: http://www.example.org/hypertext/Overview.html
1916
1917   If the field value is a relative URI, it SHOULD be interpreted
1918   relative to the Request-URI.  The URI MUST NOT include a fragment.
1919   See Section 12.2 for security considerations.
1920
192110.7.  Retry-After
1922
1923   The response-header "Retry-After" field can be used with a 503
1924   (Service Unavailable) response to indicate how long the service is
1925   expected to be unavailable to the requesting client.  This field MAY
1926   also be used with any 3xx (Redirection) response to indicate the
1927   minimum time the user-agent is asked wait before issuing the
1928   redirected request.  The value of this field can be either an HTTP-
1929   date or an integer number of seconds (in decimal) after the time of
1930   the response.
1931
1932     Retry-After   = "Retry-After" ":" OWS Retry-After-v
1933     Retry-After-v = HTTP-date / delta-seconds
1934
1935   Time spans are non-negative decimal integers, representing time in
1936   seconds.
1937
1938     delta-seconds  = 1*DIGIT
1939
1940   Two examples of its use are
1941
1942     Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
1943     Retry-After: 120
1944
1945   In the latter example, the delay is 2 minutes.
1946
194710.8.  Server
1948
1949   The response-header field "Server" contains information about the
1950   software used by the origin server to handle the request.  The field
1951   can contain multiple product tokens (Section 3.5 of [Part1]) and
1952   comments identifying the server and any significant subproducts.  The
1953   product tokens are listed in order of their significance for
1954   identifying the application.
1955
1956
1957
1958
1959Fielding, et al.          Expires May 20, 2009                 [Page 35]
1960
1961Internet-Draft              HTTP/1.1, Part 2               November 2008
1962
1963
1964     Server         = "Server" ":" OWS Server-v
1965     Server-v       = product
1966                      *( RWS ( product / comment ) )
1967
1968   Example:
1969
1970     Server: CERN/3.0 libwww/2.17
1971
1972   If the response is being forwarded through a proxy, the proxy
1973   application MUST NOT modify the Server response-header.  Instead, it
1974   MUST include a Via field (as described in Section 8.9 of [Part1]).
1975
1976      Note: Revealing the specific software version of the server might
1977      allow the server machine to become more vulnerable to attacks
1978      against software that is known to contain security holes.  Server
1979      implementors are encouraged to make this field a configurable
1980      option.
1981
198210.9.  User-Agent
1983
1984   The request-header field "User-Agent" contains information about the
1985   user agent originating the request.  This is for statistical
1986   purposes, the tracing of protocol violations, and automated
1987   recognition of user agents for the sake of tailoring responses to
1988   avoid particular user agent limitations.  User agents SHOULD include
1989   this field with requests.  The field can contain multiple product
1990   tokens (Section 3.5 of [Part1]) and comments identifying the agent
1991   and any subproducts which form a significant part of the user agent.
1992   By convention, the product tokens are listed in order of their
1993   significance for identifying the application.
1994
1995     User-Agent     = "User-Agent" ":" OWS User-Agent-v
1996     User-Agent-v   = product
1997                      *( RWS ( product / comment ) )
1998
1999   Example:
2000
2001     User-Agent: CERN-LineMode/2.15 libwww/2.17b3
2002
2003
200411.  IANA Considerations
2005
200611.1.  Method Registry
2007
2008   The registration procedure for HTTP Methods is defined by Section 3.1
2009   of this document.
2010
2011   The HTTP Method Registry located at
2012
2013
2014
2015Fielding, et al.          Expires May 20, 2009                 [Page 36]
2016
2017Internet-Draft              HTTP/1.1, Part 2               November 2008
2018
2019
2020   <http://www.iana.org/assignments/http-methods> should be populated
2021   with the registrations below:
2022
2023   +---------+------+-------------+
2024   | Method  | Safe | Reference   |
2025   +---------+------+-------------+
2026   | CONNECT | no   | Section 8.9 |
2027   | DELETE  | no   | Section 8.7 |
2028   | GET     | yes  | Section 8.3 |
2029   | HEAD    | yes  | Section 8.4 |
2030   | OPTIONS | yes  | Section 8.2 |
2031   | POST    | no   | Section 8.5 |
2032   | PUT     | no   | Section 8.6 |
2033   | TRACE   | yes  | Section 8.8 |
2034   +---------+------+-------------+
2035
203611.2.  Status Code Registry
2037
2038   The registration procedure for HTTP Status Codes -- previously
2039   defined in Section 7.1 of [RFC2817] -- is now defined by Section 5.1
2040   of this document.
2041
2042   The HTTP Status Code Registry located at
2043   <http://www.iana.org/assignments/http-status-codes> should be updated
2044   with the registrations below:
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060
2061
2062
2063
2064
2065
2066
2067
2068
2069
2070
2071Fielding, et al.          Expires May 20, 2009                 [Page 37]
2072
2073Internet-Draft              HTTP/1.1, Part 2               November 2008
2074
2075
2076   +-------+---------------------------------+----------------+
2077   | Value | Description                     | Reference      |
2078   +-------+---------------------------------+----------------+
2079   | 100   | Continue                        | Section 9.1.1  |
2080   | 101   | Switching Protocols             | Section 9.1.2  |
2081   | 200   | OK                              | Section 9.2.1  |
2082   | 201   | Created                         | Section 9.2.2  |
2083   | 202   | Accepted                        | Section 9.2.3  |
2084   | 203   | Non-Authoritative Information   | Section 9.2.4  |
2085   | 204   | No Content                      | Section 9.2.5  |
2086   | 205   | Reset Content                   | Section 9.2.6  |
2087   | 206   | Partial Content                 | Section 9.2.7  |
2088   | 300   | Multiple Choices                | Section 9.3.1  |
2089   | 301   | Moved Permanently               | Section 9.3.2  |
2090   | 302   | Found                           | Section 9.3.3  |
2091   | 303   | See Other                       | Section 9.3.4  |
2092   | 304   | Not Modified                    | Section 9.3.5  |
2093   | 305   | Use Proxy                       | Section 9.3.6  |
2094   | 306   | (Unused)                        | Section 9.3.7  |
2095   | 307   | Temporary Redirect              | Section 9.3.8  |
2096   | 400   | Bad Request                     | Section 9.4.1  |
2097   | 401   | Unauthorized                    | Section 9.4.2  |
2098   | 402   | Payment Required                | Section 9.4.3  |
2099   | 403   | Forbidden                       | Section 9.4.4  |
2100   | 404   | Not Found                       | Section 9.4.5  |
2101   | 405   | Method Not Allowed              | Section 9.4.6  |
2102   | 406   | Not Acceptable                  | Section 9.4.7  |
2103   | 407   | Proxy Authentication Required   | Section 9.4.8  |
2104   | 408   | Request Timeout                 | Section 9.4.9  |
2105   | 409   | Conflict                        | Section 9.4.10 |
2106   | 410   | Gone                            | Section 9.4.11 |
2107   | 411   | Length Required                 | Section 9.4.12 |
2108   | 412   | Precondition Failed             | Section 9.4.13 |
2109   | 413   | Request Entity Too Large        | Section 9.4.14 |
2110   | 414   | Request-URI Too Long            | Section 9.4.15 |
2111   | 415   | Unsupported Media Type          | Section 9.4.16 |
2112   | 416   | Requested Range Not Satisfiable | Section 9.4.17 |
2113   | 417   | Expectation Failed              | Section 9.4.18 |
2114   | 500   | Internal Server Error           | Section 9.5.1  |
2115   | 501   | Not Implemented                 | Section 9.5.2  |
2116   | 502   | Bad Gateway                     | Section 9.5.3  |
2117   | 503   | Service Unavailable             | Section 9.5.4  |
2118   | 504   | Gateway Timeout                 | Section 9.5.5  |
2119   | 505   | HTTP Version Not Supported      | Section 9.5.6  |
2120   +-------+---------------------------------+----------------+
2121
2122
2123
2124
2125
2126
2127Fielding, et al.          Expires May 20, 2009                 [Page 38]
2128
2129Internet-Draft              HTTP/1.1, Part 2               November 2008
2130
2131
213211.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 10.1 |
2142   | Expect            | http     | standard | Section 10.2 |
2143   | From              | http     | standard | Section 10.3 |
2144   | Location          | http     | standard | Section 10.4 |
2145   | Max-Forwards      | http     | standard | Section 10.5 |
2146   | Referer           | http     | standard | Section 10.6 |
2147   | Retry-After       | http     | standard | Section 10.7 |
2148   | Server            | http     | standard | Section 10.8 |
2149   | User-Agent        | http     | standard | Section 10.9 |
2150   +-------------------+----------+----------+--------------+
2151
2152   The change controller is: "IETF (iesg@ietf.org) - Internet
2153   Engineering Task Force".
2154
2155
215612.  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
216412.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 May 20, 2009                 [Page 39]
2184
2185Internet-Draft              HTTP/1.1, Part 2               November 2008
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 10.9) or Server (Section 10.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
221712.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   URI.  Many existing servers, proxies, and user agents log or display
2234   the Request-URI in places where it might be visible to third parties.
2235   Such services can use POST-based form submission instead.
2236
2237
2238
2239Fielding, et al.          Expires May 20, 2009                 [Page 40]
2240
2241Internet-Draft              HTTP/1.1, Part 2               November 2008
2242
2243
224412.3.  Location Headers and Spoofing
2245
2246   If a single server supports multiple organizations that do not trust
2247   one another, then it MUST check the values of Location and Content-
2248   Location headers in responses that are generated under control of
2249   said organizations to make sure that they do not attempt to
2250   invalidate resources over which they have no authority.
2251
2252
225313.  Acknowledgments
2254
2255
225614.  References
2257
225814.1.  Normative References
2259
2260   [Part1]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
2261              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
2262              and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,
2263              and Message Parsing", draft-ietf-httpbis-p1-messaging-05
2264              (work in progress), November 2008.
2265
2266   [Part3]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
2267              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
2268              and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload
2269              and Content Negotiation", draft-ietf-httpbis-p3-payload-05
2270              (work in progress), November 2008.
2271
2272   [Part4]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
2273              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
2274              and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional
2275              Requests", draft-ietf-httpbis-p4-conditional-05 (work in
2276              progress), November 2008.
2277
2278   [Part5]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
2279              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
2280              and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and
2281              Partial Responses", draft-ietf-httpbis-p5-range-05 (work
2282              in progress), November 2008.
2283
2284   [Part6]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
2285              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
2286              and J. Reschke, Ed., "HTTP/1.1, part 6: Caching",
2287              draft-ietf-httpbis-p6-cache-05 (work in progress),
2288              November 2008.
2289
2290   [Part7]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
2291              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
2292
2293
2294
2295Fielding, et al.          Expires May 20, 2009                 [Page 41]
2296
2297Internet-Draft              HTTP/1.1, Part 2               November 2008
2298
2299
2300              and J. Reschke, Ed., "HTTP/1.1, part 7: Authentication",
2301              draft-ietf-httpbis-p7-auth-05 (work in progress),
2302              November 2008.
2303
2304   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
2305              Requirement Levels", BCP 14, RFC 2119, March 1997.
2306
230714.2.  Informative References
2308
2309   [RFC1945]  Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext
2310              Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
2311
2312   [RFC2068]  Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.
2313              Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
2314              RFC 2068, January 1997.
2315
2316   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
2317              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
2318              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
2319
2320   [RFC2817]  Khare, R. and S. Lawrence, "Upgrading to TLS Within
2321              HTTP/1.1", RFC 2817, May 2000.
2322
2323   [RFC3864]  Klyne, G., Nottingham, M., and J. Mogul, "Registration
2324              Procedures for Message Header Fields", BCP 90, RFC 3864,
2325              September 2004.
2326
2327   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
2328              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
2329              May 2008.
2330
2331   [RFC5322]  Resnick, P., "Internet Message Format", RFC 5322,
2332              October 2008.
2333
2334
2335Appendix A.  Compatibility with Previous Versions
2336
2337A.1.  Changes from RFC 2068
2338
2339   Clarified which error code should be used for inbound server failures
2340   (e.g.  DNS failures).  (Section 9.5.5).
2341
2342   201 (Created) had a race that required an Etag be sent when a
2343   resource is first created.  (Section 9.2.2).
2344
2345   Rewrite of message transmission requirements to make it much harder
2346   for implementors to get it wrong, as the consequences of errors here
2347   can have significant impact on the Internet, and to deal with the
2348
2349
2350
2351Fielding, et al.          Expires May 20, 2009                 [Page 42]
2352
2353Internet-Draft              HTTP/1.1, Part 2               November 2008
2354
2355
2356   following problems:
2357
2358   1.  Changing "HTTP/1.1 or later" to "HTTP/1.1", in contexts where
2359       this was incorrectly placing a requirement on the behavior of an
2360       implementation of a future version of HTTP/1.x
2361
2362   2.  Made it clear that user-agents should retry requests, not
2363       "clients" in general.
2364
2365   3.  Converted requirements for clients to ignore unexpected 100
2366       (Continue) responses, and for proxies to forward 100 responses,
2367       into a general requirement for 1xx responses.
2368
2369   4.  Modified some TCP-specific language, to make it clearer that non-
2370       TCP transports are possible for HTTP.
2371
2372   5.  Require that the origin server MUST NOT wait for the request body
2373       before it sends a required 100 (Continue) response.
2374
2375   6.  Allow, rather than require, a server to omit 100 (Continue) if it
2376       has already seen some of the request body.
2377
2378   7.  Allow servers to defend against denial-of-service attacks and
2379       broken clients.
2380
2381   This change adds the Expect header and 417 status code.
2382
2383   Clean up confusion between 403 and 404 responses.  (Section 9.4.4,
2384   9.4.5, and 9.4.11)
2385
2386   The PATCH, LINK, UNLINK methods were defined but not commonly
2387   implemented in previous versions of this specification.  See Section
2388   19.6.1 of [RFC2068].
2389
2390A.2.  Changes from RFC 2616
2391
2392   This document takes over the Status Code Registry, previously defined
2393   in Section 7.1 of [RFC2817].  (Section 5.1)
2394
2395   Clarify definition of POST.  (Section 8.5)
2396
2397   Failed to consider that there are many other request methods that are
2398   safe to automatically redirect, and further that the user agent is
2399   able to make that determination based on the request method
2400   semantics.  (Sections 9.3.2, 9.3.3 and 9.3.8)
2401
2402   Deprecate 305 Use Proxy status code, because user agents did not
2403   implement it.  It used to indicate that the requested resource must
2404
2405
2406
2407Fielding, et al.          Expires May 20, 2009                 [Page 43]
2408
2409Internet-Draft              HTTP/1.1, Part 2               November 2008
2410
2411
2412   be accessed through the proxy given by the Location field.  The
2413   Location field gave the URI of the proxy.  The recipient was expected
2414   to repeat this single request via the proxy.  (Section 9.3.6)
2415
2416   Reclassify Allow header as response header, removing the option to
2417   specify it in a PUT request.  Relax the server requirement on the
2418   contents of the Allow header and remove requirement on clients to
2419   always trust the header value.  (Section 10.1)
2420
2421   Correct syntax of Location header to allow fragment, as referred
2422   symbol wasn't what was expected, and add some clarifications as to
2423   when it would not be appropriate.  (Section 10.4)
2424
2425   In the description of the Server header, the Via field was described
2426   as a SHOULD.  The requirement was and is stated correctly in the
2427   description of the Via header in Section 8.9 of [Part1].
2428   (Section 10.8)
2429
2430
2431Appendix B.  Change Log (to be removed by RFC Editor before publication)
2432
2433B.1.  Since RFC2616
2434
2435   Extracted relevant partitions from [RFC2616].
2436
2437B.2.  Since draft-ietf-httpbis-p2-semantics-00
2438
2439   Closed issues:
2440
2441   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/5>: "Via is a MUST"
2442      (<http://purl.org/NET/http-errata#via-must>)
2443
2444   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/6>: "Fragments
2445      allowed in Location"
2446      (<http://purl.org/NET/http-errata#location-fragments>)
2447
2448   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/10>: "Safe Methods
2449      vs Redirection" (<http://purl.org/NET/http-errata#saferedirect>)
2450
2451   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/17>: "Revise
2452      description of the POST method"
2453      (<http://purl.org/NET/http-errata#post>)
2454
2455   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and
2456      Informative references"
2457
2458   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/42>: "RFC2606
2459      Compliance"
2460
2461
2462
2463Fielding, et al.          Expires May 20, 2009                 [Page 44]
2464
2465Internet-Draft              HTTP/1.1, Part 2               November 2008
2466
2467
2468   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/65>: "Informative
2469      references"
2470
2471   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/84>: "Redundant
2472      cross-references"
2473
2474   Other changes:
2475
2476   o  Move definitions of 304 and 412 condition codes to [Part4]
2477
2478B.3.  Since draft-ietf-httpbis-p2-semantics-01
2479
2480   Closed issues:
2481
2482   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/21>: "PUT side
2483      effects"
2484
2485   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/91>: "Duplicate Host
2486      header requirements"
2487
2488   Ongoing work on ABNF conversion
2489   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
2490
2491   o  Move "Product Tokens" section (back) into Part 1, as "token" is
2492      used in the definition of the Upgrade header.
2493
2494   o  Add explicit references to BNF syntax and rules imported from
2495      other parts of the specification.
2496
2497   o  Copy definition of delta-seconds from Part6 instead of referencing
2498      it.
2499
2500B.4.  Since draft-ietf-httpbis-p2-semantics-02
2501
2502   Closed issues:
2503
2504   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/24>: "Requiring
2505      Allow in 405 responses"
2506
2507   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/59>: "Status Code
2508      Registry"
2509
2510   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/61>: "Redirection
2511      vs. Location"
2512
2513   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/70>: "Cacheability
2514      of 303 response"
2515
2516
2517
2518
2519Fielding, et al.          Expires May 20, 2009                 [Page 45]
2520
2521Internet-Draft              HTTP/1.1, Part 2               November 2008
2522
2523
2524   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/76>: "305 Use Proxy"
2525
2526   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/105>:
2527      "Classification for Allow header"
2528
2529   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/112>: "PUT - 'store
2530      under' vs 'store at'"
2531
2532   Ongoing work on IANA Message Header Registration
2533   (<http://tools.ietf.org/wg/httpbis/trac/ticket/40>):
2534
2535   o  Reference RFC 3984, and update header registrations for headers
2536      defined in this document.
2537
2538   Ongoing work on ABNF conversion
2539   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
2540
2541   o  Replace string literals when the string really is case-sensitive
2542      (method).
2543
2544B.5.  Since draft-ietf-httpbis-p2-semantics-03
2545
2546   Closed issues:
2547
2548   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/98>: "OPTIONS
2549      request bodies"
2550
2551   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/119>: "Description
2552      of CONNECT should refer to RFC2817"
2553
2554   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/125>: "Location
2555      Content-Location reference request/response mixup"
2556
2557   Ongoing work on Method Registry
2558   (<http://tools.ietf.org/wg/httpbis/trac/ticket/72>):
2559
2560   o  Added initial proposal for registration process, plus initial
2561      content (non-HTTP/1.1 methods to be added by a separate
2562      specification).
2563
2564B.6.  Since draft-ietf-httpbis-p2-semantics-04
2565
2566   Closed issues:
2567
2568   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/103>: "Content-*"
2569
2570   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/132>: "RFC 2822 is
2571      updated by RFC 5322"
2572
2573
2574
2575Fielding, et al.          Expires May 20, 2009                 [Page 46]
2576
2577Internet-Draft              HTTP/1.1, Part 2               November 2008
2578
2579
2580   Ongoing work on ABNF conversion
2581   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
2582
2583   o  Use "/" instead of "|" for alternatives.
2584
2585   o  Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
2586      whitespace ("OWS") and required whitespace ("RWS").
2587
2588   o  Rewrite ABNFs to spell out whitespace rules, factor out header
2589      value format definitions.
2590
2591
2592Index
2593
2594   1
2595      100 Continue (status code)  19
2596      101 Switching Protocols (status code)  20
2597
2598   2
2599      200 OK (status code)  20
2600      201 Created (status code)  20
2601      202 Accepted (status code)  21
2602      203 Non-Authoritative Information (status code)  21
2603      204 No Content (status code)  21
2604      205 Reset Content (status code)  22
2605      206 Partial Content (status code)  22
2606
2607   3
2608      300 Multiple Choices (status code)  22
2609      301 Moved Permanently (status code)  23
2610      302 Found (status code)  23
2611      303 See Other (status code)  24
2612      304 Not Modified (status code)  25
2613      305 Use Proxy (status code)  25
2614      306 (Unused) (status code)  25
2615      307 Temporary Redirect (status code)  25
2616
2617   4
2618      400 Bad Request (status code)  26
2619      401 Unauthorized (status code)  26
2620      402 Payment Required (status code)  26
2621      403 Forbidden (status code)  26
2622      404 Not Found (status code)  26
2623      405 Method Not Allowed (status code)  27
2624      406 Not Acceptable (status code)  27
2625      407 Proxy Authentication Required (status code)  27
2626      408 Request Timeout (status code)  27
2627      409 Conflict (status code)  27
2628
2629
2630
2631Fielding, et al.          Expires May 20, 2009                 [Page 47]
2632
2633Internet-Draft              HTTP/1.1, Part 2               November 2008
2634
2635
2636      410 Gone (status code)  28
2637      411 Length Required (status code)  28
2638      412 Precondition Failed (status code)  28
2639      413 Request Entity Too Large (status code)  29
2640      414 Request-URI Too Long (status code)  29
2641      415 Unsupported Media Type (status code)  29
2642      416 Requested Range Not Satisfiable (status code)  29
2643      417 Expectation Failed (status code)  29
2644
2645   5
2646      500 Internal Server Error (status code)  30
2647      501 Not Implemented (status code)  30
2648      502 Bad Gateway (status code)  30
2649      503 Service Unavailable (status code)  30
2650      504 Gateway Timeout (status code)  30
2651      505 HTTP Version Not Supported (status code)  31
2652
2653   A
2654      Allow header  31
2655
2656   C
2657      CONNECT method  19
2658
2659   D
2660      DELETE method  18
2661
2662   E
2663      Expect header  31
2664
2665   F
2666      From header  32
2667
2668   G
2669      GET method  15
2670      Grammar
2671         Allow  31
2672         Allow-v  31
2673         delta-seconds  35
2674         Expect  32
2675         expect-params  32
2676         Expect-v  32
2677         expectation  32
2678         expectation-extension  32
2679         extension-code  11
2680         extension-method  8
2681         From  32
2682         From-v  32
2683         Location  33
2684
2685
2686
2687Fielding, et al.          Expires May 20, 2009                 [Page 48]
2688
2689Internet-Draft              HTTP/1.1, Part 2               November 2008
2690
2691
2692         Location-v  33
2693         Max-Forwards  34
2694         Max-Forwards-v  34
2695         Method  8
2696         Reason-Phrase  11
2697         Referer  35
2698         Referer-v  35
2699         request-header  9
2700         response-header  12
2701         Retry-After  35
2702         Retry-After-v  35
2703         Server  36
2704         Server-v  36
2705         Status-Code  11
2706         User-Agent  36
2707         User-Agent-v  36
2708
2709   H
2710      HEAD method  16
2711      Headers
2712         Allow  31
2713         Expect  31
2714         From  32
2715         Location  33
2716         Max-Forwards  34
2717         Referer  34
2718         Retry-After  35
2719         Server  35
2720         User-Agent  36
2721
2722   I
2723      Idempotent Methods  14
2724
2725   L
2726      LINK method  43
2727      Location header  33
2728
2729   M
2730      Max-Forwards header  34
2731      Methods
2732         CONNECT  19
2733         DELETE  18
2734         GET  15
2735         HEAD  16
2736         LINK  43
2737         OPTIONS  14
2738         PATCH  43
2739         POST  16
2740
2741
2742
2743Fielding, et al.          Expires May 20, 2009                 [Page 49]
2744
2745Internet-Draft              HTTP/1.1, Part 2               November 2008
2746
2747
2748         PUT  17
2749         TRACE  18
2750         UNLINK  43
2751
2752   O
2753      OPTIONS method  14
2754
2755   P
2756      PATCH method  43
2757      POST method  16
2758      PUT method  17
2759
2760   R
2761      Referer header  34
2762      Retry-After header  35
2763
2764   S
2765      Safe Methods  13
2766      Server header  35
2767      Status Codes
2768         100 Continue  19
2769         101 Switching Protocols  20
2770         200 OK  20
2771         201 Created  20
2772         202 Accepted  21
2773         203 Non-Authoritative Information  21
2774         204 No Content  21
2775         205 Reset Content  22
2776         206 Partial Content  22
2777         300 Multiple Choices  22
2778         301 Moved Permanently  23
2779         302 Found  23
2780         303 See Other  24
2781         304 Not Modified  25
2782         305 Use Proxy  25
2783         306 (Unused)  25
2784         307 Temporary Redirect  25
2785         400 Bad Request  26
2786         401 Unauthorized  26
2787         402 Payment Required  26
2788         403 Forbidden  26
2789         404 Not Found  26
2790         405 Method Not Allowed  27
2791         406 Not Acceptable  27
2792         407 Proxy Authentication Required  27
2793         408 Request Timeout  27
2794         409 Conflict  27
2795         410 Gone  28
2796
2797
2798
2799Fielding, et al.          Expires May 20, 2009                 [Page 50]
2800
2801Internet-Draft              HTTP/1.1, Part 2               November 2008
2802
2803
2804         411 Length Required  28
2805         412 Precondition Failed  28
2806         413 Request Entity Too Large  29
2807         414 Request-URI Too Long  29
2808         415 Unsupported Media Type  29
2809         416 Requested Range Not Satisfiable  29
2810         417 Expectation Failed  29
2811         500 Internal Server Error  30
2812         501 Not Implemented  30
2813         502 Bad Gateway  30
2814         503 Service Unavailable  30
2815         504 Gateway Timeout  30
2816         505 HTTP Version Not Supported  31
2817
2818   T
2819      TRACE method  18
2820
2821   U
2822      UNLINK method  43
2823      User-Agent header  36
2824
2825
2826Authors' Addresses
2827
2828   Roy T. Fielding (editor)
2829   Day Software
2830   23 Corporate Plaza DR, Suite 280
2831   Newport Beach, CA  92660
2832   USA
2833
2834   Phone: +1-949-706-5300
2835   Fax:   +1-949-706-5305
2836   Email: fielding@gbiv.com
2837   URI:   http://roy.gbiv.com/
2838
2839
2840   Jim Gettys
2841   One Laptop per Child
2842   21 Oak Knoll Road
2843   Carlisle, MA  01741
2844   USA
2845
2846   Email: jg@laptop.org
2847   URI:   http://www.laptop.org/
2848
2849
2850
2851
2852
2853
2854
2855Fielding, et al.          Expires May 20, 2009                 [Page 51]
2856
2857Internet-Draft              HTTP/1.1, Part 2               November 2008
2858
2859
2860   Jeffrey C. Mogul
2861   Hewlett-Packard Company
2862   HP Labs, Large Scale Systems Group
2863   1501 Page Mill Road, MS 1177
2864   Palo Alto, CA  94304
2865   USA
2866
2867   Email: JeffMogul@acm.org
2868
2869
2870   Henrik Frystyk Nielsen
2871   Microsoft Corporation
2872   1 Microsoft Way
2873   Redmond, WA  98052
2874   USA
2875
2876   Email: henrikn@microsoft.com
2877
2878
2879   Larry Masinter
2880   Adobe Systems, Incorporated
2881   345 Park Ave
2882   San Jose, CA  95110
2883   USA
2884
2885   Email: LMM@acm.org
2886   URI:   http://larry.masinter.net/
2887
2888
2889   Paul J. Leach
2890   Microsoft Corporation
2891   1 Microsoft Way
2892   Redmond, WA  98052
2893
2894   Email: paulle@microsoft.com
2895
2896
2897   Tim Berners-Lee
2898   World Wide Web Consortium
2899   MIT Computer Science and Artificial Intelligence Laboratory
2900   The Stata Center, Building 32
2901   32 Vassar Street
2902   Cambridge, MA  02139
2903   USA
2904
2905   Email: timbl@w3.org
2906   URI:   http://www.w3.org/People/Berners-Lee/
2907
2908
2909
2910
2911Fielding, et al.          Expires May 20, 2009                 [Page 52]
2912
2913Internet-Draft              HTTP/1.1, Part 2               November 2008
2914
2915
2916   Yves Lafon (editor)
2917   World Wide Web Consortium
2918   W3C / ERCIM
2919   2004, rte des Lucioles
2920   Sophia-Antipolis, AM  06902
2921   France
2922
2923   Email: ylafon@w3.org
2924   URI:   http://www.raubacapeu.net/people/yves/
2925
2926
2927   Julian F. Reschke (editor)
2928   greenbytes GmbH
2929   Hafenweg 16
2930   Muenster, NW  48155
2931   Germany
2932
2933   Phone: +49 251 2807760
2934   Fax:   +49 251 2807761
2935   Email: julian.reschke@greenbytes.de
2936   URI:   http://greenbytes.de/tech/webdav/
2937
2938
2939
2940
2941
2942
2943
2944
2945
2946
2947
2948
2949
2950
2951
2952
2953
2954
2955
2956
2957
2958
2959
2960
2961
2962
2963
2964
2965
2966
2967Fielding, et al.          Expires May 20, 2009                 [Page 53]
2968
2969Internet-Draft              HTTP/1.1, Part 2               November 2008
2970
2971
2972Full Copyright Statement
2973
2974   Copyright (C) The IETF Trust (2008).
2975
2976   This document is subject to the rights, licenses and restrictions
2977   contained in BCP 78, and except as set forth therein, the authors
2978   retain all their rights.
2979
2980   This document and the information contained herein are provided on an
2981   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
2982   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
2983   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
2984   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
2985   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
2986   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
2987
2988
2989Intellectual Property
2990
2991   The IETF takes no position regarding the validity or scope of any
2992   Intellectual Property Rights or other rights that might be claimed to
2993   pertain to the implementation or use of the technology described in
2994   this document or the extent to which any license under such rights
2995   might or might not be available; nor does it represent that it has
2996   made any independent effort to identify any such rights.  Information
2997   on the procedures with respect to rights in RFC documents can be
2998   found in BCP 78 and BCP 79.
2999
3000   Copies of IPR disclosures made to the IETF Secretariat and any
3001   assurances of licenses to be made available, or the result of an
3002   attempt made to obtain a general license or permission for the use of
3003   such proprietary rights by implementers or users of this
3004   specification can be obtained from the IETF on-line IPR repository at
3005   http://www.ietf.org/ipr.
3006
3007   The IETF invites any interested party to bring to its attention any
3008   copyrights, patents or patent applications, or other proprietary
3009   rights that may cover technology that may be required to implement
3010   this standard.  Please address the information to the IETF at
3011   ietf-ipr@ietf.org.
3012
3013
3014
3015
3016
3017
3018
3019
3020
3021
3022
3023Fielding, et al.          Expires May 20, 2009                 [Page 54]
3024
Note: See TracBrowser for help on using the repository browser.