source: draft-ietf-httpbis/03/draft-ietf-httpbis-p2-semantics-03.txt @ 912

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

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