source: draft-ietf-httpbis/00/draft-ietf-httpbis-p2-semantics-00.txt @ 63

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

Update issues list URI and draft names

  • Property svn:eol-style set to native
File size: 93.2 KB
Line 
1
2
3
4Network Working Group                                   R. Fielding, Ed.
5Internet-Draft                                              Day Software
6Obsoletes: 2068, 2616                                          J. Gettys
7(if approved)                                       One Laptop per Child
8Intended status: Standards Track                                J. Mogul
9Expires: June 22, 2008                                                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                                                       December 20, 2007
19
20
21                  HTTP/1.1, part 2: Message Semantics
22                   draft-ietf-httpbis-p2-semantics-00
23
24Status of this Memo
25
26   By submitting this Internet-Draft, each author represents that any
27   applicable patent or other IPR claims of which he or she is aware
28   have been or will be disclosed, and any of which he or she becomes
29   aware will be disclosed, in accordance with Section 6 of BCP 79.
30
31   Internet-Drafts are working documents of the Internet Engineering
32   Task Force (IETF), its areas, and its working groups.  Note that
33   other groups may also distribute working documents as Internet-
34   Drafts.
35
36   Internet-Drafts are draft documents valid for a maximum of six months
37   and may be updated, replaced, or obsoleted by other documents at any
38   time.  It is inappropriate to use Internet-Drafts as reference
39   material or to cite them other than as "work in progress."
40
41   The list of current Internet-Drafts can be accessed at
42   http://www.ietf.org/ietf/1id-abstracts.txt.
43
44   The list of Internet-Draft Shadow Directories can be accessed at
45   http://www.ietf.org/shadow.html.
46
47   This Internet-Draft will expire on June 22, 2008.
48
49Copyright Notice
50
51   Copyright (C) The IETF Trust (2007).
52
53
54
55Fielding, et al.          Expires June 22, 2008                 [Page 1]
56
57Internet-Draft                  HTTP/1.1                   December 2007
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   This version of the HTTP specification contains only minimal
75   editorial changes from [RFC2616] (abstract, introductory paragraph,
76   and authors' addresses).  All other changes are due to partitioning
77   the original into seven mostly independent parts.  The intent is for
78   readers of future drafts to able to use draft 00 as the basis for
79   comparison when the WG makes later changes to the specification text.
80   This draft will shortly be followed by draft 01 (containing the first
81   round of changes that have already been agreed to on the mailing
82   list).  There is no point in reviewing this draft other than to
83   verify that the partitioning has been done correctly.  Roy T.
84   Fielding, Yves Lafon, and Julian Reschke will be the editors after
85   draft 00 is submitted.
86
87   Discussion of this draft should take place on the HTTPBIS working
88   group mailing list (ietf-http-wg@w3.org).  The current issues list is
89   at <http://www3.tools.ietf.org/wg/httpbis/trac/report/11> and related
90   documents (including fancy diffs) can be found at
91   <http://www3.tools.ietf.org/wg/httpbis/>.
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111Fielding, et al.          Expires June 22, 2008                 [Page 2]
112
113Internet-Draft                  HTTP/1.1                   December 2007
114
115
116Table of Contents
117
118   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
119   2.  Product Tokens . . . . . . . . . . . . . . . . . . . . . . . .  5
120   3.  Method . . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
121   4.  Request Header Fields  . . . . . . . . . . . . . . . . . . . .  6
122   5.  Status Code and Reason Phrase  . . . . . . . . . . . . . . . .  7
123   6.  Response Header Fields . . . . . . . . . . . . . . . . . . . .  9
124   7.  Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
125   8.  Method Definitions . . . . . . . . . . . . . . . . . . . . . . 10
126     8.1.  Safe and Idempotent Methods  . . . . . . . . . . . . . . . 10
127       8.1.1.  Safe Methods . . . . . . . . . . . . . . . . . . . . . 10
128       8.1.2.  Idempotent Methods . . . . . . . . . . . . . . . . . . 10
129     8.2.  OPTIONS  . . . . . . . . . . . . . . . . . . . . . . . . . 11
130     8.3.  GET  . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
131     8.4.  HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
132     8.5.  POST . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
133     8.6.  PUT  . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
134     8.7.  DELETE . . . . . . . . . . . . . . . . . . . . . . . . . . 15
135     8.8.  TRACE  . . . . . . . . . . . . . . . . . . . . . . . . . . 15
136     8.9.  CONNECT  . . . . . . . . . . . . . . . . . . . . . . . . . 16
137   9.  Status Code Definitions  . . . . . . . . . . . . . . . . . . . 16
138     9.1.  Informational 1xx  . . . . . . . . . . . . . . . . . . . . 16
139       9.1.1.  100 Continue . . . . . . . . . . . . . . . . . . . . . 16
140       9.1.2.  101 Switching Protocols  . . . . . . . . . . . . . . . 17
141     9.2.  Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 17
142       9.2.1.  200 OK . . . . . . . . . . . . . . . . . . . . . . . . 17
143       9.2.2.  201 Created  . . . . . . . . . . . . . . . . . . . . . 17
144       9.2.3.  202 Accepted . . . . . . . . . . . . . . . . . . . . . 18
145       9.2.4.  203 Non-Authoritative Information  . . . . . . . . . . 18
146       9.2.5.  204 No Content . . . . . . . . . . . . . . . . . . . . 18
147       9.2.6.  205 Reset Content  . . . . . . . . . . . . . . . . . . 19
148       9.2.7.  206 Partial Content  . . . . . . . . . . . . . . . . . 19
149     9.3.  Redirection 3xx  . . . . . . . . . . . . . . . . . . . . . 19
150       9.3.1.  300 Multiple Choices . . . . . . . . . . . . . . . . . 19
151       9.3.2.  301 Moved Permanently  . . . . . . . . . . . . . . . . 20
152       9.3.3.  302 Found  . . . . . . . . . . . . . . . . . . . . . . 20
153       9.3.4.  303 See Other  . . . . . . . . . . . . . . . . . . . . 21
154       9.3.5.  304 Not Modified . . . . . . . . . . . . . . . . . . . 21
155       9.3.6.  305 Use Proxy  . . . . . . . . . . . . . . . . . . . . 21
156       9.3.7.  306 (Unused) . . . . . . . . . . . . . . . . . . . . . 22
157       9.3.8.  307 Temporary Redirect . . . . . . . . . . . . . . . . 22
158     9.4.  Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 22
159       9.4.1.  400 Bad Request  . . . . . . . . . . . . . . . . . . . 23
160       9.4.2.  401 Unauthorized . . . . . . . . . . . . . . . . . . . 23
161       9.4.3.  402 Payment Required . . . . . . . . . . . . . . . . . 23
162       9.4.4.  403 Forbidden  . . . . . . . . . . . . . . . . . . . . 23
163       9.4.5.  404 Not Found  . . . . . . . . . . . . . . . . . . . . 23
164
165
166
167Fielding, et al.          Expires June 22, 2008                 [Page 3]
168
169Internet-Draft                  HTTP/1.1                   December 2007
170
171
172       9.4.6.  405 Method Not Allowed . . . . . . . . . . . . . . . . 23
173       9.4.7.  406 Not Acceptable . . . . . . . . . . . . . . . . . . 23
174       9.4.8.  407 Proxy Authentication Required  . . . . . . . . . . 24
175       9.4.9.  408 Request Timeout  . . . . . . . . . . . . . . . . . 24
176       9.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 24
177       9.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 25
178       9.4.12. 411 Length Required  . . . . . . . . . . . . . . . . . 25
179       9.4.13. 412 Precondition Failed  . . . . . . . . . . . . . . . 25
180       9.4.14. 413 Request Entity Too Large . . . . . . . . . . . . . 25
181       9.4.15. 414 Request-URI Too Long . . . . . . . . . . . . . . . 26
182       9.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . . 26
183       9.4.17. 416 Requested Range Not Satisfiable  . . . . . . . . . 26
184       9.4.18. 417 Expectation Failed . . . . . . . . . . . . . . . . 26
185     9.5.  Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 26
186       9.5.1.  500 Internal Server Error  . . . . . . . . . . . . . . 26
187       9.5.2.  501 Not Implemented  . . . . . . . . . . . . . . . . . 27
188       9.5.3.  502 Bad Gateway  . . . . . . . . . . . . . . . . . . . 27
189       9.5.4.  503 Service Unavailable  . . . . . . . . . . . . . . . 27
190       9.5.5.  504 Gateway Timeout  . . . . . . . . . . . . . . . . . 27
191       9.5.6.  505 HTTP Version Not Supported . . . . . . . . . . . . 27
192   10. Header Field Definitions . . . . . . . . . . . . . . . . . . . 28
193     10.1. Allow  . . . . . . . . . . . . . . . . . . . . . . . . . . 28
194     10.2. Expect . . . . . . . . . . . . . . . . . . . . . . . . . . 28
195     10.3. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
196     10.4. Location . . . . . . . . . . . . . . . . . . . . . . . . . 30
197     10.5. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . . 30
198     10.6. Referer  . . . . . . . . . . . . . . . . . . . . . . . . . 31
199     10.7. Retry-After  . . . . . . . . . . . . . . . . . . . . . . . 31
200     10.8. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 32
201     10.9. User-Agent . . . . . . . . . . . . . . . . . . . . . . . . 32
202   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 33
203   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 33
204     12.1. Transfer of Sensitive Information  . . . . . . . . . . . . 33
205     12.2. Encoding Sensitive Information in URI's  . . . . . . . . . 34
206     12.3. Location Headers and Spoofing  . . . . . . . . . . . . . . 34
207   13. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 34
208   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
209   Appendix A.  Changes from RFC 2068 . . . . . . . . . . . . . . . . 36
210   Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
211   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40
212   Intellectual Property and Copyright Statements . . . . . . . . . . 43
213
214
215
216
217
218
219
220
221
222
223Fielding, et al.          Expires June 22, 2008                 [Page 4]
224
225Internet-Draft                  HTTP/1.1                   December 2007
226
227
2281.  Introduction
229
230   This document will define aspects of HTTP related to request and
231   response semantics.  Right now it only includes the extracted
232   relevant sections of RFC 2616 with only minor edits.
233
234   The HTTP protocol is a request/response protocol.  A client sends a
235   request to the server in the form of a request method, URI, and
236   protocol version, followed by a MIME-like message containing request
237   modifiers, client information, and possible body content over a
238   connection with a server.  The server responds with a status line,
239   including the message's protocol version and a success or error code,
240   followed by a MIME-like message containing server information, entity
241   metainformation, and possible entity-body content.  The relationship
242   between HTTP and MIME is described in Appendix A of [Part3].
243
244
2452.  Product Tokens
246
247   Product tokens are used to allow communicating applications to
248   identify themselves by software name and version.  Most fields using
249   product tokens also allow sub-products which form a significant part
250   of the application to be listed, separated by white space.  By
251   convention, the products are listed in order of their significance
252   for identifying the application.
253
254       product         = token ["/" product-version]
255       product-version = token
256
257   Examples:
258
259       User-Agent: CERN-LineMode/2.15 libwww/2.17b3
260       Server: Apache/0.8.4
261
262   Product tokens SHOULD be short and to the point.  They MUST NOT be
263   used for advertising or other non-essential information.  Although
264   any token character MAY appear in a product-version, this token
265   SHOULD only be used for a version identifier (i.e., successive
266   versions of the same product SHOULD only differ in the product-
267   version portion of the product value).
268
269
2703.  Method
271
272   The Method token indicates the method to be performed on the resource
273   identified by the Request-URI.  The method is case-sensitive.
274
275
276
277
278
279Fielding, et al.          Expires June 22, 2008                 [Page 5]
280
281Internet-Draft                  HTTP/1.1                   December 2007
282
283
284       Method         = "OPTIONS"                ; Section 8.2
285                      | "GET"                    ; Section 8.3
286                      | "HEAD"                   ; Section 8.4
287                      | "POST"                   ; Section 8.5
288                      | "PUT"                    ; Section 8.6
289                      | "DELETE"                 ; Section 8.7
290                      | "TRACE"                  ; Section 8.8
291                      | "CONNECT"                ; Section 8.9
292                      | extension-method
293       extension-method = token
294
295   The list of methods allowed by a resource can be specified in an
296   Allow header field (Section 10.1).  The return code of the response
297   always notifies the client whether a method is currently allowed on a
298   resource, since the set of allowed methods can change dynamically.
299   An origin server SHOULD return the status code 405 (Method Not
300   Allowed) if the method is known by the origin server but not allowed
301   for the requested resource, and 501 (Not Implemented) if the method
302   is unrecognized or not implemented by the origin server.  The methods
303   GET and HEAD MUST be supported by all general-purpose servers.  All
304   other methods are OPTIONAL; however, if the above methods are
305   implemented, they MUST be implemented with the same semantics as
306   those specified in Section 8.
307
308
3094.  Request Header Fields
310
311   The request-header fields allow the client to pass additional
312   information about the request, and about the client itself, to the
313   server.  These fields act as request modifiers, with semantics
314   equivalent to the parameters on a programming language method
315   invocation.
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335Fielding, et al.          Expires June 22, 2008                 [Page 6]
336
337Internet-Draft                  HTTP/1.1                   December 2007
338
339
340       request-header = Accept                   ; [Part3], Section 5.1
341                      | Accept-Charset           ; [Part3], Section 5.2
342                      | Accept-Encoding          ; [Part3], Section 5.3
343                      | Accept-Language          ; [Part3], Section 5.4
344                      | Authorization            ; [Part7], Section 3.1
345                      | Expect                   ; Section 10.2
346                      | From                     ; Section 10.3
347                      | Host                     ; [Part1], Section 8.4
348                      | If-Match                 ; [Part4], Section 6.2
349                      | If-Modified-Since        ; [Part4], Section 6.3
350                      | If-None-Match            ; [Part4], Section 6.4
351                      | If-Range                 ; [Part5], Section 5.3
352                      | If-Unmodified-Since      ; [Part4], Section 6.5
353                      | Max-Forwards             ; Section 10.5
354                      | Proxy-Authorization      ; [Part7], Section 3.3
355                      | Range                    ; [Part5], Section 5.4
356                      | Referer                  ; Section 10.6
357                      | TE                       ; [Part1], Section 8.8
358                      | User-Agent               ; Section 10.9
359
360   Request-header field names can be extended reliably only in
361   combination with a change in the protocol version.  However, new or
362   experimental header fields MAY be given the semantics of request-
363   header fields if all parties in the communication recognize them to
364   be request-header fields.  Unrecognized header fields are treated as
365   entity-header fields.
366
367
3685.  Status Code and Reason Phrase
369
370   The Status-Code element is a 3-digit integer result code of the
371   attempt to understand and satisfy the request.  These codes are fully
372   defined in Section 9.  The Reason-Phrase is intended to give a short
373   textual description of the Status-Code.  The Status-Code is intended
374   for use by automata and the Reason-Phrase is intended for the human
375   user.  The client is not required to examine or display the Reason-
376   Phrase.
377
378   The individual values of the numeric status codes defined for
379   HTTP/1.1, and an example set of corresponding Reason-Phrase's, are
380   presented below.  The reason phrases listed here are only
381   recommendations -- they MAY be replaced by local equivalents without
382   affecting the protocol.
383
384
385
386
387
388
389
390
391Fielding, et al.          Expires June 22, 2008                 [Page 7]
392
393Internet-Draft                  HTTP/1.1                   December 2007
394
395
396      Status-Code    =
397            "100"  ; Section 9.1.1: Continue
398          | "101"  ; Section 9.1.2: Switching Protocols
399          | "200"  ; Section 9.2.1: OK
400          | "201"  ; Section 9.2.2: Created
401          | "202"  ; Section 9.2.3: Accepted
402          | "203"  ; Section 9.2.4: Non-Authoritative Information
403          | "204"  ; Section 9.2.5: No Content
404          | "205"  ; Section 9.2.6: Reset Content
405          | "206"  ; Section 9.2.7: Partial Content
406          | "300"  ; Section 9.3.1: Multiple Choices
407          | "301"  ; Section 9.3.2: Moved Permanently
408          | "302"  ; Section 9.3.3: Found
409          | "303"  ; Section 9.3.4: See Other
410          | "304"  ; Section 9.3.5: Not Modified
411          | "305"  ; Section 9.3.6: Use Proxy
412          | "307"  ; Section 9.3.8: Temporary Redirect
413          | "400"  ; Section 9.4.1: Bad Request
414          | "401"  ; Section 9.4.2: Unauthorized
415          | "402"  ; Section 9.4.3: Payment Required
416          | "403"  ; Section 9.4.4: Forbidden
417          | "404"  ; Section 9.4.5: Not Found
418          | "405"  ; Section 9.4.6: Method Not Allowed
419          | "406"  ; Section 9.4.7: Not Acceptable
420          | "407"  ; Section 9.4.8: Proxy Authentication Required
421          | "408"  ; Section 9.4.9: Request Time-out
422          | "409"  ; Section 9.4.10: Conflict
423          | "410"  ; Section 9.4.11: Gone
424          | "411"  ; Section 9.4.12: Length Required
425          | "412"  ; Section 9.4.13: Precondition Failed
426          | "413"  ; Section 9.4.14: Request Entity Too Large
427          | "414"  ; Section 9.4.15: Request-URI Too Large
428          | "415"  ; Section 9.4.16: Unsupported Media Type
429          | "416"  ; Section 9.4.17: Requested range not satisfiable
430          | "417"  ; Section 9.4.18: Expectation Failed
431          | "500"  ; Section 9.5.1: Internal Server Error
432          | "501"  ; Section 9.5.2: Not Implemented
433          | "502"  ; Section 9.5.3: Bad Gateway
434          | "503"  ; Section 9.5.4: Service Unavailable
435          | "504"  ; Section 9.5.5: Gateway Time-out
436          | "505"  ; Section 9.5.6: HTTP Version not supported
437          | extension-code
438
439      extension-code = 3DIGIT
440      Reason-Phrase  = *<TEXT, excluding CR, LF>
441
442   HTTP status codes are extensible.  HTTP applications are not required
443   to understand the meaning of all registered status codes, though such
444
445
446
447Fielding, et al.          Expires June 22, 2008                 [Page 8]
448
449Internet-Draft                  HTTP/1.1                   December 2007
450
451
452   understanding is obviously desirable.  However, applications MUST
453   understand the class of any status code, as indicated by the first
454   digit, and treat any unrecognized response as being equivalent to the
455   x00 status code of that class, with the exception that an
456   unrecognized response MUST NOT be cached.  For example, if an
457   unrecognized status code of 431 is received by the client, it can
458   safely assume that there was something wrong with its request and
459   treat the response as if it had received a 400 status code.  In such
460   cases, user agents SHOULD present to the user the entity returned
461   with the response, since that entity is likely to include human-
462   readable information which will explain the unusual status.
463
464
4656.  Response Header Fields
466
467   The response-header fields allow the server to pass additional
468   information about the response which cannot be placed in the Status-
469   Line.  These header fields give information about the server and
470   about further access to the resource identified by the Request-URI.
471
472       response-header = Accept-Ranges           ; [Part5], Section 5.1
473                       | Age                     ; [Part6], Section 3.1
474                       | ETag                    ; [Part4], Section 6.1
475                       | Location                ; Section 10.4
476                       | Proxy-Authenticate      ; [Part7], Section 3.2
477                       | Retry-After             ; Section 10.7
478                       | Server                  ; Section 10.8
479                       | Vary                    ; [Part6], Section 3.5
480                       | WWW-Authenticate        ; [Part7], Section 3.4
481
482   Response-header field names can be extended reliably only in
483   combination with a change in the protocol version.  However, new or
484   experimental header fields MAY be given the semantics of response-
485   header fields if all parties in the communication recognize them to
486   be response-header fields.  Unrecognized header fields are treated as
487   entity-header fields.
488
489
4907.  Entity
491
492   Request and Response messages MAY transfer an entity if not otherwise
493   restricted by the request method or response status code.  An entity
494   consists of entity-header fields and an entity-body, although some
495   responses will only include the entity-headers.  HTTP entity-body and
496   entity-header fields are defined in [Part3].
497
498   An entity-body is only present in a message when a message-body is
499   present, as described in Section 4.3 of [Part1].  The entity-body is
500
501
502
503Fielding, et al.          Expires June 22, 2008                 [Page 9]
504
505Internet-Draft                  HTTP/1.1                   December 2007
506
507
508   obtained from the message-body by decoding any Transfer-Encoding that
509   might have been applied to ensure safe and proper transfer of the
510   message.
511
512
5138.  Method Definitions
514
515   The set of common methods for HTTP/1.1 is defined below.  Although
516   this set can be expanded, additional methods cannot be assumed to
517   share the same semantics for separately extended clients and servers.
518   The Host request-header field (Section 8.4 of [Part1]) MUST accompany
519   all HTTP/1.1 requests.
520
5218.1.  Safe and Idempotent Methods
522
5238.1.1.  Safe Methods
524
525   Implementors should be aware that the software represents the user in
526   their interactions over the Internet, and should be careful to allow
527   the user to be aware of any actions they might take which may have an
528   unexpected significance to themselves or others.
529
530   In particular, the convention has been established that the GET and
531   HEAD methods SHOULD NOT have the significance of taking an action
532   other than retrieval.  These methods ought to be considered "safe".
533   This allows user agents to represent other methods, such as POST, PUT
534   and DELETE, in a special way, so that the user is made aware of the
535   fact that a possibly unsafe action is being requested.
536
537   Naturally, it is not possible to ensure that the server does not
538   generate side-effects as a result of performing a GET request; in
539   fact, some dynamic resources consider that a feature.  The important
540   distinction here is that the user did not request the side-effects,
541   so therefore cannot be held accountable for them.
542
5438.1.2.  Idempotent Methods
544
545   Methods can also have the property of "idempotence" in that (aside
546   from error or expiration issues) the side-effects of N > 0 identical
547   requests is the same as for a single request.  The methods GET, HEAD,
548   PUT and DELETE share this property.  Also, the methods OPTIONS and
549   TRACE SHOULD NOT have side effects, and so are inherently idempotent.
550
551   However, it is possible that a sequence of several requests is non-
552   idempotent, even if all of the methods executed in that sequence are
553   idempotent.  (A sequence is idempotent if a single execution of the
554   entire sequence always yields a result that is not changed by a
555   reexecution of all, or part, of that sequence.)  For example, a
556
557
558
559Fielding, et al.          Expires June 22, 2008                [Page 10]
560
561Internet-Draft                  HTTP/1.1                   December 2007
562
563
564   sequence is non-idempotent if its result depends on a value that is
565   later modified in the same sequence.
566
567   A sequence that never has side effects is idempotent, by definition
568   (provided that no concurrent operations are being executed on the
569   same set of resources).
570
5718.2.  OPTIONS
572
573   The OPTIONS method represents a request for information about the
574   communication options available on the request/response chain
575   identified by the Request-URI.  This method allows the client to
576   determine the options and/or requirements associated with a resource,
577   or the capabilities of a server, without implying a resource action
578   or initiating a resource retrieval.
579
580   Responses to this method are not cacheable.
581
582   If the OPTIONS request includes an entity-body (as indicated by the
583   presence of Content-Length or Transfer-Encoding), then the media type
584   MUST be indicated by a Content-Type field.  Although this
585   specification does not define any use for such a body, future
586   extensions to HTTP might use the OPTIONS body to make more detailed
587   queries on the server.  A server that does not support such an
588   extension MAY discard the request body.
589
590   If the Request-URI is an asterisk ("*"), the OPTIONS request is
591   intended to apply to the server in general rather than to a specific
592   resource.  Since a server's communication options typically depend on
593   the resource, the "*" request is only useful as a "ping" or "no-op"
594   type of method; it does nothing beyond allowing the client to test
595   the capabilities of the server.  For example, this can be used to
596   test a proxy for HTTP/1.1 compliance (or lack thereof).
597
598   If the Request-URI is not an asterisk, the OPTIONS request applies
599   only to the options that are available when communicating with that
600   resource.
601
602   A 200 response SHOULD include any header fields that indicate
603   optional features implemented by the server and applicable to that
604   resource (e.g., Allow), possibly including extensions not defined by
605   this specification.  The response body, if any, SHOULD also include
606   information about the communication options.  The format for such a
607   body is not defined by this specification, but might be defined by
608   future extensions to HTTP.  Content negotiation MAY be used to select
609   the appropriate response format.  If no response body is included,
610   the response MUST include a Content-Length field with a field-value
611   of "0".
612
613
614
615Fielding, et al.          Expires June 22, 2008                [Page 11]
616
617Internet-Draft                  HTTP/1.1                   December 2007
618
619
620   The Max-Forwards request-header field MAY be used to target a
621   specific proxy in the request chain.  When a proxy receives an
622   OPTIONS request on an absoluteURI for which request forwarding is
623   permitted, the proxy MUST check for a Max-Forwards field.  If the
624   Max-Forwards field-value is zero ("0"), the proxy MUST NOT forward
625   the message; instead, the proxy SHOULD respond with its own
626   communication options.  If the Max-Forwards field-value is an integer
627   greater than zero, the proxy MUST decrement the field-value when it
628   forwards the request.  If no Max-Forwards field is present in the
629   request, then the forwarded request MUST NOT include a Max-Forwards
630   field.
631
6328.3.  GET
633
634   The GET method means retrieve whatever information (in the form of an
635   entity) is identified by the Request-URI.  If the Request-URI refers
636   to a data-producing process, it is the produced data which shall be
637   returned as the entity in the response and not the source text of the
638   process, unless that text happens to be the output of the process.
639
640   The semantics of the GET method change to a "conditional GET" if the
641   request message includes an If-Modified-Since, If-Unmodified-Since,
642   If-Match, If-None-Match, or If-Range header field.  A conditional GET
643   method requests that the entity be transferred only under the
644   circumstances described by the conditional header field(s).  The
645   conditional GET method is intended to reduce unnecessary network
646   usage by allowing cached entities to be refreshed without requiring
647   multiple requests or transferring data already held by the client.
648
649   The semantics of the GET method change to a "partial GET" if the
650   request message includes a Range header field.  A partial GET
651   requests that only part of the entity be transferred, as described in
652   Section 5.4 of [Part5].  The partial GET method is intended to reduce
653   unnecessary network usage by allowing partially-retrieved entities to
654   be completed without transferring data already held by the client.
655
656   The response to a GET request is cacheable if and only if it meets
657   the requirements for HTTP caching described in [Part6].
658
659   See Section 12.2 for security considerations when used for forms.
660
6618.4.  HEAD
662
663   The HEAD method is identical to GET except that the server MUST NOT
664   return a message-body in the response.  The metainformation contained
665   in the HTTP headers in response to a HEAD request SHOULD be identical
666   to the information sent in response to a GET request.  This method
667   can be used for obtaining metainformation about the entity implied by
668
669
670
671Fielding, et al.          Expires June 22, 2008                [Page 12]
672
673Internet-Draft                  HTTP/1.1                   December 2007
674
675
676   the request without transferring the entity-body itself.  This method
677   is often used for testing hypertext links for validity,
678   accessibility, and recent modification.
679
680   The response to a HEAD request MAY be cacheable in the sense that the
681   information contained in the response MAY be used to update a
682   previously cached entity from that resource.  If the new field values
683   indicate that the cached entity differs from the current entity (as
684   would be indicated by a change in Content-Length, Content-MD5, ETag
685   or Last-Modified), then the cache MUST treat the cache entry as
686   stale.
687
6888.5.  POST
689
690   The POST method is used to request that the origin server accept the
691   entity enclosed in the request as a new subordinate of the resource
692   identified by the Request-URI in the Request-Line.  POST is designed
693   to allow a uniform method to cover the following functions:
694
695   o  Annotation of existing resources;
696
697   o  Posting a message to a bulletin board, newsgroup, mailing list, or
698      similar group of articles;
699
700   o  Providing a block of data, such as the result of submitting a
701      form, to a data-handling process;
702
703   o  Extending a database through an append operation.
704
705   The actual function performed by the POST method is determined by the
706   server and is usually dependent on the Request-URI.  The posted
707   entity is subordinate to that URI in the same way that a file is
708   subordinate to a directory containing it, a news article is
709   subordinate to a newsgroup to which it is posted, or a record is
710   subordinate to a database.
711
712   The action performed by the POST method might not result in a
713   resource that can be identified by a URI.  In this case, either 200
714   (OK) or 204 (No Content) is the appropriate response status,
715   depending on whether or not the response includes an entity that
716   describes the result.
717
718   If a resource has been created on the origin server, the response
719   SHOULD be 201 (Created) and contain an entity which describes the
720   status of the request and refers to the new resource, and a Location
721   header (see Section 10.4).
722
723   Responses to this method are not cacheable, unless the response
724
725
726
727Fielding, et al.          Expires June 22, 2008                [Page 13]
728
729Internet-Draft                  HTTP/1.1                   December 2007
730
731
732   includes appropriate Cache-Control or Expires header fields.
733   However, the 303 (See Other) response can be used to direct the user
734   agent to retrieve a cacheable resource.
735
736   POST requests MUST obey the message transmission requirements set out
737   in Section 7.2 of [Part1].
738
739   See Section 12.2 for security considerations.
740
7418.6.  PUT
742
743   The PUT method requests that the enclosed entity be stored under the
744   supplied Request-URI.  If the Request-URI refers to an already
745   existing resource, the enclosed entity SHOULD be considered as a
746   modified version of the one residing on the origin server.  If the
747   Request-URI does not point to an existing resource, and that URI is
748   capable of being defined as a new resource by the requesting user
749   agent, the origin server can create the resource with that URI.  If a
750   new resource is created, the origin server MUST inform the user agent
751   via the 201 (Created) response.  If an existing resource is modified,
752   either the 200 (OK) or 204 (No Content) response codes SHOULD be sent
753   to indicate successful completion of the request.  If the resource
754   could not be created or modified with the Request-URI, an appropriate
755   error response SHOULD be given that reflects the nature of the
756   problem.  The recipient of the entity MUST NOT ignore any Content-*
757   (e.g.  Content-Range) headers that it does not understand or
758   implement and MUST return a 501 (Not Implemented) response in such
759   cases.
760
761   If the request passes through a cache and the Request-URI identifies
762   one or more currently cached entities, those entries SHOULD be
763   treated as stale.  Responses to this method are not cacheable.
764
765   The fundamental difference between the POST and PUT requests is
766   reflected in the different meaning of the Request-URI.  The URI in a
767   POST request identifies the resource that will handle the enclosed
768   entity.  That resource might be a data-accepting process, a gateway
769   to some other protocol, or a separate entity that accepts
770   annotations.  In contrast, the URI in a PUT request identifies the
771   entity enclosed with the request -- the user agent knows what URI is
772   intended and the server MUST NOT attempt to apply the request to some
773   other resource.  If the server desires that the request be applied to
774   a different URI, it MUST send a 301 (Moved Permanently) response; the
775   user agent MAY then make its own decision regarding whether or not to
776   redirect the request.
777
778   A single resource MAY be identified by many different URIs.  For
779   example, an article might have a URI for identifying "the current
780
781
782
783Fielding, et al.          Expires June 22, 2008                [Page 14]
784
785Internet-Draft                  HTTP/1.1                   December 2007
786
787
788   version" which is separate from the URI identifying each particular
789   version.  In this case, a PUT request on a general URI might result
790   in several other URIs being defined by the origin server.
791
792   HTTP/1.1 does not define how a PUT method affects the state of an
793   origin server.
794
795   PUT requests MUST obey the message transmission requirements set out
796   in Section 7.2 of [Part1].
797
798   Unless otherwise specified for a particular entity-header, the
799   entity-headers in the PUT request SHOULD be applied to the resource
800   created or modified by the PUT.
801
8028.7.  DELETE
803
804   The DELETE method requests that the origin server delete the resource
805   identified by the Request-URI.  This method MAY be overridden by
806   human intervention (or other means) on the origin server.  The client
807   cannot be guaranteed that the operation has been carried out, even if
808   the status code returned from the origin server indicates that the
809   action has been completed successfully.  However, the server SHOULD
810   NOT indicate success unless, at the time the response is given, it
811   intends to delete the resource or move it to an inaccessible
812   location.
813
814   A successful response SHOULD be 200 (OK) if the response includes an
815   entity describing the status, 202 (Accepted) if the action has not
816   yet been enacted, or 204 (No Content) if the action has been enacted
817   but the response does not include an entity.
818
819   If the request passes through a cache and the Request-URI identifies
820   one or more currently cached entities, those entries SHOULD be
821   treated as stale.  Responses to this method are not cacheable.
822
8238.8.  TRACE
824
825   The TRACE method is used to invoke a remote, application-layer loop-
826   back of the request message.  The final recipient of the request
827   SHOULD reflect the message received back to the client as the entity-
828   body of a 200 (OK) response.  The final recipient is either the
829   origin server or the first proxy or gateway to receive a Max-Forwards
830   value of zero (0) in the request (see Section 10.5).  A TRACE request
831   MUST NOT include an entity.
832
833   TRACE allows the client to see what is being received at the other
834   end of the request chain and use that data for testing or diagnostic
835   information.  The value of the Via header field (Section 8.9 of
836
837
838
839Fielding, et al.          Expires June 22, 2008                [Page 15]
840
841Internet-Draft                  HTTP/1.1                   December 2007
842
843
844   [Part1]) is of particular interest, since it acts as a trace of the
845   request chain.  Use of the Max-Forwards header field allows the
846   client to limit the length of the request chain, which is useful for
847   testing a chain of proxies forwarding messages in an infinite loop.
848
849   If the request is valid, the response SHOULD contain the entire
850   request message in the entity-body, with a Content-Type of "message/
851   http".  Responses to this method MUST NOT be cached.
852
8538.9.  CONNECT
854
855   This specification reserves the method name CONNECT for use with a
856   proxy that can dynamically switch to being a tunnel (e.g.  SSL
857   tunneling [Luo1998]).
858
859
8609.  Status Code Definitions
861
862   Each Status-Code is described below, including a description of which
863   method(s) it can follow and any metainformation required in the
864   response.
865
8669.1.  Informational 1xx
867
868   This class of status code indicates a provisional response,
869   consisting only of the Status-Line and optional headers, and is
870   terminated by an empty line.  There are no required headers for this
871   class of status code.  Since HTTP/1.0 did not define any 1xx status
872   codes, servers MUST NOT send a 1xx response to an HTTP/1.0 client
873   except under experimental conditions.
874
875   A client MUST be prepared to accept one or more 1xx status responses
876   prior to a regular response, even if the client does not expect a 100
877   (Continue) status message.  Unexpected 1xx status responses MAY be
878   ignored by a user agent.
879
880   Proxies MUST forward 1xx responses, unless the connection between the
881   proxy and its client has been closed, or unless the proxy itself
882   requested the generation of the 1xx response.  (For example, if a
883   proxy adds a "Expect: 100-continue" field when it forwards a request,
884   then it need not forward the corresponding 100 (Continue)
885   response(s).)
886
8879.1.1.  100 Continue
888
889   The client SHOULD continue with its request.  This interim response
890   is used to inform the client that the initial part of the request has
891   been received and has not yet been rejected by the server.  The
892
893
894
895Fielding, et al.          Expires June 22, 2008                [Page 16]
896
897Internet-Draft                  HTTP/1.1                   December 2007
898
899
900   client SHOULD continue by sending the remainder of the request or, if
901   the request has already been completed, ignore this response.  The
902   server MUST send a final response after the request has been
903   completed.  See Section 7.2.3 of [Part1] for detailed discussion of
904   the use and handling of this status code.
905
9069.1.2.  101 Switching Protocols
907
908   The server understands and is willing to comply with the client's
909   request, via the Upgrade message header field (Section 5.4 of
910   [Part5]), for a change in the application protocol being used on this
911   connection.  The server will switch protocols to those defined by the
912   response's Upgrade header field immediately after the empty line
913   which terminates the 101 response.
914
915   The protocol SHOULD be switched only when it is advantageous to do
916   so.  For example, switching to a newer version of HTTP is
917   advantageous over older versions, and switching to a real-time,
918   synchronous protocol might be advantageous when delivering resources
919   that use such features.
920
9219.2.  Successful 2xx
922
923   This class of status code indicates that the client's request was
924   successfully received, understood, and accepted.
925
9269.2.1.  200 OK
927
928   The request has succeeded.  The information returned with the
929   response is dependent on the method used in the request, for example:
930
931   GET  an entity corresponding to the requested resource is sent in the
932      response;
933
934   HEAD  the entity-header fields corresponding to the requested
935      resource are sent in the response without any message-body;
936
937   POST  an entity describing or containing the result of the action;
938
939   TRACE  an entity containing the request message as received by the
940      end server.
941
9429.2.2.  201 Created
943
944   The request has been fulfilled and resulted in a new resource being
945   created.  The newly created resource can be referenced by the URI(s)
946   returned in the entity of the response, with the most specific URI
947   for the resource given by a Location header field.  The response
948
949
950
951Fielding, et al.          Expires June 22, 2008                [Page 17]
952
953Internet-Draft                  HTTP/1.1                   December 2007
954
955
956   SHOULD include an entity containing a list of resource
957   characteristics and location(s) from which the user or user agent can
958   choose the one most appropriate.  The entity format is specified by
959   the media type given in the Content-Type header field.  The origin
960   server MUST create the resource before returning the 201 status code.
961   If the action cannot be carried out immediately, the server SHOULD
962   respond with 202 (Accepted) response instead.
963
964   A 201 response MAY contain an ETag response header field indicating
965   the current value of the entity tag for the requested variant just
966   created, see Section 6.1 of [Part4].
967
9689.2.3.  202 Accepted
969
970   The request has been accepted for processing, but the processing has
971   not been completed.  The request might or might not eventually be
972   acted upon, as it might be disallowed when processing actually takes
973   place.  There is no facility for re-sending a status code from an
974   asynchronous operation such as this.
975
976   The 202 response is intentionally non-committal.  Its purpose is to
977   allow a server to accept a request for some other process (perhaps a
978   batch-oriented process that is only run once per day) without
979   requiring that the user agent's connection to the server persist
980   until the process is completed.  The entity returned with this
981   response SHOULD include an indication of the request's current status
982   and either a pointer to a status monitor or some estimate of when the
983   user can expect the request to be fulfilled.
984
9859.2.4.  203 Non-Authoritative Information
986
987   The returned metainformation in the entity-header is not the
988   definitive set as available from the origin server, but is gathered
989   from a local or a third-party copy.  The set presented MAY be a
990   subset or superset of the original version.  For example, including
991   local annotation information about the resource might result in a
992   superset of the metainformation known by the origin server.  Use of
993   this response code is not required and is only appropriate when the
994   response would otherwise be 200 (OK).
995
9969.2.5.  204 No Content
997
998   The server has fulfilled the request but does not need to return an
999   entity-body, and might want to return updated metainformation.  The
1000   response MAY include new or updated metainformation in the form of
1001   entity-headers, which if present SHOULD be associated with the
1002   requested variant.
1003
1004
1005
1006
1007Fielding, et al.          Expires June 22, 2008                [Page 18]
1008
1009Internet-Draft                  HTTP/1.1                   December 2007
1010
1011
1012   If the client is a user agent, it SHOULD NOT change its document view
1013   from that which caused the request to be sent.  This response is
1014   primarily intended to allow input for actions to take place without
1015   causing a change to the user agent's active document view, although
1016   any new or updated metainformation SHOULD be applied to the document
1017   currently in the user agent's active view.
1018
1019   The 204 response MUST NOT include a message-body, and thus is always
1020   terminated by the first empty line after the header fields.
1021
10229.2.6.  205 Reset Content
1023
1024   The server has fulfilled the request and the user agent SHOULD reset
1025   the document view which caused the request to be sent.  This response
1026   is primarily intended to allow input for actions to take place via
1027   user input, followed by a clearing of the form in which the input is
1028   given so that the user can easily initiate another input action.  The
1029   response MUST NOT include an entity.
1030
10319.2.7.  206 Partial Content
1032
1033   The server has fulfilled the partial GET request for the resource and
1034   the enclosed entity is a partial representation as defined in
1035   [Part5].
1036
10379.3.  Redirection 3xx
1038
1039   This class of status code indicates that further action needs to be
1040   taken by the user agent in order to fulfill the request.  The action
1041   required MAY be carried out by the user agent without interaction
1042   with the user if and only if the method used in the second request is
1043   GET or HEAD.  A client SHOULD detect infinite redirection loops,
1044   since such loops generate network traffic for each redirection.
1045
1046      Note: previous versions of this specification recommended a
1047      maximum of five redirections.  Content developers should be aware
1048      that there might be clients that implement such a fixed
1049      limitation.
1050
10519.3.1.  300 Multiple Choices
1052
1053   The requested resource corresponds to any one of a set of
1054   representations, each with its own specific location, and agent-
1055   driven negotiation information (Section 4 of [Part3]) is being
1056   provided so that the user (or user agent) can select a preferred
1057   representation and redirect its request to that location.
1058
1059   Unless it was a HEAD request, the response SHOULD include an entity
1060
1061
1062
1063Fielding, et al.          Expires June 22, 2008                [Page 19]
1064
1065Internet-Draft                  HTTP/1.1                   December 2007
1066
1067
1068   containing a list of resource characteristics and location(s) from
1069   which the user or user agent can choose the one most appropriate.
1070   The entity format is specified by the media type given in the
1071   Content-Type header field.  Depending upon the format and the
1072   capabilities of the user agent, selection of the most appropriate
1073   choice MAY be performed automatically.  However, this specification
1074   does not define any standard for such automatic selection.
1075
1076   If the server has a preferred choice of representation, it SHOULD
1077   include the specific URI for that representation in the Location
1078   field; user agents MAY use the Location field value for automatic
1079   redirection.  This response is cacheable unless indicated otherwise.
1080
10819.3.2.  301 Moved Permanently
1082
1083   The requested resource has been assigned a new permanent URI and any
1084   future references to this resource SHOULD use one of the returned
1085   URIs.  Clients with link editing capabilities ought to automatically
1086   re-link references to the Request-URI to one or more of the new
1087   references returned by the server, where possible.  This response is
1088   cacheable unless indicated otherwise.
1089
1090   The new permanent URI SHOULD be given by the Location field in the
1091   response.  Unless the request method was HEAD, the entity of the
1092   response SHOULD contain a short hypertext note with a hyperlink to
1093   the new URI(s).
1094
1095   If the 301 status code is received in response to a request other
1096   than GET or HEAD, the user agent MUST NOT automatically redirect the
1097   request unless it can be confirmed by the user, since this might
1098   change the conditions under which the request was issued.
1099
1100      Note: When automatically redirecting a POST request after
1101      receiving a 301 status code, some existing HTTP/1.0 user agents
1102      will erroneously change it into a GET request.
1103
11049.3.3.  302 Found
1105
1106   The requested resource resides temporarily under a different URI.
1107   Since the redirection might be altered on occasion, the client SHOULD
1108   continue to use the Request-URI for future requests.  This response
1109   is only cacheable if indicated by a Cache-Control or Expires header
1110   field.
1111
1112   The temporary URI SHOULD be given by the Location field in the
1113   response.  Unless the request method was HEAD, the entity of the
1114   response SHOULD contain a short hypertext note with a hyperlink to
1115   the new URI(s).
1116
1117
1118
1119Fielding, et al.          Expires June 22, 2008                [Page 20]
1120
1121Internet-Draft                  HTTP/1.1                   December 2007
1122
1123
1124   If the 302 status code is received in response to a request other
1125   than GET or HEAD, the user agent MUST NOT automatically redirect the
1126   request unless it can be confirmed by the user, since this might
1127   change the conditions under which the request was issued.
1128
1129      Note: RFC 1945 and RFC 2068 specify that the client is not allowed
1130      to change the method on the redirected request.  However, most
1131      existing user agent implementations treat 302 as if it were a 303
1132      response, performing a GET on the Location field-value regardless
1133      of the original request method.  The status codes 303 and 307 have
1134      been added for servers that wish to make unambiguously clear which
1135      kind of reaction is expected of the client.
1136
11379.3.4.  303 See Other
1138
1139   The response to the request can be found under a different URI and
1140   SHOULD be retrieved using a GET method on that resource.  This method
1141   exists primarily to allow the output of a POST-activated script to
1142   redirect the user agent to a selected resource.  The new URI is not a
1143   substitute reference for the originally requested resource.  The 303
1144   response MUST NOT be cached, but the response to the second
1145   (redirected) request might be cacheable.
1146
1147   The different URI SHOULD be given by the Location field in the
1148   response.  Unless the request method was HEAD, the entity of the
1149   response SHOULD contain a short hypertext note with a hyperlink to
1150   the new URI(s).
1151
1152      Note: Many pre-HTTP/1.1 user agents do not understand the 303
1153      status.  When interoperability with such clients is a concern, the
1154      302 status code may be used instead, since most user agents react
1155      to a 302 response as described here for 303.
1156
11579.3.5.  304 Not Modified
1158
1159   The response to the request has not been modified since the
1160   conditions indicated by the client's conditional GET request, as
1161   defined in [Part4].
1162
11639.3.6.  305 Use Proxy
1164
1165   The requested resource MUST be accessed through the proxy given by
1166   the Location field.  The Location field gives the URI of the proxy.
1167   The recipient is expected to repeat this single request via the
1168   proxy. 305 responses MUST only be generated by origin servers.
1169
1170      Note: RFC 2068 was not clear that 305 was intended to redirect a
1171      single request, and to be generated by origin servers only.  Not
1172
1173
1174
1175Fielding, et al.          Expires June 22, 2008                [Page 21]
1176
1177Internet-Draft                  HTTP/1.1                   December 2007
1178
1179
1180      observing these limitations has significant security consequences.
1181
11829.3.7.  306 (Unused)
1183
1184   The 306 status code was used in a previous version of the
1185   specification, is no longer used, and the code is reserved.
1186
11879.3.8.  307 Temporary Redirect
1188
1189   The requested resource resides temporarily under a different URI.
1190   Since the redirection MAY be altered on occasion, the client SHOULD
1191   continue to use the Request-URI for future requests.  This response
1192   is only cacheable if indicated by a Cache-Control or Expires header
1193   field.
1194
1195   The temporary URI SHOULD be given by the Location field in the
1196   response.  Unless the request method was HEAD, the entity of the
1197   response SHOULD contain a short hypertext note with a hyperlink to
1198   the new URI(s) , since many pre-HTTP/1.1 user agents do not
1199   understand the 307 status.  Therefore, the note SHOULD contain the
1200   information necessary for a user to repeat the original request on
1201   the new URI.
1202
1203   If the 307 status code is received in response to a request other
1204   than GET or HEAD, the user agent MUST NOT automatically redirect the
1205   request unless it can be confirmed by the user, since this might
1206   change the conditions under which the request was issued.
1207
12089.4.  Client Error 4xx
1209
1210   The 4xx class of status code is intended for cases in which the
1211   client seems to have erred.  Except when responding to a HEAD
1212   request, the server SHOULD include an entity containing an
1213   explanation of the error situation, and whether it is a temporary or
1214   permanent condition.  These status codes are applicable to any
1215   request method.  User agents SHOULD display any included entity to
1216   the user.
1217
1218   If the client is sending data, a server implementation using TCP
1219   SHOULD be careful to ensure that the client acknowledges receipt of
1220   the packet(s) containing the response, before the server closes the
1221   input connection.  If the client continues sending data to the server
1222   after the close, the server's TCP stack will send a reset packet to
1223   the client, which may erase the client's unacknowledged input buffers
1224   before they can be read and interpreted by the HTTP application.
1225
1226
1227
1228
1229
1230
1231Fielding, et al.          Expires June 22, 2008                [Page 22]
1232
1233Internet-Draft                  HTTP/1.1                   December 2007
1234
1235
12369.4.1.  400 Bad Request
1237
1238   The request could not be understood by the server due to malformed
1239   syntax.  The client SHOULD NOT repeat the request without
1240   modifications.
1241
12429.4.2.  401 Unauthorized
1243
1244   The request requires user authentication (see [Part7]).
1245
12469.4.3.  402 Payment Required
1247
1248   This code is reserved for future use.
1249
12509.4.4.  403 Forbidden
1251
1252   The server understood the request, but is refusing to fulfill it.
1253   Authorization will not help and the request SHOULD NOT be repeated.
1254   If the request method was not HEAD and the server wishes to make
1255   public why the request has not been fulfilled, it SHOULD describe the
1256   reason for the refusal in the entity.  If the server does not wish to
1257   make this information available to the client, the status code 404
1258   (Not Found) can be used instead.
1259
12609.4.5.  404 Not Found
1261
1262   The server has not found anything matching the Request-URI.  No
1263   indication is given of whether the condition is temporary or
1264   permanent.  The 410 (Gone) status code SHOULD be used if the server
1265   knows, through some internally configurable mechanism, that an old
1266   resource is permanently unavailable and has no forwarding address.
1267   This status code is commonly used when the server does not wish to
1268   reveal exactly why the request has been refused, or when no other
1269   response is applicable.
1270
12719.4.6.  405 Method Not Allowed
1272
1273   The method specified in the Request-Line is not allowed for the
1274   resource identified by the Request-URI.  The response MUST include an
1275   Allow header containing a list of valid methods for the requested
1276   resource.
1277
12789.4.7.  406 Not Acceptable
1279
1280   The resource identified by the request is only capable of generating
1281   response entities which have content characteristics not acceptable
1282   according to the accept headers sent in the request.
1283
1284
1285
1286
1287Fielding, et al.          Expires June 22, 2008                [Page 23]
1288
1289Internet-Draft                  HTTP/1.1                   December 2007
1290
1291
1292   Unless it was a HEAD request, the response SHOULD include an entity
1293   containing a list of available entity characteristics and location(s)
1294   from which the user or user agent can choose the one most
1295   appropriate.  The entity format is specified by the media type given
1296   in the Content-Type header field.  Depending upon the format and the
1297   capabilities of the user agent, selection of the most appropriate
1298   choice MAY be performed automatically.  However, this specification
1299   does not define any standard for such automatic selection.
1300
1301      Note: HTTP/1.1 servers are allowed to return responses which are
1302      not acceptable according to the accept headers sent in the
1303      request.  In some cases, this may even be preferable to sending a
1304      406 response.  User agents are encouraged to inspect the headers
1305      of an incoming response to determine if it is acceptable.
1306
1307   If the response could be unacceptable, a user agent SHOULD
1308   temporarily stop receipt of more data and query the user for a
1309   decision on further actions.
1310
13119.4.8.  407 Proxy Authentication Required
1312
1313   This code is similar to 401 (Unauthorized), but indicates that the
1314   client must first authenticate itself with the proxy (see [Part7]).
1315
13169.4.9.  408 Request Timeout
1317
1318   The client did not produce a request within the time that the server
1319   was prepared to wait.  The client MAY repeat the request without
1320   modifications at any later time.
1321
13229.4.10.  409 Conflict
1323
1324   The request could not be completed due to a conflict with the current
1325   state of the resource.  This code is only allowed in situations where
1326   it is expected that the user might be able to resolve the conflict
1327   and resubmit the request.  The response body SHOULD include enough
1328   information for the user to recognize the source of the conflict.
1329   Ideally, the response entity would include enough information for the
1330   user or user agent to fix the problem; however, that might not be
1331   possible and is not required.
1332
1333   Conflicts are most likely to occur in response to a PUT request.  For
1334   example, if versioning were being used and the entity being PUT
1335   included changes to a resource which conflict with those made by an
1336   earlier (third-party) request, the server might use the 409 response
1337   to indicate that it can't complete the request.  In this case, the
1338   response entity would likely contain a list of the differences
1339   between the two versions in a format defined by the response Content-
1340
1341
1342
1343Fielding, et al.          Expires June 22, 2008                [Page 24]
1344
1345Internet-Draft                  HTTP/1.1                   December 2007
1346
1347
1348   Type.
1349
13509.4.11.  410 Gone
1351
1352   The requested resource is no longer available at the server and no
1353   forwarding address is known.  This condition is expected to be
1354   considered permanent.  Clients with link editing capabilities SHOULD
1355   delete references to the Request-URI after user approval.  If the
1356   server does not know, or has no facility to determine, whether or not
1357   the condition is permanent, the status code 404 (Not Found) SHOULD be
1358   used instead.  This response is cacheable unless indicated otherwise.
1359
1360   The 410 response is primarily intended to assist the task of web
1361   maintenance by notifying the recipient that the resource is
1362   intentionally unavailable and that the server owners desire that
1363   remote links to that resource be removed.  Such an event is common
1364   for limited-time, promotional services and for resources belonging to
1365   individuals no longer working at the server's site.  It is not
1366   necessary to mark all permanently unavailable resources as "gone" or
1367   to keep the mark for any length of time -- that is left to the
1368   discretion of the server owner.
1369
13709.4.12.  411 Length Required
1371
1372   The server refuses to accept the request without a defined Content-
1373   Length.  The client MAY repeat the request if it adds a valid
1374   Content-Length header field containing the length of the message-body
1375   in the request message.
1376
13779.4.13.  412 Precondition Failed
1378
1379   The precondition given in one or more of the request-header fields
1380   evaluated to false when it was tested on the server, as defined in
1381   [Part4].
1382
13839.4.14.  413 Request Entity Too Large
1384
1385   The server is refusing to process a request because the request
1386   entity is larger than the server is willing or able to process.  The
1387   server MAY close the connection to prevent the client from continuing
1388   the request.
1389
1390   If the condition is temporary, the server SHOULD include a Retry-
1391   After header field to indicate that it is temporary and after what
1392   time the client MAY try again.
1393
1394
1395
1396
1397
1398
1399Fielding, et al.          Expires June 22, 2008                [Page 25]
1400
1401Internet-Draft                  HTTP/1.1                   December 2007
1402
1403
14049.4.15.  414 Request-URI Too Long
1405
1406   The server is refusing to service the request because the Request-URI
1407   is longer than the server is willing to interpret.  This rare
1408   condition is only likely to occur when a client has improperly
1409   converted a POST request to a GET request with long query
1410   information, when the client has descended into a URI "black hole" of
1411   redirection (e.g., a redirected URI prefix that points to a suffix of
1412   itself), or when the server is under attack by a client attempting to
1413   exploit security holes present in some servers using fixed-length
1414   buffers for reading or manipulating the Request-URI.
1415
14169.4.16.  415 Unsupported Media Type
1417
1418   The server is refusing to service the request because the entity of
1419   the request is in a format not supported by the requested resource
1420   for the requested method.
1421
14229.4.17.  416 Requested Range Not Satisfiable
1423
1424   The request included a Range request-header field (Section 5.4 of
1425   [Part5]) and none of the range-specifier values in this field overlap
1426   the current extent of the selected resource.
1427
14289.4.18.  417 Expectation Failed
1429
1430   The expectation given in an Expect request-header field (see
1431   Section 10.2) could not be met by this server, or, if the server is a
1432   proxy, the server has unambiguous evidence that the request could not
1433   be met by the next-hop server.
1434
14359.5.  Server Error 5xx
1436
1437   Response status codes beginning with the digit "5" indicate cases in
1438   which the server is aware that it has erred or is incapable of
1439   performing the request.  Except when responding to a HEAD request,
1440   the server SHOULD include an entity containing an explanation of the
1441   error situation, and whether it is a temporary or permanent
1442   condition.  User agents SHOULD display any included entity to the
1443   user.  These response codes are applicable to any request method.
1444
14459.5.1.  500 Internal Server Error
1446
1447   The server encountered an unexpected condition which prevented it
1448   from fulfilling the request.
1449
1450
1451
1452
1453
1454
1455Fielding, et al.          Expires June 22, 2008                [Page 26]
1456
1457Internet-Draft                  HTTP/1.1                   December 2007
1458
1459
14609.5.2.  501 Not Implemented
1461
1462   The server does not support the functionality required to fulfill the
1463   request.  This is the appropriate response when the server does not
1464   recognize the request method and is not capable of supporting it for
1465   any resource.
1466
14679.5.3.  502 Bad Gateway
1468
1469   The server, while acting as a gateway or proxy, received an invalid
1470   response from the upstream server it accessed in attempting to
1471   fulfill the request.
1472
14739.5.4.  503 Service Unavailable
1474
1475   The server is currently unable to handle the request due to a
1476   temporary overloading or maintenance of the server.  The implication
1477   is that this is a temporary condition which will be alleviated after
1478   some delay.  If known, the length of the delay MAY be indicated in a
1479   Retry-After header.  If no Retry-After is given, the client SHOULD
1480   handle the response as it would for a 500 response.
1481
1482      Note: The existence of the 503 status code does not imply that a
1483      server must use it when becoming overloaded.  Some servers may
1484      wish to simply refuse the connection.
1485
14869.5.5.  504 Gateway Timeout
1487
1488   The server, while acting as a gateway or proxy, did not receive a
1489   timely response from the upstream server specified by the URI (e.g.
1490   HTTP, FTP, LDAP) or some other auxiliary server (e.g.  DNS) it needed
1491   to access in attempting to complete the request.
1492
1493      Note: Note to implementors: some deployed proxies are known to
1494      return 400 or 500 when DNS lookups time out.
1495
14969.5.6.  505 HTTP Version Not Supported
1497
1498   The server does not support, or refuses to support, the HTTP protocol
1499   version that was used in the request message.  The server is
1500   indicating that it is unable or unwilling to complete the request
1501   using the same major version as the client, as described in Section
1502   3.1 of [Part1], other than with this error message.  The response
1503   SHOULD contain an entity describing why that version is not supported
1504   and what other protocols are supported by that server.
1505
1506
1507
1508
1509
1510
1511Fielding, et al.          Expires June 22, 2008                [Page 27]
1512
1513Internet-Draft                  HTTP/1.1                   December 2007
1514
1515
151610.  Header Field Definitions
1517
1518   This section defines the syntax and semantics of all standard
1519   HTTP/1.1 header fields.  For entity-header fields, both sender and
1520   recipient refer to either the client or the server, depending on who
1521   sends and who receives the entity.
1522
152310.1.  Allow
1524
1525   The Allow entity-header field lists the set of methods supported by
1526   the resource identified by the Request-URI.  The purpose of this
1527   field is strictly to inform the recipient of valid methods associated
1528   with the resource.  An Allow header field MUST be present in a 405
1529   (Method Not Allowed) response.
1530
1531          Allow   = "Allow" ":" #Method
1532
1533   Example of use:
1534
1535          Allow: GET, HEAD, PUT
1536
1537   This field cannot prevent a client from trying other methods.
1538   However, the indications given by the Allow header field value SHOULD
1539   be followed.  The actual set of allowed methods is defined by the
1540   origin server at the time of each request.
1541
1542   The Allow header field MAY be provided with a PUT request to
1543   recommend the methods to be supported by the new or modified
1544   resource.  The server is not required to support these methods and
1545   SHOULD include an Allow header in the response giving the actual
1546   supported methods.
1547
1548   A proxy MUST NOT modify the Allow header field even if it does not
1549   understand all the methods specified, since the user agent might have
1550   other means of communicating with the origin server.
1551
155210.2.  Expect
1553
1554   The Expect request-header field is used to indicate that particular
1555   server behaviors are required by the client.
1556
1557      Expect       =  "Expect" ":" 1#expectation
1558
1559      expectation  =  "100-continue" | expectation-extension
1560      expectation-extension =  token [ "=" ( token | quoted-string )
1561                               *expect-params ]
1562      expect-params =  ";" token [ "=" ( token | quoted-string ) ]
1563
1564
1565
1566
1567Fielding, et al.          Expires June 22, 2008                [Page 28]
1568
1569Internet-Draft                  HTTP/1.1                   December 2007
1570
1571
1572   A server that does not understand or is unable to comply with any of
1573   the expectation values in the Expect field of a request MUST respond
1574   with appropriate error status.  The server MUST respond with a 417
1575   (Expectation Failed) status if any of the expectations cannot be met
1576   or, if there are other problems with the request, some other 4xx
1577   status.
1578
1579   This header field is defined with extensible syntax to allow for
1580   future extensions.  If a server receives a request containing an
1581   Expect field that includes an expectation-extension that it does not
1582   support, it MUST respond with a 417 (Expectation Failed) status.
1583
1584   Comparison of expectation values is case-insensitive for unquoted
1585   tokens (including the 100-continue token), and is case-sensitive for
1586   quoted-string expectation-extensions.
1587
1588   The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy MUST
1589   return a 417 (Expectation Failed) status if it receives a request
1590   with an expectation that it cannot meet.  However, the Expect
1591   request-header itself is end-to-end; it MUST be forwarded if the
1592   request is forwarded.
1593
1594   Many older HTTP/1.0 and HTTP/1.1 applications do not understand the
1595   Expect header.
1596
1597   See Section 7.2.3 of [Part1] for the use of the 100 (continue)
1598   status.
1599
160010.3.  From
1601
1602   The From request-header field, if given, SHOULD contain an Internet
1603   e-mail address for the human user who controls the requesting user
1604   agent.  The address SHOULD be machine-usable, as defined by "mailbox"
1605   in RFC 822 [RFC822] as updated by RFC 1123 [RFC1123]:
1606
1607       From   = "From" ":" mailbox
1608
1609   An example is:
1610
1611       From: webmaster@w3.org
1612
1613   This header field MAY be used for logging purposes and as a means for
1614   identifying the source of invalid or unwanted requests.  It SHOULD
1615   NOT be used as an insecure form of access protection.  The
1616   interpretation of this field is that the request is being performed
1617   on behalf of the person given, who accepts responsibility for the
1618   method performed.  In particular, robot agents SHOULD include this
1619   header so that the person responsible for running the robot can be
1620
1621
1622
1623Fielding, et al.          Expires June 22, 2008                [Page 29]
1624
1625Internet-Draft                  HTTP/1.1                   December 2007
1626
1627
1628   contacted if problems occur on the receiving end.
1629
1630   The Internet e-mail address in this field MAY be separate from the
1631   Internet host which issued the request.  For example, when a request
1632   is passed through a proxy the original issuer's address SHOULD be
1633   used.
1634
1635   The client SHOULD NOT send the From header field without the user's
1636   approval, as it might conflict with the user's privacy interests or
1637   their site's security policy.  It is strongly recommended that the
1638   user be able to disable, enable, and modify the value of this field
1639   at any time prior to a request.
1640
164110.4.  Location
1642
1643   The Location response-header field is used to redirect the recipient
1644   to a location other than the Request-URI for completion of the
1645   request or identification of a new resource.  For 201 (Created)
1646   responses, the Location is that of the new resource which was created
1647   by the request.  For 3xx responses, the location SHOULD indicate the
1648   server's preferred URI for automatic redirection to the resource.
1649   The field value consists of a single absolute URI.
1650
1651       Location       = "Location" ":" absoluteURI
1652
1653   An example is:
1654
1655       Location: http://www.w3.org/pub/WWW/People.html
1656
1657      Note: The Content-Location header field (Section 5.7 of [Part3])
1658      differs from Location in that the Content-Location identifies the
1659      original location of the entity enclosed in the request.  It is
1660      therefore possible for a response to contain header fields for
1661      both Location and Content-Location.
1662
166310.5.  Max-Forwards
1664
1665   The Max-Forwards request-header field provides a mechanism with the
1666   TRACE (Section 8.8) and OPTIONS (Section 8.2) methods to limit the
1667   number of proxies or gateways that can forward the request to the
1668   next inbound server.  This can be useful when the client is
1669   attempting to trace a request chain which appears to be failing or
1670   looping in mid-chain.
1671
1672       Max-Forwards   = "Max-Forwards" ":" 1*DIGIT
1673
1674   The Max-Forwards value is a decimal integer indicating the remaining
1675   number of times this request message may be forwarded.
1676
1677
1678
1679Fielding, et al.          Expires June 22, 2008                [Page 30]
1680
1681Internet-Draft                  HTTP/1.1                   December 2007
1682
1683
1684   Each proxy or gateway recipient of a TRACE or OPTIONS request
1685   containing a Max-Forwards header field MUST check and update its
1686   value prior to forwarding the request.  If the received value is zero
1687   (0), the recipient MUST NOT forward the request; instead, it MUST
1688   respond as the final recipient.  If the received Max-Forwards value
1689   is greater than zero, then the forwarded message MUST contain an
1690   updated Max-Forwards field with a value decremented by one (1).
1691
1692   The Max-Forwards header field MAY be ignored for all other methods
1693   defined by this specification and for any extension methods for which
1694   it is not explicitly referred to as part of that method definition.
1695
169610.6.  Referer
1697
1698   The Referer[sic] request-header field allows the client to specify,
1699   for the server's benefit, the address (URI) of the resource from
1700   which the Request-URI was obtained (the "referrer", although the
1701   header field is misspelled.)  The Referer request-header allows a
1702   server to generate lists of back-links to resources for interest,
1703   logging, optimized caching, etc.  It also allows obsolete or mistyped
1704   links to be traced for maintenance.  The Referer field MUST NOT be
1705   sent if the Request-URI was obtained from a source that does not have
1706   its own URI, such as input from the user keyboard.
1707
1708       Referer        = "Referer" ":" ( absoluteURI | relativeURI )
1709
1710   Example:
1711
1712       Referer: http://www.w3.org/hypertext/DataSources/Overview.html
1713
1714   If the field value is a relative URI, it SHOULD be interpreted
1715   relative to the Request-URI.  The URI MUST NOT include a fragment.
1716   See Section 12.2 for security considerations.
1717
171810.7.  Retry-After
1719
1720   The Retry-After response-header field can be used with a 503 (Service
1721   Unavailable) response to indicate how long the service is expected to
1722   be unavailable to the requesting client.  This field MAY also be used
1723   with any 3xx (Redirection) response to indicate the minimum time the
1724   user-agent is asked wait before issuing the redirected request.  The
1725   value of this field can be either an HTTP-date or an integer number
1726   of seconds (in decimal) after the time of the response.
1727
1728       Retry-After  = "Retry-After" ":" ( HTTP-date | delta-seconds )
1729
1730   Two examples of its use are
1731
1732
1733
1734
1735Fielding, et al.          Expires June 22, 2008                [Page 31]
1736
1737Internet-Draft                  HTTP/1.1                   December 2007
1738
1739
1740       Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
1741       Retry-After: 120
1742
1743   In the latter example, the delay is 2 minutes.
1744
174510.8.  Server
1746
1747   The Server response-header field contains information about the
1748   software used by the origin server to handle the request.  The field
1749   can contain multiple product tokens (Section 2) and comments
1750   identifying the server and any significant subproducts.  The product
1751   tokens are listed in order of their significance for identifying the
1752   application.
1753
1754       Server         = "Server" ":" 1*( product | comment )
1755
1756   Example:
1757
1758       Server: CERN/3.0 libwww/2.17
1759
1760   If the response is being forwarded through a proxy, the proxy
1761   application MUST NOT modify the Server response-header.  Instead, it
1762   SHOULD include a Via field (as described in Section 8.9 of [Part1]).
1763
1764      Note: Revealing the specific software version of the server might
1765      allow the server machine to become more vulnerable to attacks
1766      against software that is known to contain security holes.  Server
1767      implementors are encouraged to make this field a configurable
1768      option.
1769
177010.9.  User-Agent
1771
1772   The User-Agent request-header field contains information about the
1773   user agent originating the request.  This is for statistical
1774   purposes, the tracing of protocol violations, and automated
1775   recognition of user agents for the sake of tailoring responses to
1776   avoid particular user agent limitations.  User agents SHOULD include
1777   this field with requests.  The field can contain multiple product
1778   tokens (Section 2) and comments identifying the agent and any
1779   subproducts which form a significant part of the user agent.  By
1780   convention, the product tokens are listed in order of their
1781   significance for identifying the application.
1782
1783       User-Agent     = "User-Agent" ":" 1*( product | comment )
1784
1785   Example:
1786
1787       User-Agent: CERN-LineMode/2.15 libwww/2.17b3
1788
1789
1790
1791Fielding, et al.          Expires June 22, 2008                [Page 32]
1792
1793Internet-Draft                  HTTP/1.1                   December 2007
1794
1795
179611.  IANA Considerations
1797
1798   TBD.
1799
1800
180112.  Security Considerations
1802
1803   This section is meant to inform application developers, information
1804   providers, and users of the security limitations in HTTP/1.1 as
1805   described by this document.  The discussion does not include
1806   definitive solutions to the problems revealed, though it does make
1807   some suggestions for reducing security risks.
1808
180912.1.  Transfer of Sensitive Information
1810
1811   Like any generic data transfer protocol, HTTP cannot regulate the
1812   content of the data that is transferred, nor is there any a priori
1813   method of determining the sensitivity of any particular piece of
1814   information within the context of any given request.  Therefore,
1815   applications SHOULD supply as much control over this information as
1816   possible to the provider of that information.  Four header fields are
1817   worth special mention in this context: Server, Via, Referer and From.
1818
1819   Revealing the specific software version of the server might allow the
1820   server machine to become more vulnerable to attacks against software
1821   that is known to contain security holes.  Implementors SHOULD make
1822   the Server header field a configurable option.
1823
1824   Proxies which serve as a portal through a network firewall SHOULD
1825   take special precautions regarding the transfer of header information
1826   that identifies the hosts behind the firewall.  In particular, they
1827   SHOULD remove, or replace with sanitized versions, any Via fields
1828   generated behind the firewall.
1829
1830   The Referer header allows reading patterns to be studied and reverse
1831   links drawn.  Although it can be very useful, its power can be abused
1832   if user details are not separated from the information contained in
1833   the Referer.  Even when the personal information has been removed,
1834   the Referer header might indicate a private document's URI whose
1835   publication would be inappropriate.
1836
1837   The information sent in the From field might conflict with the user's
1838   privacy interests or their site's security policy, and hence it
1839   SHOULD NOT be transmitted without the user being able to disable,
1840   enable, and modify the contents of the field.  The user MUST be able
1841   to set the contents of this field within a user preference or
1842   application defaults configuration.
1843
1844
1845
1846
1847Fielding, et al.          Expires June 22, 2008                [Page 33]
1848
1849Internet-Draft                  HTTP/1.1                   December 2007
1850
1851
1852   We suggest, though do not require, that a convenient toggle interface
1853   be provided for the user to enable or disable the sending of From and
1854   Referer information.
1855
1856   The User-Agent (Section 10.9) or Server (Section 10.8) header fields
1857   can sometimes be used to determine that a specific client or server
1858   have a particular security hole which might be exploited.
1859   Unfortunately, this same information is often used for other valuable
1860   purposes for which HTTP currently has no better mechanism.
1861
186212.2.  Encoding Sensitive Information in URI's
1863
1864   Because the source of a link might be private information or might
1865   reveal an otherwise private information source, it is strongly
1866   recommended that the user be able to select whether or not the
1867   Referer field is sent.  For example, a browser client could have a
1868   toggle switch for browsing openly/anonymously, which would
1869   respectively enable/disable the sending of Referer and From
1870   information.
1871
1872   Clients SHOULD NOT include a Referer header field in a (non-secure)
1873   HTTP request if the referring page was transferred with a secure
1874   protocol.
1875
1876   Authors of services which use the HTTP protocol SHOULD NOT use GET
1877   based forms for the submission of sensitive data, because this will
1878   cause this data to be encoded in the Request-URI.  Many existing
1879   servers, proxies, and user agents will log the request URI in some
1880   place where it might be visible to third parties.  Servers can use
1881   POST-based form submission instead
1882
188312.3.  Location Headers and Spoofing
1884
1885   If a single server supports multiple organizations that do not trust
1886   one another, then it MUST check the values of Location and Content-
1887   Location headers in responses that are generated under control of
1888   said organizations to make sure that they do not attempt to
1889   invalidate resources over which they have no authority.
1890
1891
189213.  Acknowledgments
1893
1894   Based on an XML translation of RFC 2616 by Julian Reschke.
1895
1896
189714.  References
1898
1899   [Luo1998]  Luotonen, A., "Tunneling TCP based protocols through Web
1900
1901
1902
1903Fielding, et al.          Expires June 22, 2008                [Page 34]
1904
1905Internet-Draft                  HTTP/1.1                   December 2007
1906
1907
1908              proxy servers",  Work in Progress.
1909
1910   [Part1]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
1911              Masinter, L., Leach, P., and T. Berners-Lee, "HTTP/1.1,
1912              part 1: URIs, Connections, and Message Parsing",
1913              draft-ietf-httpbis-p1-messaging-00 (work in progress),
1914              December 2007.
1915
1916   [Part3]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
1917              Masinter, L., Leach, P., and T. Berners-Lee, "HTTP/1.1,
1918              part 3: Message Payload and Content Negotiation",
1919              draft-ietf-httpbis-p3-payload-00 (work in progress),
1920              December 2007.
1921
1922   [Part4]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
1923              Masinter, L., Leach, P., and T. Berners-Lee, "HTTP/1.1,
1924              part 4: Conditional Requests",
1925              draft-ietf-httpbis-p4-conditional-00 (work in progress),
1926              December 2007.
1927
1928   [Part5]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
1929              Masinter, L., Leach, P., and T. Berners-Lee, "HTTP/1.1,
1930              part 5: Range Requests and Partial Responses",
1931              draft-ietf-httpbis-p5-range-00 (work in progress),
1932              December 2007.
1933
1934   [Part6]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
1935              Masinter, L., Leach, P., and T. Berners-Lee, "HTTP/1.1,
1936              part 6: Caching", draft-ietf-httpbis-p6-cache-00 (work in
1937              progress), December 2007.
1938
1939   [Part7]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
1940              Masinter, L., Leach, P., and T. Berners-Lee, "HTTP/1.1,
1941              part 7: Authentication", draft-ietf-httpbis-p7-auth-00
1942              (work in progress), December 2007.
1943
1944   [RFC1123]  Braden, R., "Requirements for Internet Hosts - Application
1945              and Support", STD 3, RFC 1123, October 1989.
1946
1947   [RFC2068]  Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.
1948              Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
1949              RFC 2068, January 1997.
1950
1951   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
1952              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
1953              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
1954
1955   [RFC822]   Crocker, D., "Standard for the format of ARPA Internet
1956
1957
1958
1959Fielding, et al.          Expires June 22, 2008                [Page 35]
1960
1961Internet-Draft                  HTTP/1.1                   December 2007
1962
1963
1964              text messages", STD 11, RFC 822, August 1982.
1965
1966
1967Appendix A.  Changes from RFC 2068
1968
1969   Clarified which error code should be used for inbound server failures
1970   (e.g.  DNS failures).  (Section 9.5.5).
1971
1972   CREATE had a race that required an Etag be sent when a resource is
1973   first created.  (Section 9.2.2).
1974
1975   Rewrite of message transmission requirements to make it much harder
1976   for implementors to get it wrong, as the consequences of errors here
1977   can have significant impact on the Internet, and to deal with the
1978   following problems:
1979
1980   1.  Changing "HTTP/1.1 or later" to "HTTP/1.1", in contexts where
1981       this was incorrectly placing a requirement on the behavior of an
1982       implementation of a future version of HTTP/1.x
1983
1984   2.  Made it clear that user-agents should retry requests, not
1985       "clients" in general.
1986
1987   3.  Converted requirements for clients to ignore unexpected 100
1988       (Continue) responses, and for proxies to forward 100 responses,
1989       into a general requirement for 1xx responses.
1990
1991   4.  Modified some TCP-specific language, to make it clearer that non-
1992       TCP transports are possible for HTTP.
1993
1994   5.  Require that the origin server MUST NOT wait for the request body
1995       before it sends a required 100 (Continue) response.
1996
1997   6.  Allow, rather than require, a server to omit 100 (Continue) if it
1998       has already seen some of the request body.
1999
2000   7.  Allow servers to defend against denial-of-service attacks and
2001       broken clients.
2002
2003   This change adds the Expect header and 417 status code.
2004
2005   Clean up confusion between 403 and 404 responses.  (Section 9.4.4,
2006   9.4.5, and 9.4.11)
2007
2008   The PATCH, LINK, UNLINK methods were defined but not commonly
2009   implemented in previous versions of this specification.  See RFC 2068
2010   [RFC2068].
2011
2012
2013
2014
2015Fielding, et al.          Expires June 22, 2008                [Page 36]
2016
2017Internet-Draft                  HTTP/1.1                   December 2007
2018
2019
2020Index
2021
2022   1
2023      100 Continue (status code)  16
2024      101 Switching Protocols (status code)  17
2025
2026   2
2027      200 OK (status code)  17
2028      201 Created (status code)  17
2029      202 Accepted (status code)  18
2030      203 Non-Authoritative Information (status code)  18
2031      204 No Content (status code)  18
2032      205 Reset Content (status code)  19
2033      206 Partial Content (status code)  19
2034
2035   3
2036      300 Multiple Choices (status code)  19
2037      301 Moved Permanently (status code)  20
2038      302 Found (status code)  20
2039      303 See Other (status code)  21
2040      304 Not Modified (status code)  21
2041      305 Use Proxy (status code)  21
2042      306 (Unused) (status code)  22
2043      307 Temporary Redirect (status code)  22
2044
2045   4
2046      400 Bad Request (status code)  23
2047      401 Unauthorized (status code)  23
2048      402 Payment Required (status code)  23
2049      403 Forbidden (status code)  23
2050      404 Not Found (status code)  23
2051      405 Method Not Allowed (status code)  23
2052      406 Not Acceptable (status code)  23
2053      407 Proxy Authentication Required (status code)  24
2054      408 Request Timeout (status code)  24
2055      409 Conflict (status code)  24
2056      410 Gone (status code)  25
2057      411 Length Required (status code)  25
2058      412 Precondition Failed (status code)  25
2059      413 Request Entity Too Large (status code)  25
2060      414 Request-URI Too Long (status code)  26
2061      415 Unsupported Media Type (status code)  26
2062      416 Requested Range Not Satisfiable (status code)  26
2063      417 Expectation Failed (status code)  26
2064
2065   5
2066      500 Internal Server Error (status code)  26
2067      501 Not Implemented (status code)  27
2068
2069
2070
2071Fielding, et al.          Expires June 22, 2008                [Page 37]
2072
2073Internet-Draft                  HTTP/1.1                   December 2007
2074
2075
2076      502 Bad Gateway (status code)  27
2077      503 Service Unavailable (status code)  27
2078      504 Gateway Timeout (status code)  27
2079      505 HTTP Version Not Supported (status code)  27
2080
2081   A
2082      Allow header  28
2083
2084   C
2085      CONNECT method  16
2086
2087   D
2088      DELETE method  15
2089
2090   E
2091      Expect header  28
2092
2093   F
2094      From header  29
2095
2096   G
2097      GET method  12
2098      Grammar
2099         Allow  28
2100         Expect  28
2101         expect-params  28
2102         expectation  28
2103         expectation-extension  28
2104         extension-code  8
2105         extension-method  6
2106         From  29
2107         Location  30
2108         Max-Forwards  30
2109         Method  6
2110         product  5
2111         product-version  5
2112         Reason-Phrase  8
2113         Referer  31
2114         request-header  7
2115         response-header  9
2116         Retry-After  31
2117         Server  32
2118         Status-Code  8
2119         User-Agent  32
2120
2121   H
2122      HEAD method  12
2123      Headers
2124
2125
2126
2127Fielding, et al.          Expires June 22, 2008                [Page 38]
2128
2129Internet-Draft                  HTTP/1.1                   December 2007
2130
2131
2132         Allow  28
2133         Expect  28
2134         From  29
2135         Location  30
2136         Max-Forwards  30
2137         Referer  31
2138         Retry-After  31
2139         Server  32
2140         User-Agent  32
2141
2142   L
2143      LINK method  36
2144      Location header  30
2145
2146   M
2147      Max-Forwards header  30
2148      Methods
2149         CONNECT  16
2150         DELETE  15
2151         GET  12
2152         HEAD  12
2153         LINK  36
2154         OPTIONS  11
2155         PATCH  36
2156         POST  13
2157         PUT  14
2158         TRACE  15
2159         UNLINK  36
2160
2161   O
2162      OPTIONS method  11
2163
2164   P
2165      PATCH method  36
2166      POST method  13
2167      PUT method  14
2168
2169   R
2170      Referer header  31
2171      Retry-After header  31
2172
2173   S
2174      Server header  32
2175      Status Codes
2176         100 Continue  16
2177         101 Switching Protocols  17
2178         200 OK  17
2179         201 Created  17
2180
2181
2182
2183Fielding, et al.          Expires June 22, 2008                [Page 39]
2184
2185Internet-Draft                  HTTP/1.1                   December 2007
2186
2187
2188         202 Accepted  18
2189         203 Non-Authoritative Information  18
2190         204 No Content  18
2191         205 Reset Content  19
2192         206 Partial Content  19
2193         300 Multiple Choices  19
2194         301 Moved Permanently  20
2195         302 Found  20
2196         303 See Other  21
2197         304 Not Modified  21
2198         305 Use Proxy  21
2199         306 (Unused)  22
2200         307 Temporary Redirect  22
2201         400 Bad Request  23
2202         401 Unauthorized  23
2203         402 Payment Required  23
2204         403 Forbidden  23
2205         404 Not Found  23
2206         405 Method Not Allowed  23
2207         406 Not Acceptable  23
2208         407 Proxy Authentication Required  24
2209         408 Request Timeout  24
2210         409 Conflict  24
2211         410 Gone  25
2212         411 Length Required  25
2213         412 Precondition Failed  25
2214         413 Request Entity Too Large  25
2215         414 Request-URI Too Long  26
2216         415 Unsupported Media Type  26
2217         416 Requested Range Not Satisfiable  26
2218         417 Expectation Failed  26
2219         500 Internal Server Error  26
2220         501 Not Implemented  27
2221         502 Bad Gateway  27
2222         503 Service Unavailable  27
2223         504 Gateway Timeout  27
2224         505 HTTP Version Not Supported  27
2225
2226   T
2227      TRACE method  15
2228
2229   U
2230      UNLINK method  36
2231      User-Agent header  32
2232
2233
2234
2235
2236
2237
2238
2239Fielding, et al.          Expires June 22, 2008                [Page 40]
2240
2241Internet-Draft                  HTTP/1.1                   December 2007
2242
2243
2244Authors' Addresses
2245
2246   Roy T. Fielding (editor)
2247   Day Software
2248   23 Corporate Plaza DR, Suite 280
2249   Newport Beach, CA  92660
2250   USA
2251
2252   Phone: +1-949-706-5300
2253   Fax:   +1-949-706-5305
2254   Email: fielding@gbiv.com
2255   URI:   http://roy.gbiv.com/
2256
2257
2258   Jim Gettys
2259   One Laptop per Child
2260   21 Oak Knoll Road
2261   Carlisle, MA  01741
2262   USA
2263
2264   Email: jg@laptop.org
2265   URI:   http://www.laptop.org/
2266
2267
2268   Jeffrey C. Mogul
2269   Hewlett-Packard Company
2270   HP Labs, Large Scale Systems Group
2271   1501 Page Mill Road, MS 1177
2272   Palo Alto, CA  94304
2273   USA
2274
2275   Email: JeffMogul@acm.org
2276
2277
2278   Henrik Frystyk Nielsen
2279   Microsoft Corporation
2280   1 Microsoft Way
2281   Redmond, WA  98052
2282   USA
2283
2284   Email: henrikn@microsoft.com
2285
2286
2287
2288
2289
2290
2291
2292
2293
2294
2295Fielding, et al.          Expires June 22, 2008                [Page 41]
2296
2297Internet-Draft                  HTTP/1.1                   December 2007
2298
2299
2300   Larry Masinter
2301   Adobe Systems, Incorporated
2302   345 Park Ave
2303   San Jose, CA  95110
2304   USA
2305
2306   Email: LMM@acm.org
2307   URI:   http://larry.masinter.net/
2308
2309
2310   Paul J. Leach
2311   Microsoft Corporation
2312   1 Microsoft Way
2313   Redmond, WA  98052
2314
2315   Email: paulle@microsoft.com
2316
2317
2318   Tim Berners-Lee
2319   World Wide Web Consortium
2320   MIT Computer Science and Artificial Intelligence Laboratory
2321   The Stata Center, Building 32
2322   32 Vassar Street
2323   Cambridge, MA  02139
2324   USA
2325
2326   Email: timbl@w3.org
2327   URI:   http://www.w3.org/People/Berners-Lee/
2328
2329
2330
2331
2332
2333
2334
2335
2336
2337
2338
2339
2340
2341
2342
2343
2344
2345
2346
2347
2348
2349
2350
2351Fielding, et al.          Expires June 22, 2008                [Page 42]
2352
2353Internet-Draft                  HTTP/1.1                   December 2007
2354
2355
2356Full Copyright Statement
2357
2358   Copyright (C) The IETF Trust (2007).
2359
2360   This document is subject to the rights, licenses and restrictions
2361   contained in BCP 78, and except as set forth therein, the authors
2362   retain all their rights.
2363
2364   This document and the information contained herein are provided on an
2365   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
2366   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
2367   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
2368   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
2369   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
2370   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
2371
2372
2373Intellectual Property
2374
2375   The IETF takes no position regarding the validity or scope of any
2376   Intellectual Property Rights or other rights that might be claimed to
2377   pertain to the implementation or use of the technology described in
2378   this document or the extent to which any license under such rights
2379   might or might not be available; nor does it represent that it has
2380   made any independent effort to identify any such rights.  Information
2381   on the procedures with respect to rights in RFC documents can be
2382   found in BCP 78 and BCP 79.
2383
2384   Copies of IPR disclosures made to the IETF Secretariat and any
2385   assurances of licenses to be made available, or the result of an
2386   attempt made to obtain a general license or permission for the use of
2387   such proprietary rights by implementers or users of this
2388   specification can be obtained from the IETF on-line IPR repository at
2389   http://www.ietf.org/ipr.
2390
2391   The IETF invites any interested party to bring to its attention any
2392   copyrights, patents or patent applications, or other proprietary
2393   rights that may cover technology that may be required to implement
2394   this standard.  Please address the information to the IETF at
2395   ietf-ipr@ietf.org.
2396
2397
2398Acknowledgment
2399
2400   Funding for the RFC Editor function is provided by the IETF
2401   Administrative Support Activity (IASA).
2402
2403
2404
2405
2406
2407Fielding, et al.          Expires June 22, 2008                [Page 43]
2408
Note: See TracBrowser for help on using the repository browser.