source: draft-ietf-httpbis/04/draft-ietf-httpbis-p2-semantics-04.txt @ 315

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

prepare publication of draft -04, also remove unneeded cookie drafts

File size: 113.9 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: March 2, 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                                                         August 29, 2008
23
24
25                  HTTP/1.1, part 2: Message Semantics
26                   draft-ietf-httpbis-p2-semantics-04
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 March 2, 2009.
52
53
54
55Fielding, et al.          Expires March 2, 2009                 [Page 1]
56
57Internet-Draft              HTTP/1.1, Part 2                 August 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://www.tools.ietf.org/wg/httpbis/trac/report/11> and related
77   documents (including fancy diffs) can be found at
78   <http://www.tools.ietf.org/wg/httpbis/>.
79
80   The changes in this draft are summarized in Appendix B.4.
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 March 2, 2009                 [Page 2]
112
113Internet-Draft              HTTP/1.1, Part 2                 August 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  . . . . . . . . . . . . . . . .  9
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 March 2, 2009                 [Page 3]
168
169Internet-Draft              HTTP/1.1, Part 2                 August 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 March 2, 2009                 [Page 4]
224
225Internet-Draft              HTTP/1.1, Part 2                 August 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   Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
236   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50
237   Intellectual Property and Copyright Statements . . . . . . . . . . 54
238
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 March 2, 2009                 [Page 5]
280
281Internet-Draft              HTTP/1.1, Part 2                 August 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   [[abnf.dep: ABNF syntax and basic rules will be adopted from RFC
327   5234, see <http://tools.ietf.org/wg/httpbis/trac/ticket/36>.]]
328
329     DIGIT         = <DIGIT, defined in [Part1], Section 2.2>
330
331
332
333
334
335Fielding, et al.          Expires March 2, 2009                 [Page 6]
336
337Internet-Draft              HTTP/1.1, Part 2                 August 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
344   The ABNF rules below are defined in other parts:
345
346     absoluteURI   = <absoluteURI, defined in [Part1], Section 3.2.1>
347     fragment      = <fragment, defined in [Part1], Section 3.2.1>
348     Host          = <Host, defined in [Part1], Section 8.4>
349     HTTP-date     = <HTTP-date, defined in [Part1], Section 3.3.1>
350     product       = <product, defined in [Part1], Section 3.5>
351     relativeURI   = <relativeURI, defined in [Part1], Section 3.2.1>
352     TE            = <TE, defined in [Part1], Section 8.8>
353
354
355     Accept        = <Accept, defined in [Part3], Section 6.1>
356     Accept-Charset =
357                <Accept-Charset, defined in [Part3], Section 6.2>
358     Accept-Encoding =
359                <Accept-Encoding, defined in [Part3], Section 6.3>
360     Accept-Language =
361                <Accept-Language, defined in [Part3], Section 6.4>
362
363
364     ETag          = <ETag, defined in [Part4], Section 7.1>
365     If-Match      = <If-Match, defined in [Part4], Section 7.2>
366     If-Modified-Since =
367                <If-Modified-Since, defined in [Part4], Section 7.3>
368     If-None-Match = <If-None-Match, defined in [Part4], Section 7.4>
369     If-Unmodified-Since =
370                <If-Unmodified-Since, defined in [Part4], Section 7.5>
371
372
373     Accept-Ranges = <Accept-Ranges, defined in [Part5], Section 6.1>
374     If-Range      = <If-Range, defined in [Part5], Section 6.3>
375     Range         = <Range, defined in [Part5], Section 6.4>
376
377
378     Age           = <Age, defined in [Part6], Section 16.1>
379     Vary          = <Vary, defined in [Part6], Section 16.5>
380
381
382     Authorization = <Authorization, defined in [Part7], Section 4.1>
383     Proxy-Authenticate =
384                <Proxy-Authenticate, defined in [Part7], Section 4.2>
385     Proxy-Authorization =
386                <Proxy-Authorization, defined in [Part7], Section 4.3>
387     WWW-Authenticate =
388
389
390
391Fielding, et al.          Expires March 2, 2009                 [Page 7]
392
393Internet-Draft              HTTP/1.1, Part 2                 August 2008
394
395
396                <WWW-Authenticate, defined in [Part7], Section 4.4>
397
398
3993.  Method
400
401   The Method token indicates the method to be performed on the resource
402   identified by the Request-URI.  The method is case-sensitive.
403
404     Method         = %x4F.50.54.49.4F.4E.53   ; "OPTIONS", Section 8.2
405                    | %x47.45.54               ; "GET", Section 8.3
406                    | %x48.45.41.44            ; "HEAD", Section 8.4
407                    | %x50.4F.53.54            ; "POST", Section 8.5
408                    | %x50.55.54               ; "PUT", Section 8.6
409                    | %x44.45.4C.45.54.45      ; "DELETE", Section 8.7
410                    | %x54.52.41.43.45         ; "TRACE", Section 8.8
411                    | %x43.4F.4E.4E.45.43.54   ; "CONNECT", Section 8.9
412                    | extension-method
413     extension-method = token
414
415   The list of methods allowed by a resource can be specified in an
416   Allow header field (Section 10.1).  The return code of the response
417   always notifies the client whether a method is currently allowed on a
418   resource, since the set of allowed methods can change dynamically.
419   An origin server SHOULD return the status code 405 (Method Not
420   Allowed) if the method is known by the origin server but not allowed
421   for the requested resource, and 501 (Not Implemented) if the method
422   is unrecognized or not implemented by the origin server.  The methods
423   GET and HEAD MUST be supported by all general-purpose servers.  All
424   other methods are OPTIONAL; however, if the above methods are
425   implemented, they MUST be implemented with the same semantics as
426   those specified in Section 8.
427
4283.1.  Method Registry
429
430   The HTTP Method Registry defines the name space for the Method token
431   in the Request line of an HTTP request.
432
433   Registrations MUST include the following fields:
434
435   o  Method Name (see Section 3)
436
437   o  Safe ("yes" or "no", see Section 8.1.1)
438
439   o  Pointer to specification text
440
441   Values to be added to this name space are subject to IETF review
442   ([RFC5226], Section 4.1).  Any document registering new method names
443   should be traceable through statuses of either 'Obsoletes' or
444
445
446
447Fielding, et al.          Expires March 2, 2009                 [Page 8]
448
449Internet-Draft              HTTP/1.1, Part 2                 August 2008
450
451
452   'Updates' to this document.
453
454   The registry itself is maintained at
455   <http://www.iana.org/assignments/http-methods>.
456
457
4584.  Request Header Fields
459
460   The request-header fields allow the client to pass additional
461   information about the request, and about the client itself, to the
462   server.  These fields act as request modifiers, with semantics
463   equivalent to the parameters on a programming language method
464   invocation.
465
466     request-header = Accept                   ; [Part3], Section 6.1
467                    | Accept-Charset           ; [Part3], Section 6.2
468                    | Accept-Encoding          ; [Part3], Section 6.3
469                    | Accept-Language          ; [Part3], Section 6.4
470                    | Authorization            ; [Part7], Section 4.1
471                    | Expect                   ; Section 10.2
472                    | From                     ; Section 10.3
473                    | Host                     ; [Part1], Section 8.4
474                    | If-Match                 ; [Part4], Section 7.2
475                    | If-Modified-Since        ; [Part4], Section 7.3
476                    | If-None-Match            ; [Part4], Section 7.4
477                    | If-Range                 ; [Part5], Section 6.3
478                    | If-Unmodified-Since      ; [Part4], Section 7.5
479                    | Max-Forwards             ; Section 10.5
480                    | Proxy-Authorization      ; [Part7], Section 4.3
481                    | Range                    ; [Part5], Section 6.4
482                    | Referer                  ; Section 10.6
483                    | TE                       ; [Part1], Section 8.8
484                    | User-Agent               ; Section 10.9
485
486   Request-header field names can be extended reliably only in
487   combination with a change in the protocol version.  However, new or
488   experimental header fields MAY be given the semantics of request-
489   header fields if all parties in the communication recognize them to
490   be request-header fields.  Unrecognized header fields are treated as
491   entity-header fields.
492
493
4945.  Status Code and Reason Phrase
495
496   The Status-Code element is a 3-digit integer result code of the
497   attempt to understand and satisfy the request.  The status codes
498   listed below are defined in Section 9.  The Reason-Phrase is intended
499   to give a short textual description of the Status-Code.  The Status-
500
501
502
503Fielding, et al.          Expires March 2, 2009                 [Page 9]
504
505Internet-Draft              HTTP/1.1, Part 2                 August 2008
506
507
508   Code is intended for use by automata and the Reason-Phrase is
509   intended for the human user.  The client is not required to examine
510   or display the Reason-Phrase.
511
512   The individual values of the numeric status codes defined for
513   HTTP/1.1, and an example set of corresponding Reason-Phrase's, are
514   presented below.  The reason phrases listed here are only
515   recommendations -- they MAY be replaced by local equivalents without
516   affecting the protocol.
517
518
519
520
521
522
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 March 2, 2009                [Page 10]
560
561Internet-Draft              HTTP/1.1, Part 2                 August 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 March 2, 2009                [Page 11]
616
617Internet-Draft              HTTP/1.1, Part 2                 August 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 March 2, 2009                [Page 12]
672
673Internet-Draft              HTTP/1.1, Part 2                 August 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 March 2, 2009                [Page 13]
728
729Internet-Draft              HTTP/1.1, Part 2                 August 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 March 2, 2009                [Page 14]
784
785Internet-Draft              HTTP/1.1, Part 2                 August 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 absoluteURI 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 March 2, 2009                [Page 15]
840
841Internet-Draft              HTTP/1.1, Part 2                 August 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 March 2, 2009                [Page 16]
896
897Internet-Draft              HTTP/1.1, Part 2                 August 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-* (e.g.  Content-Range) headers that it does
929   not understand or implement and MUST return a 501 (Not Implemented)
930   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 March 2, 2009                [Page 17]
952
953Internet-Draft              HTTP/1.1, Part 2                 August 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 March 2, 2009                [Page 18]
1008
1009Internet-Draft              HTTP/1.1, Part 2                 August 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 March 2, 2009                [Page 19]
1064
1065Internet-Draft              HTTP/1.1, Part 2                 August 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 March 2, 2009                [Page 20]
1120
1121Internet-Draft              HTTP/1.1, Part 2                 August 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 March 2, 2009                [Page 21]
1176
1177Internet-Draft              HTTP/1.1, Part 2                 August 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 March 2, 2009                [Page 22]
1232
1233Internet-Draft              HTTP/1.1, Part 2                 August 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 March 2, 2009                [Page 23]
1288
1289Internet-Draft              HTTP/1.1, Part 2                 August 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 March 2, 2009                [Page 24]
1344
1345Internet-Draft              HTTP/1.1, Part 2                 August 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 March 2, 2009                [Page 25]
1400
1401Internet-Draft              HTTP/1.1, Part 2                 August 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 March 2, 2009                [Page 26]
1456
1457Internet-Draft              HTTP/1.1, Part 2                 August 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 March 2, 2009                [Page 27]
1512
1513Internet-Draft              HTTP/1.1, Part 2                 August 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 March 2, 2009                [Page 28]
1568
1569Internet-Draft              HTTP/1.1, Part 2                 August 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 March 2, 2009                [Page 29]
1624
1625Internet-Draft              HTTP/1.1, Part 2                 August 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 March 2, 2009                [Page 30]
1680
1681Internet-Draft              HTTP/1.1, Part 2                 August 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 Allow response-header field 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" ":" #Method
1713
1714   Example of use:
1715
1716          Allow: GET, HEAD, PUT
1717
1718   The actual set of allowed methods is defined by the origin server at
1719   the time of each request.
1720
1721   A proxy MUST NOT modify the Allow header field even if it does not
1722   understand all the methods specified, since the user agent might have
1723   other means of communicating with the origin server.
1724
172510.2.  Expect
1726
1727   The Expect request-header field is used to indicate that particular
1728   server behaviors are required by the client.
1729
1730
1731
1732
1733
1734
1735Fielding, et al.          Expires March 2, 2009                [Page 31]
1736
1737Internet-Draft              HTTP/1.1, Part 2                 August 2008
1738
1739
1740     Expect       =  "Expect" ":" 1#expectation
1741
1742     expectation  =  "100-continue" | expectation-extension
1743     expectation-extension =  token [ "=" ( token | quoted-string )
1744                              *expect-params ]
1745     expect-params =  ";" token [ "=" ( token | quoted-string ) ]
1746
1747   A server that does not understand or is unable to comply with any of
1748   the expectation values in the Expect field of a request MUST respond
1749   with appropriate error status.  The server MUST respond with a 417
1750   (Expectation Failed) status if any of the expectations cannot be met
1751   or, if there are other problems with the request, some other 4xx
1752   status.
1753
1754   This header field is defined with extensible syntax to allow for
1755   future extensions.  If a server receives a request containing an
1756   Expect field that includes an expectation-extension that it does not
1757   support, it MUST respond with a 417 (Expectation Failed) status.
1758
1759   Comparison of expectation values is case-insensitive for unquoted
1760   tokens (including the 100-continue token), and is case-sensitive for
1761   quoted-string expectation-extensions.
1762
1763   The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy MUST
1764   return a 417 (Expectation Failed) status if it receives a request
1765   with an expectation that it cannot meet.  However, the Expect
1766   request-header itself is end-to-end; it MUST be forwarded if the
1767   request is forwarded.
1768
1769   Many older HTTP/1.0 and HTTP/1.1 applications do not understand the
1770   Expect header.
1771
1772   See Section 7.2.3 of [Part1] for the use of the 100 (Continue)
1773   status.
1774
177510.3.  From
1776
1777   The From request-header field, if given, SHOULD contain an Internet
1778   e-mail address for the human user who controls the requesting user
1779   agent.  The address SHOULD be machine-usable, as defined by "mailbox"
1780   in Section 3.4 of [RFC2822]:
1781
1782     From    = "From" ":" mailbox
1783
1784     mailbox = <mailbox, defined in [RFC2822], Section 3.4>
1785
1786   An example is:
1787
1788
1789
1790
1791Fielding, et al.          Expires March 2, 2009                [Page 32]
1792
1793Internet-Draft              HTTP/1.1, Part 2                 August 2008
1794
1795
1796       From: webmaster@example.org
1797
1798   This header field MAY be used for logging purposes and as a means for
1799   identifying the source of invalid or unwanted requests.  It SHOULD
1800   NOT be used as an insecure form of access protection.  The
1801   interpretation of this field is that the request is being performed
1802   on behalf of the person given, who accepts responsibility for the
1803   method performed.  In particular, robot agents SHOULD include this
1804   header so that the person responsible for running the robot can be
1805   contacted if problems occur on the receiving end.
1806
1807   The Internet e-mail address in this field MAY be separate from the
1808   Internet host which issued the request.  For example, when a request
1809   is passed through a proxy the original issuer's address SHOULD be
1810   used.
1811
1812   The client SHOULD NOT send the From header field without the user's
1813   approval, as it might conflict with the user's privacy interests or
1814   their site's security policy.  It is strongly recommended that the
1815   user be able to disable, enable, and modify the value of this field
1816   at any time prior to a request.
1817
181810.4.  Location
1819
1820   The Location response-header field is used for the identification of
1821   a new resource or to redirect the recipient to a location other than
1822   the Request-URI for completion of the request.  For 201 (Created)
1823   responses, the Location is that of the new resource which was created
1824   by the request.  For 3xx responses, the location SHOULD indicate the
1825   server's preferred URI for automatic redirection to the resource.
1826   The field value consists of a single absolute URI.
1827
1828     Location       = "Location" ":" absoluteURI [ "#" fragment ]
1829
1830   An example is:
1831
1832       Location: http://www.example.org/pub/WWW/People.html
1833
1834      Note: The Content-Location header field (Section 6.7 of [Part3])
1835      differs from Location in that the Content-Location identifies the
1836      original location of the entity enclosed in the response.  It is
1837      therefore possible for a response to contain header fields for
1838      both Location and Content-Location.
1839
1840   There are circumstances in which a fragment identifier in a Location
1841   URL would not be appropriate:
1842
1843
1844
1845
1846
1847Fielding, et al.          Expires March 2, 2009                [Page 33]
1848
1849Internet-Draft              HTTP/1.1, Part 2                 August 2008
1850
1851
1852   o  With a 201 Created response, because in this usage the Location
1853      header specifies the URL for the entire created resource.
1854
1855   o  With a 300 Multiple Choices, since the choice decision is intended
1856      to be made on resource characteristics and not fragment
1857      characteristics.
1858
1859   o  With 305 Use Proxy.
1860
186110.5.  Max-Forwards
1862
1863   The Max-Forwards request-header field provides a mechanism with the
1864   TRACE (Section 8.8) and OPTIONS (Section 8.2) methods to limit the
1865   number of proxies or gateways that can forward the request to the
1866   next inbound server.  This can be useful when the client is
1867   attempting to trace a request chain which appears to be failing or
1868   looping in mid-chain.
1869
1870     Max-Forwards   = "Max-Forwards" ":" 1*DIGIT
1871
1872   The Max-Forwards value is a decimal integer indicating the remaining
1873   number of times this request message may be forwarded.
1874
1875   Each proxy or gateway recipient of a TRACE or OPTIONS request
1876   containing a Max-Forwards header field MUST check and update its
1877   value prior to forwarding the request.  If the received value is zero
1878   (0), the recipient MUST NOT forward the request; instead, it MUST
1879   respond as the final recipient.  If the received Max-Forwards value
1880   is greater than zero, then the forwarded message MUST contain an
1881   updated Max-Forwards field with a value decremented by one (1).
1882
1883   The Max-Forwards header field MAY be ignored for all other methods
1884   defined by this specification and for any extension methods for which
1885   it is not explicitly referred to as part of that method definition.
1886
188710.6.  Referer
1888
1889   The Referer[sic] request-header field allows the client to specify,
1890   for the server's benefit, the address (URI) of the resource from
1891   which the Request-URI was obtained (the "referrer", although the
1892   header field is misspelled.)  The Referer request-header allows a
1893   server to generate lists of back-links to resources for interest,
1894   logging, optimized caching, etc.  It also allows obsolete or mistyped
1895   links to be traced for maintenance.  The Referer field MUST NOT be
1896   sent if the Request-URI was obtained from a source that does not have
1897   its own URI, such as input from the user keyboard.
1898
1899     Referer        = "Referer" ":" ( absoluteURI | relativeURI )
1900
1901
1902
1903Fielding, et al.          Expires March 2, 2009                [Page 34]
1904
1905Internet-Draft              HTTP/1.1, Part 2                 August 2008
1906
1907
1908   Example:
1909
1910       Referer: http://www.example.org/hypertext/Overview.html
1911
1912   If the field value is a relative URI, it SHOULD be interpreted
1913   relative to the Request-URI.  The URI MUST NOT include a fragment.
1914   See Section 12.2 for security considerations.
1915
191610.7.  Retry-After
1917
1918   The Retry-After response-header field can be used with a 503 (Service
1919   Unavailable) response to indicate how long the service is expected to
1920   be unavailable to the requesting client.  This field MAY also be used
1921   with any 3xx (Redirection) response to indicate the minimum time the
1922   user-agent is asked wait before issuing the redirected request.  The
1923   value of this field can be either an HTTP-date or an integer number
1924   of seconds (in decimal) after the time of the response.
1925
1926     Retry-After   = "Retry-After" ":" ( HTTP-date | delta-seconds )
1927
1928   Time spans are non-negative decimal integers, representing time in
1929   seconds.
1930
1931     delta-seconds  = 1*DIGIT
1932
1933   Two examples of its use are
1934
1935       Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
1936       Retry-After: 120
1937
1938   In the latter example, the delay is 2 minutes.
1939
194010.8.  Server
1941
1942   The Server response-header field contains information about the
1943   software used by the origin server to handle the request.  The field
1944   can contain multiple product tokens (Section 3.5 of [Part1]) and
1945   comments identifying the server and any significant subproducts.  The
1946   product tokens are listed in order of their significance for
1947   identifying the application.
1948
1949     Server         = "Server" ":" 1*( product | comment )
1950
1951   Example:
1952
1953       Server: CERN/3.0 libwww/2.17
1954
1955   If the response is being forwarded through a proxy, the proxy
1956
1957
1958
1959Fielding, et al.          Expires March 2, 2009                [Page 35]
1960
1961Internet-Draft              HTTP/1.1, Part 2                 August 2008
1962
1963
1964   application MUST NOT modify the Server response-header.  Instead, it
1965   MUST include a Via field (as described in Section 8.9 of [Part1]).
1966
1967      Note: Revealing the specific software version of the server might
1968      allow the server machine to become more vulnerable to attacks
1969      against software that is known to contain security holes.  Server
1970      implementors are encouraged to make this field a configurable
1971      option.
1972
197310.9.  User-Agent
1974
1975   The User-Agent request-header field contains information about the
1976   user agent originating the request.  This is for statistical
1977   purposes, the tracing of protocol violations, and automated
1978   recognition of user agents for the sake of tailoring responses to
1979   avoid particular user agent limitations.  User agents SHOULD include
1980   this field with requests.  The field can contain multiple product
1981   tokens (Section 3.5 of [Part1]) and comments identifying the agent
1982   and any subproducts which form a significant part of the user agent.
1983   By convention, the product tokens are listed in order of their
1984   significance for identifying the application.
1985
1986     User-Agent     = "User-Agent" ":" 1*( product | comment )
1987
1988   Example:
1989
1990       User-Agent: CERN-LineMode/2.15 libwww/2.17b3
1991
1992
199311.  IANA Considerations
1994
199511.1.  Method Registry
1996
1997   The registration procedure for HTTP Methods is defined by Section 3.1
1998   of this document.
1999
2000   The HTTP Method Registry located at
2001   <http://www.iana.org/assignments/http-methods> should be populated
2002   with the registrations below:
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015Fielding, et al.          Expires March 2, 2009                [Page 36]
2016
2017Internet-Draft              HTTP/1.1, Part 2                 August 2008
2018
2019
2020   +---------+------+-------------+
2021   | Method  | Safe | Reference   |
2022   +---------+------+-------------+
2023   | CONNECT | no   | Section 8.9 |
2024   | DELETE  | no   | Section 8.7 |
2025   | GET     | yes  | Section 8.3 |
2026   | HEAD    | yes  | Section 8.4 |
2027   | OPTIONS | yes  | Section 8.2 |
2028   | POST    | no   | Section 8.5 |
2029   | PUT     | no   | Section 8.6 |
2030   | TRACE   | yes  | Section 8.8 |
2031   +---------+------+-------------+
2032
203311.2.  Status Code Registry
2034
2035   The registration procedure for HTTP Status Codes -- previously
2036   defined in Section 7.1 of [RFC2817] -- is now defined by Section 5.1
2037   of this document.
2038
2039   The HTTP Status Code Registry located at
2040   <http://www.iana.org/assignments/http-status-codes> should be updated
2041   with the registrations below:
2042
2043
2044
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 March 2, 2009                [Page 37]
2072
2073Internet-Draft              HTTP/1.1, Part 2                 August 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 March 2, 2009                [Page 38]
2128
2129Internet-Draft              HTTP/1.1, Part 2                 August 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 March 2, 2009                [Page 39]
2184
2185Internet-Draft              HTTP/1.1, Part 2                 August 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 March 2, 2009                [Page 40]
2240
2241Internet-Draft              HTTP/1.1, Part 2                 August 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-04
2264              (work in progress), August 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-04
2270              (work in progress), August 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-04 (work in
2276              progress), August 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-04 (work
2282              in progress), August 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-04 (work in progress),
2288              August 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 March 2, 2009                [Page 41]
2296
2297Internet-Draft              HTTP/1.1, Part 2                 August 2008
2298
2299
2300              and J. Reschke, Ed., "HTTP/1.1, part 7: Authentication",
2301              draft-ietf-httpbis-p7-auth-04 (work in progress),
2302              August 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   [RFC2822]  Resnick, P., "Internet Message Format", RFC 2822,
2324              April 2001.
2325
2326   [RFC3864]  Klyne, G., Nottingham, M., and J. Mogul, "Registration
2327              Procedures for Message Header Fields", BCP 90, RFC 3864,
2328              September 2004.
2329
2330   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
2331              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
2332              May 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 March 2, 2009                [Page 42]
2352
2353Internet-Draft              HTTP/1.1, Part 2                 August 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 March 2, 2009                [Page 43]
2408
2409Internet-Draft              HTTP/1.1, Part 2                 August 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://www3.tools.ietf.org/wg/httpbis/trac/ticket/5>: "Via is a
2442      MUST" (<http://purl.org/NET/http-errata#via-must>)
2443
2444   o  <http://www3.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://www3.tools.ietf.org/wg/httpbis/trac/ticket/10>: "Safe
2449      Methods vs Redirection"
2450      (<http://purl.org/NET/http-errata#saferedirect>)
2451
2452   o  <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/17>: "Revise
2453      description of the POST method"
2454      (<http://purl.org/NET/http-errata#post>)
2455
2456   o  <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative
2457      and Informative references"
2458
2459
2460
2461
2462
2463Fielding, et al.          Expires March 2, 2009                [Page 44]
2464
2465Internet-Draft              HTTP/1.1, Part 2                 August 2008
2466
2467
2468   o  <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/42>: "RFC2606
2469      Compliance"
2470
2471   o  <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/65>:
2472      "Informative references"
2473
2474   o  <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/84>: "Redundant
2475      cross-references"
2476
2477   Other changes:
2478
2479   o  Move definitions of 304 and 412 condition codes to [Part4]
2480
2481B.3.  Since draft-ietf-httpbis-p2-semantics-01
2482
2483   Closed issues:
2484
2485   o  <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/21>: "PUT side
2486      effects"
2487
2488   o  <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/91>: "Duplicate
2489      Host header requirements"
2490
2491   Ongoing work on ABNF conversion
2492   (<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36>):
2493
2494   o  Move "Product Tokens" section (back) into Part 1, as "token" is
2495      used in the definition of the Upgrade header.
2496
2497   o  Add explicit references to BNF syntax and rules imported from
2498      other parts of the specification.
2499
2500   o  Copy definition of delta-seconds from Part6 instead of referencing
2501      it.
2502
2503B.4.  Since draft-ietf-httpbis-p2-semantics-02
2504
2505   Closed issues:
2506
2507   o  <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/24>: "Requiring
2508      Allow in 405 responses"
2509
2510   o  <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/59>: "Status
2511      Code Registry"
2512
2513   o  <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/61>:
2514      "Redirection vs. Location"
2515
2516
2517
2518
2519Fielding, et al.          Expires March 2, 2009                [Page 45]
2520
2521Internet-Draft              HTTP/1.1, Part 2                 August 2008
2522
2523
2524   o  <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/70>:
2525      "Cacheability of 303 response"
2526
2527   o  <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/76>: "305 Use
2528      Proxy"
2529
2530   o  <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/105>:
2531      "Classification for Allow header"
2532
2533   o  <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/112>: "PUT -
2534      'store under' vs 'store at'"
2535
2536   Ongoing work on IANA Message Header Registration
2537   (<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/40>):
2538
2539   o  Reference RFC 3984, and update header registrations for headers
2540      defined in this document.
2541
2542   Ongoing work on ABNF conversion
2543   (<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36>):
2544
2545   o  Replace string literals when the string really is case-sensitive
2546      (method).
2547
2548B.5.  Since draft-ietf-httpbis-p2-semantics-03
2549
2550   Closed issues:
2551
2552   o  <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/98>: "OPTIONS
2553      request bodies"
2554
2555   o  <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/119>:
2556      "Description of CONNECT should refer to RFC2817"
2557
2558   o  <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/125>: "Location
2559      Content-Location reference request/response mixup"
2560
2561   Ongoing work on Method Registry
2562   (<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/72>):
2563
2564   o  Added initial proposal for registration process, plus initial
2565      content (non-HTTP/1.1 methods to be added by a separate
2566      specification).
2567
2568
2569Index
2570
2571   1
2572
2573
2574
2575Fielding, et al.          Expires March 2, 2009                [Page 46]
2576
2577Internet-Draft              HTTP/1.1, Part 2                 August 2008
2578
2579
2580      100 Continue (status code)  19
2581      101 Switching Protocols (status code)  20
2582
2583   2
2584      200 OK (status code)  20
2585      201 Created (status code)  20
2586      202 Accepted (status code)  21
2587      203 Non-Authoritative Information (status code)  21
2588      204 No Content (status code)  21
2589      205 Reset Content (status code)  22
2590      206 Partial Content (status code)  22
2591
2592   3
2593      300 Multiple Choices (status code)  22
2594      301 Moved Permanently (status code)  23
2595      302 Found (status code)  23
2596      303 See Other (status code)  24
2597      304 Not Modified (status code)  25
2598      305 Use Proxy (status code)  25
2599      306 (Unused) (status code)  25
2600      307 Temporary Redirect (status code)  25
2601
2602   4
2603      400 Bad Request (status code)  26
2604      401 Unauthorized (status code)  26
2605      402 Payment Required (status code)  26
2606      403 Forbidden (status code)  26
2607      404 Not Found (status code)  26
2608      405 Method Not Allowed (status code)  27
2609      406 Not Acceptable (status code)  27
2610      407 Proxy Authentication Required (status code)  27
2611      408 Request Timeout (status code)  27
2612      409 Conflict (status code)  27
2613      410 Gone (status code)  28
2614      411 Length Required (status code)  28
2615      412 Precondition Failed (status code)  28
2616      413 Request Entity Too Large (status code)  29
2617      414 Request-URI Too Long (status code)  29
2618      415 Unsupported Media Type (status code)  29
2619      416 Requested Range Not Satisfiable (status code)  29
2620      417 Expectation Failed (status code)  29
2621
2622   5
2623      500 Internal Server Error (status code)  30
2624      501 Not Implemented (status code)  30
2625      502 Bad Gateway (status code)  30
2626      503 Service Unavailable (status code)  30
2627      504 Gateway Timeout (status code)  30
2628
2629
2630
2631Fielding, et al.          Expires March 2, 2009                [Page 47]
2632
2633Internet-Draft              HTTP/1.1, Part 2                 August 2008
2634
2635
2636      505 HTTP Version Not Supported (status code)  31
2637
2638   A
2639      Allow header  31
2640
2641   C
2642      CONNECT method  19
2643
2644   D
2645      DELETE method  18
2646
2647   E
2648      Expect header  31
2649
2650   F
2651      From header  32
2652
2653   G
2654      GET method  15
2655      Grammar
2656         Allow  31
2657         delta-seconds  35
2658         Expect  32
2659         expect-params  32
2660         expectation  32
2661         expectation-extension  32
2662         extension-code  11
2663         extension-method  8
2664         From  32
2665         Location  33
2666         Max-Forwards  34
2667         Method  8
2668         Reason-Phrase  11
2669         Referer  34
2670         request-header  9
2671         response-header  12
2672         Retry-After  35
2673         Server  35
2674         Status-Code  11
2675         User-Agent  36
2676
2677   H
2678      HEAD method  16
2679      Headers
2680         Allow  31
2681         Expect  31
2682         From  32
2683         Location  33
2684
2685
2686
2687Fielding, et al.          Expires March 2, 2009                [Page 48]
2688
2689Internet-Draft              HTTP/1.1, Part 2                 August 2008
2690
2691
2692         Max-Forwards  34
2693         Referer  34
2694         Retry-After  35
2695         Server  35
2696         User-Agent  36
2697
2698   I
2699      Idempotent Methods  14
2700
2701   L
2702      LINK method  43
2703      Location header  33
2704
2705   M
2706      Max-Forwards header  34
2707      Methods
2708         CONNECT  19
2709         DELETE  18
2710         GET  15
2711         HEAD  16
2712         LINK  43
2713         OPTIONS  14
2714         PATCH  43
2715         POST  16
2716         PUT  17
2717         TRACE  18
2718         UNLINK  43
2719
2720   O
2721      OPTIONS method  14
2722
2723   P
2724      PATCH method  43
2725      POST method  16
2726      PUT method  17
2727
2728   R
2729      Referer header  34
2730      Retry-After header  35
2731
2732   S
2733      Safe Methods  13
2734      Server header  35
2735      Status Codes
2736         100 Continue  19
2737         101 Switching Protocols  20
2738         200 OK  20
2739         201 Created  20
2740
2741
2742
2743Fielding, et al.          Expires March 2, 2009                [Page 49]
2744
2745Internet-Draft              HTTP/1.1, Part 2                 August 2008
2746
2747
2748         202 Accepted  21
2749         203 Non-Authoritative Information  21
2750         204 No Content  21
2751         205 Reset Content  22
2752         206 Partial Content  22
2753         300 Multiple Choices  22
2754         301 Moved Permanently  23
2755         302 Found  23
2756         303 See Other  24
2757         304 Not Modified  25
2758         305 Use Proxy  25
2759         306 (Unused)  25
2760         307 Temporary Redirect  25
2761         400 Bad Request  26
2762         401 Unauthorized  26
2763         402 Payment Required  26
2764         403 Forbidden  26
2765         404 Not Found  26
2766         405 Method Not Allowed  27
2767         406 Not Acceptable  27
2768         407 Proxy Authentication Required  27
2769         408 Request Timeout  27
2770         409 Conflict  27
2771         410 Gone  28
2772         411 Length Required  28
2773         412 Precondition Failed  28
2774         413 Request Entity Too Large  29
2775         414 Request-URI Too Long  29
2776         415 Unsupported Media Type  29
2777         416 Requested Range Not Satisfiable  29
2778         417 Expectation Failed  29
2779         500 Internal Server Error  30
2780         501 Not Implemented  30
2781         502 Bad Gateway  30
2782         503 Service Unavailable  30
2783         504 Gateway Timeout  30
2784         505 HTTP Version Not Supported  31
2785
2786   T
2787      TRACE method  18
2788
2789   U
2790      UNLINK method  43
2791      User-Agent header  36
2792
2793
2794
2795
2796
2797
2798
2799Fielding, et al.          Expires March 2, 2009                [Page 50]
2800
2801Internet-Draft              HTTP/1.1, Part 2                 August 2008
2802
2803
2804Authors' Addresses
2805
2806   Roy T. Fielding (editor)
2807   Day Software
2808   23 Corporate Plaza DR, Suite 280
2809   Newport Beach, CA  92660
2810   USA
2811
2812   Phone: +1-949-706-5300
2813   Fax:   +1-949-706-5305
2814   Email: fielding@gbiv.com
2815   URI:   http://roy.gbiv.com/
2816
2817
2818   Jim Gettys
2819   One Laptop per Child
2820   21 Oak Knoll Road
2821   Carlisle, MA  01741
2822   USA
2823
2824   Email: jg@laptop.org
2825   URI:   http://www.laptop.org/
2826
2827
2828   Jeffrey C. Mogul
2829   Hewlett-Packard Company
2830   HP Labs, Large Scale Systems Group
2831   1501 Page Mill Road, MS 1177
2832   Palo Alto, CA  94304
2833   USA
2834
2835   Email: JeffMogul@acm.org
2836
2837
2838   Henrik Frystyk Nielsen
2839   Microsoft Corporation
2840   1 Microsoft Way
2841   Redmond, WA  98052
2842   USA
2843
2844   Email: henrikn@microsoft.com
2845
2846
2847
2848
2849
2850
2851
2852
2853
2854
2855Fielding, et al.          Expires March 2, 2009                [Page 51]
2856
2857Internet-Draft              HTTP/1.1, Part 2                 August 2008
2858
2859
2860   Larry Masinter
2861   Adobe Systems, Incorporated
2862   345 Park Ave
2863   San Jose, CA  95110
2864   USA
2865
2866   Email: LMM@acm.org
2867   URI:   http://larry.masinter.net/
2868
2869
2870   Paul J. Leach
2871   Microsoft Corporation
2872   1 Microsoft Way
2873   Redmond, WA  98052
2874
2875   Email: paulle@microsoft.com
2876
2877
2878   Tim Berners-Lee
2879   World Wide Web Consortium
2880   MIT Computer Science and Artificial Intelligence Laboratory
2881   The Stata Center, Building 32
2882   32 Vassar Street
2883   Cambridge, MA  02139
2884   USA
2885
2886   Email: timbl@w3.org
2887   URI:   http://www.w3.org/People/Berners-Lee/
2888
2889
2890   Yves Lafon (editor)
2891   World Wide Web Consortium
2892   W3C / ERCIM
2893   2004, rte des Lucioles
2894   Sophia-Antipolis, AM  06902
2895   France
2896
2897   Email: ylafon@w3.org
2898   URI:   http://www.raubacapeu.net/people/yves/
2899
2900
2901
2902
2903
2904
2905
2906
2907
2908
2909
2910
2911Fielding, et al.          Expires March 2, 2009                [Page 52]
2912
2913Internet-Draft              HTTP/1.1, Part 2                 August 2008
2914
2915
2916   Julian F. Reschke (editor)
2917   greenbytes GmbH
2918   Hafenweg 16
2919   Muenster, NW  48155
2920   Germany
2921
2922   Phone: +49 251 2807760
2923   Fax:   +49 251 2807761
2924   Email: julian.reschke@greenbytes.de
2925   URI:   http://greenbytes.de/tech/webdav/
2926
2927
2928
2929
2930
2931
2932
2933
2934
2935
2936
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 March 2, 2009                [Page 53]
2968
2969Internet-Draft              HTTP/1.1, Part 2                 August 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 March 2, 2009                [Page 54]
3024
Note: See TracBrowser for help on using the repository browser.