source: draft-ietf-httpbis/09/draft-ietf-httpbis-p2-semantics-09.txt @ 2105

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

Prepare publication of -09 drafts on March 08
  • Property svn:executable set to *
File size: 124.4 KB
Line 
1
2
3
4HTTPbis Working Group                                   R. Fielding, Ed.
5Internet-Draft                                              Day Software
6Obsoletes: 2616 (if approved)                                  J. Gettys
7Updates: 2817 (if approved)                         One Laptop per Child
8Intended status: Standards Track                                J. Mogul
9Expires: September 9, 2010                                            HP
10                                                              H. Frystyk
11                                                               Microsoft
12                                                             L. Masinter
13                                                           Adobe Systems
14                                                                P. Leach
15                                                               Microsoft
16                                                          T. Berners-Lee
17                                                                 W3C/MIT
18                                                           Y. Lafon, Ed.
19                                                                     W3C
20                                                         J. Reschke, Ed.
21                                                              greenbytes
22                                                           March 8, 2010
23
24
25                  HTTP/1.1, part 2: Message Semantics
26                   draft-ietf-httpbis-p2-semantics-09
27
28Abstract
29
30   The Hypertext Transfer Protocol (HTTP) is an application-level
31   protocol for distributed, collaborative, hypermedia information
32   systems.  HTTP has been in use by the World Wide Web global
33   information initiative since 1990.  This document is Part 2 of the
34   seven-part specification that defines the protocol referred to as
35   "HTTP/1.1" and, taken together, obsoletes RFC 2616.  Part 2 defines
36   the semantics of HTTP messages as expressed by request methods,
37   request-header fields, response status codes, and response-header
38   fields.
39
40Editorial Note (To be removed by RFC Editor)
41
42   Discussion of this draft should take place on the HTTPBIS working
43   group mailing list (ietf-http-wg@w3.org).  The current issues list is
44   at <http://tools.ietf.org/wg/httpbis/trac/report/11> and related
45   documents (including fancy diffs) can be found at
46   <http://tools.ietf.org/wg/httpbis/>.
47
48   The changes in this draft are summarized in Appendix C.10.
49
50Status of this Memo
51
52
53
54
55Fielding, et al.        Expires September 9, 2010               [Page 1]
56
57Internet-Draft              HTTP/1.1, Part 2                  March 2010
58
59
60   This Internet-Draft is submitted to IETF in full conformance with the
61   provisions of BCP 78 and BCP 79.
62
63   Internet-Drafts are working documents of the Internet Engineering
64   Task Force (IETF), its areas, and its working groups.  Note that
65   other groups may also distribute working documents as Internet-
66   Drafts.
67
68   Internet-Drafts are draft documents valid for a maximum of six months
69   and may be updated, replaced, or obsoleted by other documents at any
70   time.  It is inappropriate to use Internet-Drafts as reference
71   material or to cite them other than as "work in progress."
72
73   The list of current Internet-Drafts can be accessed at
74   http://www.ietf.org/ietf/1id-abstracts.txt.
75
76   The list of Internet-Draft Shadow Directories can be accessed at
77   http://www.ietf.org/shadow.html.
78
79   This Internet-Draft will expire on September 9, 2010.
80
81Copyright Notice
82
83   Copyright (c) 2010 IETF Trust and the persons identified as the
84   document authors.  All rights reserved.
85
86   This document is subject to BCP 78 and the IETF Trust's Legal
87   Provisions Relating to IETF Documents
88   (http://trustee.ietf.org/license-info) in effect on the date of
89   publication of this document.  Please review these documents
90   carefully, as they describe your rights and restrictions with respect
91   to this document.  Code Components extracted from this document must
92   include Simplified BSD License text as described in Section 4.e of
93   the Trust Legal Provisions and are provided without warranty as
94   described in the BSD License.
95
96   This document may contain material from IETF Documents or IETF
97   Contributions published or made publicly available before November
98   10, 2008.  The person(s) controlling the copyright in some of this
99   material may not have granted the IETF Trust the right to allow
100   modifications of such material outside the IETF Standards Process.
101   Without obtaining an adequate license from the person(s) controlling
102   the copyright in such materials, this document may not be modified
103   outside the IETF Standards Process, and derivative works of it may
104   not be created outside the IETF Standards Process, except to format
105   it for publication as an RFC or to translate it into languages other
106   than English.
107
108
109
110
111Fielding, et al.        Expires September 9, 2010               [Page 2]
112
113Internet-Draft              HTTP/1.1, Part 2                  March 2010
114
115
116Table of Contents
117
118   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  6
119     1.1.  Requirements . . . . . . . . . . . . . . . . . . . . . . .  6
120     1.2.  Syntax Notation  . . . . . . . . . . . . . . . . . . . . .  6
121       1.2.1.  Core Rules . . . . . . . . . . . . . . . . . . . . . .  7
122       1.2.2.  ABNF Rules defined in other Parts of the
123               Specification  . . . . . . . . . . . . . . . . . . . .  7
124   2.  Method . . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
125     2.1.  Method Registry  . . . . . . . . . . . . . . . . . . . . .  8
126   3.  Request Header Fields  . . . . . . . . . . . . . . . . . . . .  9
127   4.  Status Code and Reason Phrase  . . . . . . . . . . . . . . . . 10
128     4.1.  Status Code Registry . . . . . . . . . . . . . . . . . . . 12
129   5.  Response Header Fields . . . . . . . . . . . . . . . . . . . . 12
130   6.  Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
131     6.1.  Identifying the Resource Associated with a
132           Representation . . . . . . . . . . . . . . . . . . . . . . 13
133   7.  Method Definitions . . . . . . . . . . . . . . . . . . . . . . 14
134     7.1.  Safe and Idempotent Methods  . . . . . . . . . . . . . . . 14
135       7.1.1.  Safe Methods . . . . . . . . . . . . . . . . . . . . . 14
136       7.1.2.  Idempotent Methods . . . . . . . . . . . . . . . . . . 14
137     7.2.  OPTIONS  . . . . . . . . . . . . . . . . . . . . . . . . . 15
138     7.3.  GET  . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
139     7.4.  HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
140     7.5.  POST . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
141     7.6.  PUT  . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
142     7.7.  DELETE . . . . . . . . . . . . . . . . . . . . . . . . . . 19
143     7.8.  TRACE  . . . . . . . . . . . . . . . . . . . . . . . . . . 19
144     7.9.  CONNECT  . . . . . . . . . . . . . . . . . . . . . . . . . 20
145   8.  Status Code Definitions  . . . . . . . . . . . . . . . . . . . 20
146     8.1.  Informational 1xx  . . . . . . . . . . . . . . . . . . . . 20
147       8.1.1.  100 Continue . . . . . . . . . . . . . . . . . . . . . 20
148       8.1.2.  101 Switching Protocols  . . . . . . . . . . . . . . . 20
149     8.2.  Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 21
150       8.2.1.  200 OK . . . . . . . . . . . . . . . . . . . . . . . . 21
151       8.2.2.  201 Created  . . . . . . . . . . . . . . . . . . . . . 21
152       8.2.3.  202 Accepted . . . . . . . . . . . . . . . . . . . . . 22
153       8.2.4.  203 Non-Authoritative Information  . . . . . . . . . . 22
154       8.2.5.  204 No Content . . . . . . . . . . . . . . . . . . . . 22
155       8.2.6.  205 Reset Content  . . . . . . . . . . . . . . . . . . 23
156       8.2.7.  206 Partial Content  . . . . . . . . . . . . . . . . . 23
157     8.3.  Redirection 3xx  . . . . . . . . . . . . . . . . . . . . . 23
158       8.3.1.  300 Multiple Choices . . . . . . . . . . . . . . . . . 23
159       8.3.2.  301 Moved Permanently  . . . . . . . . . . . . . . . . 24
160       8.3.3.  302 Found  . . . . . . . . . . . . . . . . . . . . . . 24
161       8.3.4.  303 See Other  . . . . . . . . . . . . . . . . . . . . 25
162       8.3.5.  304 Not Modified . . . . . . . . . . . . . . . . . . . 25
163       8.3.6.  305 Use Proxy  . . . . . . . . . . . . . . . . . . . . 26
164
165
166
167Fielding, et al.        Expires September 9, 2010               [Page 3]
168
169Internet-Draft              HTTP/1.1, Part 2                  March 2010
170
171
172       8.3.7.  306 (Unused) . . . . . . . . . . . . . . . . . . . . . 26
173       8.3.8.  307 Temporary Redirect . . . . . . . . . . . . . . . . 26
174     8.4.  Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 26
175       8.4.1.  400 Bad Request  . . . . . . . . . . . . . . . . . . . 27
176       8.4.2.  401 Unauthorized . . . . . . . . . . . . . . . . . . . 27
177       8.4.3.  402 Payment Required . . . . . . . . . . . . . . . . . 27
178       8.4.4.  403 Forbidden  . . . . . . . . . . . . . . . . . . . . 27
179       8.4.5.  404 Not Found  . . . . . . . . . . . . . . . . . . . . 27
180       8.4.6.  405 Method Not Allowed . . . . . . . . . . . . . . . . 27
181       8.4.7.  406 Not Acceptable . . . . . . . . . . . . . . . . . . 28
182       8.4.8.  407 Proxy Authentication Required  . . . . . . . . . . 28
183       8.4.9.  408 Request Timeout  . . . . . . . . . . . . . . . . . 28
184       8.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 28
185       8.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 29
186       8.4.12. 411 Length Required  . . . . . . . . . . . . . . . . . 29
187       8.4.13. 412 Precondition Failed  . . . . . . . . . . . . . . . 29
188       8.4.14. 413 Request Entity Too Large . . . . . . . . . . . . . 29
189       8.4.15. 414 URI Too Long . . . . . . . . . . . . . . . . . . . 30
190       8.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . . 30
191       8.4.17. 416 Requested Range Not Satisfiable  . . . . . . . . . 30
192       8.4.18. 417 Expectation Failed . . . . . . . . . . . . . . . . 30
193     8.5.  Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 30
194       8.5.1.  500 Internal Server Error  . . . . . . . . . . . . . . 31
195       8.5.2.  501 Not Implemented  . . . . . . . . . . . . . . . . . 31
196       8.5.3.  502 Bad Gateway  . . . . . . . . . . . . . . . . . . . 31
197       8.5.4.  503 Service Unavailable  . . . . . . . . . . . . . . . 31
198       8.5.5.  504 Gateway Timeout  . . . . . . . . . . . . . . . . . 31
199       8.5.6.  505 HTTP Version Not Supported . . . . . . . . . . . . 31
200   9.  Header Field Definitions . . . . . . . . . . . . . . . . . . . 32
201     9.1.  Allow  . . . . . . . . . . . . . . . . . . . . . . . . . . 32
202     9.2.  Expect . . . . . . . . . . . . . . . . . . . . . . . . . . 32
203     9.3.  From . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
204     9.4.  Location . . . . . . . . . . . . . . . . . . . . . . . . . 34
205     9.5.  Max-Forwards . . . . . . . . . . . . . . . . . . . . . . . 35
206     9.6.  Referer  . . . . . . . . . . . . . . . . . . . . . . . . . 35
207     9.7.  Retry-After  . . . . . . . . . . . . . . . . . . . . . . . 36
208     9.8.  Server . . . . . . . . . . . . . . . . . . . . . . . . . . 36
209     9.9.  User-Agent . . . . . . . . . . . . . . . . . . . . . . . . 37
210   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 37
211     10.1. Method Registry  . . . . . . . . . . . . . . . . . . . . . 37
212     10.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 38
213     10.3. Message Header Registration  . . . . . . . . . . . . . . . 39
214   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 40
215     11.1. Transfer of Sensitive Information  . . . . . . . . . . . . 40
216     11.2. Encoding Sensitive Information in URIs . . . . . . . . . . 41
217     11.3. Location Headers and Spoofing  . . . . . . . . . . . . . . 42
218   12. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 42
219   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42
220
221
222
223Fielding, et al.        Expires September 9, 2010               [Page 4]
224
225Internet-Draft              HTTP/1.1, Part 2                  March 2010
226
227
228     13.1. Normative References . . . . . . . . . . . . . . . . . . . 42
229     13.2. Informative References . . . . . . . . . . . . . . . . . . 43
230   Appendix A.  Compatibility with Previous Versions  . . . . . . . . 43
231     A.1.  Changes from RFC 2068  . . . . . . . . . . . . . . . . . . 43
232     A.2.  Changes from RFC 2616  . . . . . . . . . . . . . . . . . . 44
233   Appendix B.  Collected ABNF  . . . . . . . . . . . . . . . . . . . 45
234   Appendix C.  Change Log (to be removed by RFC Editor before
235                publication)  . . . . . . . . . . . . . . . . . . . . 48
236     C.1.  Since RFC2616  . . . . . . . . . . . . . . . . . . . . . . 48
237     C.2.  Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 48
238     C.3.  Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . . 49
239     C.4.  Since draft-ietf-httpbis-p2-semantics-02 . . . . . . . . . 49
240     C.5.  Since draft-ietf-httpbis-p2-semantics-03 . . . . . . . . . 50
241     C.6.  Since draft-ietf-httpbis-p2-semantics-04 . . . . . . . . . 50
242     C.7.  Since draft-ietf-httpbis-p2-semantics-05 . . . . . . . . . 51
243     C.8.  Since draft-ietf-httpbis-p2-semantics-06 . . . . . . . . . 51
244     C.9.  Since draft-ietf-httpbis-p2-semantics-07 . . . . . . . . . 51
245     C.10. Since draft-ietf-httpbis-p2-semantics-08 . . . . . . . . . 52
246   Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
247   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279Fielding, et al.        Expires September 9, 2010               [Page 5]
280
281Internet-Draft              HTTP/1.1, Part 2                  March 2010
282
283
2841.  Introduction
285
286   This document defines HTTP/1.1 request and response semantics.  Each
287   HTTP message, as defined in [Part1], is in the form of either a
288   request or a response.  An HTTP server listens on a connection for
289   HTTP requests and responds to each request, in the order received on
290   that connection, with one or more HTTP response messages.  This
291   document defines the commonly agreed upon semantics of the HTTP
292   uniform interface, the intentions defined by each request method, and
293   the various response messages that might be expected as a result of
294   applying that method for the requested resource.
295
296   This document is currently disorganized in order to minimize the
297   changes between drafts and enable reviewers to see the smaller errata
298   changes.  The next draft will reorganize the sections to better
299   reflect the content.  In particular, the sections will be ordered
300   according to the typical processing of an HTTP request message (after
301   message parsing): resource mapping, general header fields, methods,
302   request modifiers, response status, and resource metadata.  The
303   current mess reflects how widely dispersed these topics and
304   associated requirements had become in [RFC2616].
305
3061.1.  Requirements
307
308   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
309   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
310   document are to be interpreted as described in [RFC2119].
311
312   An implementation is not compliant if it fails to satisfy one or more
313   of the MUST or REQUIRED level requirements for the protocols it
314   implements.  An implementation that satisfies all the MUST or
315   REQUIRED level and all the SHOULD level requirements for its
316   protocols is said to be "unconditionally compliant"; one that
317   satisfies all the MUST level requirements but not all the SHOULD
318   level requirements for its protocols is said to be "conditionally
319   compliant."
320
3211.2.  Syntax Notation
322
323   This specification uses the ABNF syntax defined in Section 1.2 of
324   [Part1] (which extends the syntax defined in [RFC5234] with a list
325   rule).  Appendix B shows the collected ABNF, with the list rule
326   expanded.
327
328   The following core rules are included by reference, as defined in
329   [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
330   (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
331   HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit
332
333
334
335Fielding, et al.        Expires September 9, 2010               [Page 6]
336
337Internet-Draft              HTTP/1.1, Part 2                  March 2010
338
339
340   sequence of data), SP (space), VCHAR (any visible USASCII character),
341   and WSP (whitespace).
342
3431.2.1.  Core Rules
344
345   The core rules below are defined in Section 1.2.2 of [Part1]:
346
347     quoted-string = <quoted-string, defined in [Part1], Section 1.2.2>
348     token         = <token, defined in [Part1], Section 1.2.2>
349     OWS           = <OWS, defined in [Part1], Section 1.2.2>
350     RWS           = <RWS, defined in [Part1], Section 1.2.2>
351     obs-text      = <obs-text, defined in [Part1], Section 1.2.2>
352
3531.2.2.  ABNF Rules defined in other Parts of the Specification
354
355   The ABNF rules below are defined in other parts:
356
357     absolute-URI  = <absolute-URI, defined in [Part1], Section 2.6>
358     comment       = <comment, defined in [Part1], Section 3.2>
359     Host          = <Host, defined in [Part1], Section 2.6>
360     HTTP-date     = <HTTP-date, defined in [Part1], Section 6.1>
361     partial-URI   = <partial-URI, defined in [Part1], Section 2.6>
362     product       = <product, defined in [Part1], Section 6.3>
363     TE            = <TE, defined in [Part1], Section 9.8>
364     URI           = <URI, defined in [Part1], Section 2.6>
365
366
367     Accept        = <Accept, defined in [Part3], Section 5.1>
368     Accept-Charset =
369                <Accept-Charset, defined in [Part3], Section 5.2>
370     Accept-Encoding =
371                <Accept-Encoding, defined in [Part3], Section 5.3>
372     Accept-Language =
373                <Accept-Language, defined in [Part3], Section 5.4>
374
375
376     ETag          = <ETag, defined in [Part4], Section 6.1>
377     If-Match      = <If-Match, defined in [Part4], Section 6.2>
378     If-Modified-Since =
379                <If-Modified-Since, defined in [Part4], Section 6.3>
380     If-None-Match = <If-None-Match, defined in [Part4], Section 6.4>
381     If-Unmodified-Since =
382                <If-Unmodified-Since, defined in [Part4], Section 6.5>
383
384
385     Accept-Ranges = <Accept-Ranges, defined in [Part5], Section 5.1>
386     If-Range      = <If-Range, defined in [Part5], Section 5.3>
387     Range         = <Range, defined in [Part5], Section 5.4>
388
389
390
391Fielding, et al.        Expires September 9, 2010               [Page 7]
392
393Internet-Draft              HTTP/1.1, Part 2                  March 2010
394
395
396     Age           = <Age, defined in [Part6], Section 3.1>
397     Vary          = <Vary, defined in [Part6], Section 3.5>
398
399
400     Authorization = <Authorization, defined in [Part7], Section 3.1>
401     Proxy-Authenticate =
402                <Proxy-Authenticate, defined in [Part7], Section 3.2>
403     Proxy-Authorization =
404                <Proxy-Authorization, defined in [Part7], Section 3.3>
405     WWW-Authenticate =
406                <WWW-Authenticate, defined in [Part7], Section 3.4>
407
408
4092.  Method
410
411   The Method token indicates the method to be performed on the resource
412   identified by the request-target.  The method is case-sensitive.
413
414     Method         = %x4F.50.54.49.4F.4E.53   ; "OPTIONS", Section 7.2
415                    / %x47.45.54               ; "GET", Section 7.3
416                    / %x48.45.41.44            ; "HEAD", Section 7.4
417                    / %x50.4F.53.54            ; "POST", Section 7.5
418                    / %x50.55.54               ; "PUT", Section 7.6
419                    / %x44.45.4C.45.54.45      ; "DELETE", Section 7.7
420                    / %x54.52.41.43.45         ; "TRACE", Section 7.8
421                    / %x43.4F.4E.4E.45.43.54   ; "CONNECT", Section 7.9
422                    / extension-method
423     extension-method = token
424
425   The list of methods allowed by a resource can be specified in an
426   Allow header field (Section 9.1).  The return code of the response
427   always notifies the client whether a method is currently allowed on a
428   resource, since the set of allowed methods can change dynamically.
429   An origin server SHOULD return the status code 405 (Method Not
430   Allowed) if the method is known by the origin server but not allowed
431   for the requested resource, and 501 (Not Implemented) if the method
432   is unrecognized or not implemented by the origin server.  The methods
433   GET and HEAD MUST be supported by all general-purpose servers.  All
434   other methods are OPTIONAL; however, if the above methods are
435   implemented, they MUST be implemented with the same semantics as
436   those specified in Section 7.
437
4382.1.  Method Registry
439
440   The HTTP Method Registry defines the name space for the Method token
441   in the Request line of an HTTP request.
442
443   Registrations MUST include the following fields:
444
445
446
447Fielding, et al.        Expires September 9, 2010               [Page 8]
448
449Internet-Draft              HTTP/1.1, Part 2                  March 2010
450
451
452   o  Method Name (see Section 2)
453
454   o  Safe ("yes" or "no", see Section 7.1.1)
455
456   o  Pointer to specification text
457
458   Values to be added to this name space are subject to IETF review
459   ([RFC5226], Section 4.1).
460
461   The registry itself is maintained at
462   <http://www.iana.org/assignments/http-methods>.
463
464
4653.  Request Header Fields
466
467   The request-header fields allow the client to pass additional
468   information about the request, and about the client itself, to the
469   server.  These fields act as request modifiers, with semantics
470   equivalent to the parameters on a programming language method
471   invocation.
472
473     request-header = Accept                   ; [Part3], Section 5.1
474                    / Accept-Charset           ; [Part3], Section 5.2
475                    / Accept-Encoding          ; [Part3], Section 5.3
476                    / Accept-Language          ; [Part3], Section 5.4
477                    / Authorization            ; [Part7], Section 3.1
478                    / Expect                   ; Section 9.2
479                    / From                     ; Section 9.3
480                    / Host                     ; [Part1], Section 9.4
481                    / If-Match                 ; [Part4], Section 6.2
482                    / If-Modified-Since        ; [Part4], Section 6.3
483                    / If-None-Match            ; [Part4], Section 6.4
484                    / If-Range                 ; [Part5], Section 5.3
485                    / If-Unmodified-Since      ; [Part4], Section 6.5
486                    / Max-Forwards             ; Section 9.5
487                    / Proxy-Authorization      ; [Part7], Section 3.3
488                    / Range                    ; [Part5], Section 5.4
489                    / Referer                  ; Section 9.6
490                    / TE                       ; [Part1], Section 9.8
491                    / User-Agent               ; Section 9.9
492
493   Request-header field names can be extended reliably only in
494   combination with a change in the protocol version.  However, new or
495   experimental header fields MAY be given the semantics of request-
496   header fields if all parties in the communication recognize them to
497   be request-header fields.  Unrecognized header fields are treated as
498   entity-header fields.
499
500
501
502
503Fielding, et al.        Expires September 9, 2010               [Page 9]
504
505Internet-Draft              HTTP/1.1, Part 2                  March 2010
506
507
5084.  Status Code and Reason Phrase
509
510   The Status-Code element is a 3-digit integer result code of the
511   attempt to understand and satisfy the request.  The status codes
512   listed below are defined in Section 8.  The Reason-Phrase is intended
513   to give a short textual description of the Status-Code.  The Status-
514   Code is intended for use by automata and the Reason-Phrase is
515   intended for the human user.  The client is not required to examine
516   or display the Reason-Phrase.
517
518   The individual values of the numeric status codes defined for
519   HTTP/1.1, and an example set of corresponding Reason-Phrase values,
520   are presented below.  The reason phrases listed here are only
521   recommendations -- they MAY be replaced by local equivalents without
522   affecting the protocol.
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559Fielding, et al.        Expires September 9, 2010              [Page 10]
560
561Internet-Draft              HTTP/1.1, Part 2                  March 2010
562
563
564     Status-Code    =
565            "100"  ; Section 8.1.1: Continue
566          / "101"  ; Section 8.1.2: Switching Protocols
567          / "200"  ; Section 8.2.1: OK
568          / "201"  ; Section 8.2.2: Created
569          / "202"  ; Section 8.2.3: Accepted
570          / "203"  ; Section 8.2.4: Non-Authoritative Information
571          / "204"  ; Section 8.2.5: No Content
572          / "205"  ; Section 8.2.6: Reset Content
573          / "206"  ; [Part5], Section 3.1: Partial Content
574          / "300"  ; Section 8.3.1: Multiple Choices
575          / "301"  ; Section 8.3.2: Moved Permanently
576          / "302"  ; Section 8.3.3: Found
577          / "303"  ; Section 8.3.4: See Other
578          / "304"  ; [Part4], Section 3.1: Not Modified
579          / "305"  ; Section 8.3.6: Use Proxy
580          / "307"  ; Section 8.3.8: Temporary Redirect
581          / "400"  ; Section 8.4.1: Bad Request
582          / "401"  ; [Part7], Section 2.1: Unauthorized
583          / "402"  ; Section 8.4.3: Payment Required
584          / "403"  ; Section 8.4.4: Forbidden
585          / "404"  ; Section 8.4.5: Not Found
586          / "405"  ; Section 8.4.6: Method Not Allowed
587          / "406"  ; Section 8.4.7: Not Acceptable
588          / "407"  ; [Part7], Section 2.2: Proxy Authentication Required
589          / "408"  ; Section 8.4.9: Request Time-out
590          / "409"  ; Section 8.4.10: Conflict
591          / "410"  ; Section 8.4.11: Gone
592          / "411"  ; Section 8.4.12: Length Required
593          / "412"  ; [Part4], Section 3.2: Precondition Failed
594          / "413"  ; Section 8.4.14: Request Entity Too Large
595          / "414"  ; Section 8.4.15: URI Too Long
596          / "415"  ; Section 8.4.16: Unsupported Media Type
597          / "416"  ; status-416;: Requested range not satisfiable
598          / "417"  ; Section 8.4.18: Expectation Failed
599          / "500"  ; Section 8.5.1: Internal Server Error
600          / "501"  ; Section 8.5.2: Not Implemented
601          / "502"  ; Section 8.5.3: Bad Gateway
602          / "503"  ; Section 8.5.4: Service Unavailable
603          / "504"  ; Section 8.5.5: Gateway Time-out
604          / "505"  ; Section 8.5.6: HTTP Version not supported
605          / extension-code
606
607     extension-code = 3DIGIT
608     Reason-Phrase  = *( WSP / VCHAR / obs-text )
609
610   HTTP status codes are extensible.  HTTP applications are not required
611   to understand the meaning of all registered status codes, though such
612
613
614
615Fielding, et al.        Expires September 9, 2010              [Page 11]
616
617Internet-Draft              HTTP/1.1, Part 2                  March 2010
618
619
620   understanding is obviously desirable.  However, applications MUST
621   understand the class of any status code, as indicated by the first
622   digit, and treat any unrecognized response as being equivalent to the
623   x00 status code of that class, with the exception that an
624   unrecognized response MUST NOT be cached.  For example, if an
625   unrecognized status code of 431 is received by the client, it can
626   safely assume that there was something wrong with its request and
627   treat the response as if it had received a 400 status code.  In such
628   cases, user agents SHOULD present to the user the entity returned
629   with the response, since that entity is likely to include human-
630   readable information which will explain the unusual status.
631
6324.1.  Status Code Registry
633
634   The HTTP Status Code Registry defines the name space for the Status-
635   Code token in the Status line of an HTTP response.
636
637   Values to be added to this name space are subject to IETF review
638   ([RFC5226], Section 4.1).
639
640   The registry itself is maintained at
641   <http://www.iana.org/assignments/http-status-codes>.
642
643
6445.  Response Header Fields
645
646   The response-header fields allow the server to pass additional
647   information about the response which cannot be placed in the Status-
648   Line.  These header fields give information about the server and
649   about further access to the resource identified by the request-
650   target.
651
652     response-header = Accept-Ranges           ; [Part5], Section 5.1
653                     / Age                     ; [Part6], Section 3.1
654                     / Allow                   ; Section 9.1
655                     / ETag                    ; [Part4], Section 6.1
656                     / Location                ; Section 9.4
657                     / Proxy-Authenticate      ; [Part7], Section 3.2
658                     / Retry-After             ; Section 9.7
659                     / Server                  ; Section 9.8
660                     / Vary                    ; [Part6], Section 3.5
661                     / WWW-Authenticate        ; [Part7], Section 3.4
662
663   Response-header field names can be extended reliably only in
664   combination with a change in the protocol version.  However, new or
665   experimental header fields MAY be given the semantics of response-
666   header fields if all parties in the communication recognize them to
667   be response-header fields.  Unrecognized header fields are treated as
668
669
670
671Fielding, et al.        Expires September 9, 2010              [Page 12]
672
673Internet-Draft              HTTP/1.1, Part 2                  March 2010
674
675
676   entity-header fields.
677
678
6796.  Entity
680
681   Request and Response messages MAY transfer an entity if not otherwise
682   restricted by the request method or response status code.  An entity
683   consists of entity-header fields and an entity-body, although some
684   responses will only include the entity-headers.  HTTP entity-body and
685   entity-header fields are defined in [Part3].
686
687   An entity-body is only present in a message when a message-body is
688   present, as described in Section 3.3 of [Part1].  The entity-body is
689   obtained from the message-body by decoding any Transfer-Encoding that
690   might have been applied to ensure safe and proper transfer of the
691   message.
692
6936.1.  Identifying the Resource Associated with a Representation
694
695   It is sometimes necessary to determine the identity of the resource
696   associated with a representation.
697
698   An HTTP request representation, when present, is always associated
699   with an anonymous (i.e., unidentified) resource.
700
701   In the common case, an HTTP response is a representation of the
702   resource located at the request-URI.  However, this is not always the
703   case.  To determine the URI of the resource a response is associated
704   with, the following rules are used (with the first applicable one
705   being selected):
706
707   1.  If the response status code is 200 or 203 and the request method
708       was GET, the response is a representation of the resource at the
709       request-URI.
710
711   2.  If the response status is 204, 206, or 304 and the request method
712       was GET or HEAD, the response is a partial representation of the
713       resource at the request-URI (see Section 2.7 of [Part6]).
714
715   3.  If the response has a Content-Location header, and that URI is
716       the same as the request-URI [[TODO-missref-requri: (see [ref])]],
717       the response is a representation of the resource at the request-
718       URI.
719
720   4.  If the response has a Content-Location header, and that URI is
721       not the same as the request-URI, the response asserts that it is
722       a representation of the resource at the Content-Location URI (but
723       it may not be).
724
725
726
727Fielding, et al.        Expires September 9, 2010              [Page 13]
728
729Internet-Draft              HTTP/1.1, Part 2                  March 2010
730
731
732   5.  Otherwise, the response is a representation of an anonymous
733       (i.e., unidentified) resource.
734
735   [[TODO-req-uri: Note that "request-URI" is used here; however, we
736   need to come up with a term to denote "the URI that can be inferred
737   from examining the request-target and the Host header." (see
738   <http://tools.ietf.org/wg/httpbis/trac/ticket/196>).  Also, the
739   comparison function is going to have to be defined somewhere, because
740   we already need to compare URIs for things like cache invalidation.]]
741
742
7437.  Method Definitions
744
745   The set of common methods for HTTP/1.1 is defined below.  Although
746   this set can be expanded, additional methods cannot be assumed to
747   share the same semantics for separately extended clients and servers.
748
7497.1.  Safe and Idempotent Methods
750
7517.1.1.  Safe Methods
752
753   Implementors should be aware that the software represents the user in
754   their interactions over the Internet, and should be careful to allow
755   the user to be aware of any actions they might take which may have an
756   unexpected significance to themselves or others.
757
758   In particular, the convention has been established that the GET,
759   HEAD, OPTIONS, and TRACE methods SHOULD NOT have the significance of
760   taking an action other than retrieval.  These methods ought to be
761   considered "safe".  This allows user agents to represent other
762   methods, such as POST, PUT and DELETE, in a special way, so that the
763   user is made aware of the fact that a possibly unsafe action is being
764   requested.
765
766   Naturally, it is not possible to ensure that the server does not
767   generate side-effects as a result of performing a GET request; in
768   fact, some dynamic resources consider that a feature.  The important
769   distinction here is that the user did not request the side-effects,
770   so therefore cannot be held accountable for them.
771
7727.1.2.  Idempotent Methods
773
774   Methods can also have the property of "idempotence" in that, aside
775   from error or expiration issues, the intended effect of multiple
776   identical requests is the same as for a single request.  The methods
777   PUT, DELETE, and all safe methods are idempotent.  It is important to
778   note that idempotence refers only to changes requested by the client:
779   a server is free to change its state due to multiple requests for the
780
781
782
783Fielding, et al.        Expires September 9, 2010              [Page 14]
784
785Internet-Draft              HTTP/1.1, Part 2                  March 2010
786
787
788   purpose of tracking those requests, versioning of results, etc.
789
7907.2.  OPTIONS
791
792   The OPTIONS method represents a request for information about the
793   communication options available on the request/response chain
794   identified by the request-target.  This method allows the client to
795   determine the options and/or requirements associated with a resource,
796   or the capabilities of a server, without implying a resource action
797   or initiating a resource retrieval.
798
799   Responses to this method are not cacheable.
800
801   If the OPTIONS request includes an entity-body (as indicated by the
802   presence of Content-Length or Transfer-Encoding), then the media type
803   MUST be indicated by a Content-Type field.  Although this
804   specification does not define any use for such a body, future
805   extensions to HTTP might use the OPTIONS body to make more detailed
806   queries on the server.
807
808   If the request-target is an asterisk ("*"), the OPTIONS request is
809   intended to apply to the server in general rather than to a specific
810   resource.  Since a server's communication options typically depend on
811   the resource, the "*" request is only useful as a "ping" or "no-op"
812   type of method; it does nothing beyond allowing the client to test
813   the capabilities of the server.  For example, this can be used to
814   test a proxy for HTTP/1.1 compliance (or lack thereof).
815
816   If the request-target is not an asterisk, the OPTIONS request applies
817   only to the options that are available when communicating with that
818   resource.
819
820   A 200 response SHOULD include any header fields that indicate
821   optional features implemented by the server and applicable to that
822   resource (e.g., Allow), possibly including extensions not defined by
823   this specification.  The response body, if any, SHOULD also include
824   information about the communication options.  The format for such a
825   body is not defined by this specification, but might be defined by
826   future extensions to HTTP.  Content negotiation MAY be used to select
827   the appropriate response format.  If no response body is included,
828   the response MUST include a Content-Length field with a field-value
829   of "0".
830
831   The Max-Forwards request-header field MAY be used to target a
832   specific proxy in the request chain.  When a proxy receives an
833   OPTIONS request on an absolute-URI for which request forwarding is
834   permitted, the proxy MUST check for a Max-Forwards field.  If the
835   Max-Forwards field-value is zero ("0"), the proxy MUST NOT forward
836
837
838
839Fielding, et al.        Expires September 9, 2010              [Page 15]
840
841Internet-Draft              HTTP/1.1, Part 2                  March 2010
842
843
844   the message; instead, the proxy SHOULD respond with its own
845   communication options.  If the Max-Forwards field-value is an integer
846   greater than zero, the proxy MUST decrement the field-value when it
847   forwards the request.  If no Max-Forwards field is present in the
848   request, then the forwarded request MUST NOT include a Max-Forwards
849   field.
850
8517.3.  GET
852
853   The GET method means retrieve whatever information (in the form of an
854   entity) currently corresponds to the resource identified by the
855   request-target.
856
857   If the request-target identifies a data-producing process, it is the
858   produced data which shall be returned as the entity in the response
859   and not the source text of the process, unless that text happens to
860   be the output of the process.
861
862   The semantics of the GET method change to a "conditional GET" if the
863   request message includes an If-Modified-Since, If-Unmodified-Since,
864   If-Match, If-None-Match, or If-Range header field.  A conditional GET
865   method requests that the entity be transferred only under the
866   circumstances described by the conditional header field(s).  The
867   conditional GET method is intended to reduce unnecessary network
868   usage by allowing cached entities to be refreshed without requiring
869   multiple requests or transferring data already held by the client.
870
871   The semantics of the GET method change to a "partial GET" if the
872   request message includes a Range header field.  A partial GET
873   requests that only part of the entity be transferred, as described in
874   Section 5.4 of [Part5].  The partial GET method is intended to reduce
875   unnecessary network usage by allowing partially-retrieved entities to
876   be completed without transferring data already held by the client.
877
878   The response to a GET request is cacheable if and only if it meets
879   the requirements for HTTP caching described in [Part6].
880
881   See Section 11.2 for security considerations when used for forms.
882
8837.4.  HEAD
884
885   The HEAD method is identical to GET except that the server MUST NOT
886   return a message-body in the response.  The metainformation contained
887   in the HTTP headers in response to a HEAD request SHOULD be identical
888   to the information sent in response to a GET request.  This method
889   can be used for obtaining metainformation about the entity implied by
890   the request without transferring the entity-body itself.  This method
891   is often used for testing hypertext links for validity,
892
893
894
895Fielding, et al.        Expires September 9, 2010              [Page 16]
896
897Internet-Draft              HTTP/1.1, Part 2                  March 2010
898
899
900   accessibility, and recent modification.
901
902   The response to a HEAD request MAY be cacheable in the sense that the
903   information contained in the response MAY be used to update a
904   previously cached entity from that resource.  If the new field values
905   indicate that the cached entity differs from the current entity (as
906   would be indicated by a change in Content-Length, Content-MD5, ETag
907   or Last-Modified), then the cache MUST treat the cache entry as
908   stale.
909
9107.5.  POST
911
912   The POST method is used to request that the origin server accept the
913   entity enclosed in the request as data to be processed by the
914   resource identified by the request-target in the Request-Line.  POST
915   is designed to allow a uniform method to cover the following
916   functions:
917
918   o  Annotation of existing resources;
919
920   o  Posting a message to a bulletin board, newsgroup, mailing list, or
921      similar group of articles;
922
923   o  Providing a block of data, such as the result of submitting a
924      form, to a data-handling process;
925
926   o  Extending a database through an append operation.
927
928   The actual function performed by the POST method is determined by the
929   server and is usually dependent on the request-target.
930
931   The action performed by the POST method might not result in a
932   resource that can be identified by a URI.  In this case, either 200
933   (OK) or 204 (No Content) is the appropriate response status,
934   depending on whether or not the response includes an entity that
935   describes the result.
936
937   If a resource has been created on the origin server, the response
938   SHOULD be 201 (Created) and contain an entity which describes the
939   status of the request and refers to the new resource, and a Location
940   header (see Section 9.4).
941
942   Responses to this method are not cacheable, unless the response
943   includes appropriate Cache-Control or Expires header fields.
944   However, the 303 (See Other) response can be used to direct the user
945   agent to retrieve a cacheable resource.
946
947
948
949
950
951Fielding, et al.        Expires September 9, 2010              [Page 17]
952
953Internet-Draft              HTTP/1.1, Part 2                  March 2010
954
955
9567.6.  PUT
957
958   The PUT method requests that the enclosed entity be stored at the
959   supplied request-target.  If the request-target refers to an already
960   existing resource, the enclosed entity SHOULD be considered as a
961   modified version of the one residing on the origin server.  If the
962   request-target does not point to an existing resource, and that URI
963   is capable of being defined as a new resource by the requesting user
964   agent, the origin server can create the resource with that URI.  If a
965   new resource is created at the request-target, the origin server MUST
966   inform the user agent via the 201 (Created) response.  If an existing
967   resource is modified, either the 200 (OK) or 204 (No Content)
968   response codes SHOULD be sent to indicate successful completion of
969   the request.  If the resource could not be created or modified with
970   the request-target, an appropriate error response SHOULD be given
971   that reflects the nature of the problem.  The recipient of the entity
972   MUST NOT ignore any Content-* headers (headers starting with the
973   prefix "Content-") that it does not understand or implement and MUST
974   return a 501 (Not Implemented) response in such cases.
975
976   If the request passes through a cache and the request-target
977   identifies one or more currently cached entities, those entries
978   SHOULD be treated as stale.  Responses to this method are not
979   cacheable.
980
981   The fundamental difference between the POST and PUT requests is
982   reflected in the different meaning of the request-target.  The URI in
983   a POST request identifies the resource that will handle the enclosed
984   entity.  That resource might be a data-accepting process, a gateway
985   to some other protocol, or a separate entity that accepts
986   annotations.  In contrast, the URI in a PUT request identifies the
987   entity enclosed with the request -- the user agent knows what URI is
988   intended and the server MUST NOT attempt to apply the request to some
989   other resource.  If the server desires that the request be applied to
990   a different URI, it MUST send a 301 (Moved Permanently) response; the
991   user agent MAY then make its own decision regarding whether or not to
992   redirect the request.
993
994   A single resource MAY be identified by many different URIs.  For
995   example, an article might have a URI for identifying "the current
996   version" which is separate from the URI identifying each particular
997   version.  In this case, a PUT request on a general URI might result
998   in several other URIs being defined by the origin server.
999
1000   HTTP/1.1 does not define how a PUT method affects the state of an
1001   origin server.
1002
1003   Unless otherwise specified for a particular entity-header, the
1004
1005
1006
1007Fielding, et al.        Expires September 9, 2010              [Page 18]
1008
1009Internet-Draft              HTTP/1.1, Part 2                  March 2010
1010
1011
1012   entity-headers in the PUT request SHOULD be applied to the resource
1013   created or modified by the PUT.
1014
10157.7.  DELETE
1016
1017   The DELETE method requests that the origin server delete the resource
1018   identified by the request-target.  This method MAY be overridden by
1019   human intervention (or other means) on the origin server.  The client
1020   cannot be guaranteed that the operation has been carried out, even if
1021   the status code returned from the origin server indicates that the
1022   action has been completed successfully.  However, the server SHOULD
1023   NOT indicate success unless, at the time the response is given, it
1024   intends to delete the resource or move it to an inaccessible
1025   location.
1026
1027   A successful response SHOULD be 200 (OK) if the response includes an
1028   entity describing the status, 202 (Accepted) if the action has not
1029   yet been enacted, or 204 (No Content) if the action has been enacted
1030   but the response does not include an entity.
1031
1032   If the request passes through a cache and the request-target
1033   identifies one or more currently cached entities, those entries
1034   SHOULD be treated as stale.  Responses to this method are not
1035   cacheable.
1036
10377.8.  TRACE
1038
1039   The TRACE method is used to invoke a remote, application-layer loop-
1040   back of the request message.  The final recipient of the request
1041   SHOULD reflect the message received back to the client as the entity-
1042   body of a 200 (OK) response.  The final recipient is either the
1043   origin server or the first proxy or gateway to receive a Max-Forwards
1044   value of zero (0) in the request (see Section 9.5).  A TRACE request
1045   MUST NOT include an entity.
1046
1047   TRACE allows the client to see what is being received at the other
1048   end of the request chain and use that data for testing or diagnostic
1049   information.  The value of the Via header field (Section 9.9 of
1050   [Part1]) is of particular interest, since it acts as a trace of the
1051   request chain.  Use of the Max-Forwards header field allows the
1052   client to limit the length of the request chain, which is useful for
1053   testing a chain of proxies forwarding messages in an infinite loop.
1054
1055   If the request is valid, the response SHOULD contain the entire
1056   request message in the entity-body, with a Content-Type of "message/
1057   http" (see Section 10.3.1 of [Part1]).  Responses to this method MUST
1058   NOT be cached.
1059
1060
1061
1062
1063Fielding, et al.        Expires September 9, 2010              [Page 19]
1064
1065Internet-Draft              HTTP/1.1, Part 2                  March 2010
1066
1067
10687.9.  CONNECT
1069
1070   This specification reserves the method name CONNECT for use with a
1071   proxy that can dynamically switch to being a tunnel (e.g., SSL
1072   tunneling [RFC2817]).
1073
1074
10758.  Status Code Definitions
1076
1077   Each Status-Code is described below, including any metainformation
1078   required in the response.
1079
10808.1.  Informational 1xx
1081
1082   This class of status code indicates a provisional response,
1083   consisting only of the Status-Line and optional headers, and is
1084   terminated by an empty line.  There are no required headers for this
1085   class of status code.  Since HTTP/1.0 did not define any 1xx status
1086   codes, servers MUST NOT send a 1xx response to an HTTP/1.0 client
1087   except under experimental conditions.
1088
1089   A client MUST be prepared to accept one or more 1xx status responses
1090   prior to a regular response, even if the client does not expect a 100
1091   (Continue) status message.  Unexpected 1xx status responses MAY be
1092   ignored by a user agent.
1093
1094   Proxies MUST forward 1xx responses, unless the connection between the
1095   proxy and its client has been closed, or unless the proxy itself
1096   requested the generation of the 1xx response.  (For example, if a
1097   proxy adds a "Expect: 100-continue" field when it forwards a request,
1098   then it need not forward the corresponding 100 (Continue)
1099   response(s).)
1100
11018.1.1.  100 Continue
1102
1103   The client SHOULD continue with its request.  This interim response
1104   is used to inform the client that the initial part of the request has
1105   been received and has not yet been rejected by the server.  The
1106   client SHOULD continue by sending the remainder of the request or, if
1107   the request has already been completed, ignore this response.  The
1108   server MUST send a final response after the request has been
1109   completed.  See Section 7.2.3 of [Part1] for detailed discussion of
1110   the use and handling of this status code.
1111
11128.1.2.  101 Switching Protocols
1113
1114   The server understands and is willing to comply with the client's
1115   request, via the Upgrade message header field (Section 5.4 of
1116
1117
1118
1119Fielding, et al.        Expires September 9, 2010              [Page 20]
1120
1121Internet-Draft              HTTP/1.1, Part 2                  March 2010
1122
1123
1124   [Part5]), for a change in the application protocol being used on this
1125   connection.  The server will switch protocols to those defined by the
1126   response's Upgrade header field immediately after the empty line
1127   which terminates the 101 response.
1128
1129   The protocol SHOULD be switched only when it is advantageous to do
1130   so.  For example, switching to a newer version of HTTP is
1131   advantageous over older versions, and switching to a real-time,
1132   synchronous protocol might be advantageous when delivering resources
1133   that use such features.
1134
11358.2.  Successful 2xx
1136
1137   This class of status code indicates that the client's request was
1138   successfully received, understood, and accepted.
1139
11408.2.1.  200 OK
1141
1142   The request has succeeded.  The information returned with the
1143   response is dependent on the method used in the request, for example:
1144
1145   GET  an entity corresponding to the requested resource is sent in the
1146      response;
1147
1148   HEAD  the entity-header fields corresponding to the requested
1149      resource are sent in the response without any message-body;
1150
1151   POST  an entity describing or containing the result of the action;
1152
1153   TRACE  an entity containing the request message as received by the
1154      end server.
1155
11568.2.2.  201 Created
1157
1158   The request has been fulfilled and has resulted in a new resource
1159   being created.  The newly created resource can be referenced by the
1160   URI(s) returned in the entity of the response, with the most specific
1161   URI for the resource given by a Location header field.  The response
1162   SHOULD include an entity containing a list of resource
1163   characteristics and location(s) from which the user or user agent can
1164   choose the one most appropriate.  The entity format is specified by
1165   the media type given in the Content-Type header field.  The origin
1166   server MUST create the resource before returning the 201 status code.
1167   If the action cannot be carried out immediately, the server SHOULD
1168   respond with 202 (Accepted) response instead.
1169
1170   A 201 response MAY contain an ETag response header field indicating
1171   the current value of the entity tag for the requested variant just
1172
1173
1174
1175Fielding, et al.        Expires September 9, 2010              [Page 21]
1176
1177Internet-Draft              HTTP/1.1, Part 2                  March 2010
1178
1179
1180   created, see Section 6.1 of [Part4].
1181
11828.2.3.  202 Accepted
1183
1184   The request has been accepted for processing, but the processing has
1185   not been completed.  The request might or might not eventually be
1186   acted upon, as it might be disallowed when processing actually takes
1187   place.  There is no facility for re-sending a status code from an
1188   asynchronous operation such as this.
1189
1190   The 202 response is intentionally non-committal.  Its purpose is to
1191   allow a server to accept a request for some other process (perhaps a
1192   batch-oriented process that is only run once per day) without
1193   requiring that the user agent's connection to the server persist
1194   until the process is completed.  The entity returned with this
1195   response SHOULD include an indication of the request's current status
1196   and either a pointer to a status monitor or some estimate of when the
1197   user can expect the request to be fulfilled.
1198
11998.2.4.  203 Non-Authoritative Information
1200
1201   The returned metainformation in the entity-header is not the
1202   definitive set as available from the origin server, but is gathered
1203   from a local or a third-party copy.  The set presented MAY be a
1204   subset or superset of the original version.  For example, including
1205   local annotation information about the resource might result in a
1206   superset of the metainformation known by the origin server.  Use of
1207   this response code is not required and is only appropriate when the
1208   response would otherwise be 200 (OK).
1209
12108.2.5.  204 No Content
1211
1212   The server has fulfilled the request but does not need to return an
1213   entity-body, and might want to return updated metainformation.  The
1214   response MAY include new or updated metainformation in the form of
1215   entity-headers, which if present SHOULD be associated with the
1216   requested variant.
1217
1218   If the client is a user agent, it SHOULD NOT change its document view
1219   from that which caused the request to be sent.  This response is
1220   primarily intended to allow input for actions to take place without
1221   causing a change to the user agent's active document view, although
1222   any new or updated metainformation SHOULD be applied to the document
1223   currently in the user agent's active view.
1224
1225   The 204 response MUST NOT include a message-body, and thus is always
1226   terminated by the first empty line after the header fields.
1227
1228
1229
1230
1231Fielding, et al.        Expires September 9, 2010              [Page 22]
1232
1233Internet-Draft              HTTP/1.1, Part 2                  March 2010
1234
1235
12368.2.6.  205 Reset Content
1237
1238   The server has fulfilled the request and the user agent SHOULD reset
1239   the document view which caused the request to be sent.  This response
1240   is primarily intended to allow input for actions to take place via
1241   user input, followed by a clearing of the form in which the input is
1242   given so that the user can easily initiate another input action.  The
1243   response MUST NOT include an entity.
1244
12458.2.7.  206 Partial Content
1246
1247   The server has fulfilled the partial GET request for the resource and
1248   the enclosed entity is a partial representation as defined in Section
1249   3.1 of [Part5].
1250
12518.3.  Redirection 3xx
1252
1253   This class of status code indicates that further action needs to be
1254   taken by the user agent in order to fulfill the request.  The action
1255   required MAY be carried out by the user agent without interaction
1256   with the user if and only if the method used in the second request is
1257   known to be "safe", as defined in Section 7.1.1.  A client SHOULD
1258   detect infinite redirection loops, since such loops generate network
1259   traffic for each redirection.
1260
1261      Note: An earlier version of this specification recommended a
1262      maximum of five redirections ([RFC2068], Section 10.3).  Content
1263      developers should be aware that there might be clients that
1264      implement such a fixed limitation.
1265
12668.3.1.  300 Multiple Choices
1267
1268   The requested resource corresponds to any one of a set of
1269   representations, each with its own specific location, and agent-
1270   driven negotiation information (Section 4 of [Part3]) is being
1271   provided so that the user (or user agent) can select a preferred
1272   representation and redirect its request to that location.
1273
1274   Unless it was a HEAD request, the response SHOULD include an entity
1275   containing a list of resource characteristics and location(s) from
1276   which the user or user agent can choose the one most appropriate.
1277   The entity format is specified by the media type given in the
1278   Content-Type header field.  Depending upon the format and the
1279   capabilities of the user agent, selection of the most appropriate
1280   choice MAY be performed automatically.  However, this specification
1281   does not define any standard for such automatic selection.
1282
1283   If the server has a preferred choice of representation, it SHOULD
1284
1285
1286
1287Fielding, et al.        Expires September 9, 2010              [Page 23]
1288
1289Internet-Draft              HTTP/1.1, Part 2                  March 2010
1290
1291
1292   include the specific URI for that representation in the Location
1293   field; user agents MAY use the Location field value for automatic
1294   redirection.  This response is cacheable unless indicated otherwise.
1295
12968.3.2.  301 Moved Permanently
1297
1298   The requested resource has been assigned a new permanent URI and any
1299   future references to this resource SHOULD use one of the returned
1300   URIs.  Clients with link editing capabilities ought to automatically
1301   re-link references to the request-target to one or more of the new
1302   references returned by the server, where possible.  This response is
1303   cacheable unless indicated otherwise.
1304
1305   The new permanent URI SHOULD be given by the Location field in the
1306   response.  Unless the request method was HEAD, the entity of the
1307   response SHOULD contain a short hypertext note with a hyperlink to
1308   the new URI(s).
1309
1310   If the 301 status code is received in response to a request method
1311   that is known to be "safe", as defined in Section 7.1.1, then the
1312   request MAY be automatically redirected by the user agent without
1313   confirmation.  Otherwise, the user agent MUST NOT automatically
1314   redirect the request unless it can be confirmed by the user, since
1315   this might change the conditions under which the request was issued.
1316
1317      Note: When automatically redirecting a POST request after
1318      receiving a 301 status code, some existing HTTP/1.0 user agents
1319      will erroneously change it into a GET request.
1320
13218.3.3.  302 Found
1322
1323   The requested resource resides temporarily under a different URI.
1324   Since the redirection might be altered on occasion, the client SHOULD
1325   continue to use the request-target for future requests.  This
1326   response is only cacheable if indicated by a Cache-Control or Expires
1327   header 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).
1333
1334   If the 302 status code is received in response to a request method
1335   that is known to be "safe", as defined in Section 7.1.1, then the
1336   request MAY be automatically redirected by the user agent without
1337   confirmation.  Otherwise, the user agent MUST NOT automatically
1338   redirect the request unless it can be confirmed by the user, since
1339   this might change the conditions under which the request was issued.
1340
1341
1342
1343Fielding, et al.        Expires September 9, 2010              [Page 24]
1344
1345Internet-Draft              HTTP/1.1, Part 2                  March 2010
1346
1347
1348      Note: HTTP/1.0 ([RFC1945], Section 9.3) and the first version of
1349      HTTP/1.1 ([RFC2068], Section 10.3.3) specify that the client is
1350      not allowed to change the method on the redirected request.
1351      However, most existing user agent implementations treat 302 as if
1352      it were a 303 response, performing a GET on the Location field-
1353      value regardless of the original request method.  Therefore, a
1354      previous version of this specification ([RFC2616], Section 10.3.3)
1355      has added the status codes 303 and 307 for servers that wish to
1356      make unambiguously clear which kind of reaction is expected of the
1357      client.
1358
13598.3.4.  303 See Other
1360
1361   The server directs the user agent to a different resource, indicated
1362   by a URI in the Location header field, that provides an indirect
1363   response to the original request.  The user agent MAY perform a GET
1364   request on the URI in the Location field in order to obtain a
1365   representation corresponding to the response, be redirected again, or
1366   end with an error status.  The Location URI is not a substitute
1367   reference for the originally requested resource.
1368
1369   The 303 status is generally applicable to any HTTP method.  It is
1370   primarily used to allow the output of a POST action to redirect the
1371   user agent to a selected resource, since doing so provides the
1372   information corresponding to the POST response in a form that can be
1373   separately identified, bookmarked, and cached independent of the
1374   original request.
1375
1376   A 303 response to a GET request indicates that the requested resource
1377   does not have a representation of its own that can be transferred by
1378   the server over HTTP.  The Location URI indicates a resource that is
1379   descriptive of the requested resource such that the follow-on
1380   representation may be useful without implying that it adequately
1381   represents the previously requested resource.  Note that answers to
1382   the questions of what can be represented, what representations are
1383   adequate, and what might be a useful description are outside the
1384   scope of HTTP and thus entirely determined by the URI owner(s).
1385
1386   A 303 response SHOULD NOT be cached unless it is indicated as
1387   cacheable by Cache-Control or Expires header fields.  Except for
1388   responses to a HEAD request, the entity of a 303 response SHOULD
1389   contain a short hypertext note with a hyperlink to the Location URI.
1390
13918.3.5.  304 Not Modified
1392
1393   The response to the request has not been modified since the
1394   conditions indicated by the client's conditional GET request, as
1395   defined in Section 3.1 of [Part4].
1396
1397
1398
1399Fielding, et al.        Expires September 9, 2010              [Page 25]
1400
1401Internet-Draft              HTTP/1.1, Part 2                  March 2010
1402
1403
14048.3.6.  305 Use Proxy
1405
1406   The 305 status was defined in a previous version of this
1407   specification (see Appendix A.2), and is now deprecated.
1408
14098.3.7.  306 (Unused)
1410
1411   The 306 status code was used in a previous version of the
1412   specification, is no longer used, and the code is reserved.
1413
14148.3.8.  307 Temporary Redirect
1415
1416   The requested resource resides temporarily under a different URI.
1417   Since the redirection MAY be altered on occasion, the client SHOULD
1418   continue to use the request-target for future requests.  This
1419   response is only cacheable if indicated by a Cache-Control or Expires
1420   header field.
1421
1422   The temporary URI SHOULD be given by the Location field in the
1423   response.  Unless the request method was HEAD, the entity of the
1424   response SHOULD contain a short hypertext note with a hyperlink to
1425   the new URI(s) , since many pre-HTTP/1.1 user agents do not
1426   understand the 307 status.  Therefore, the note SHOULD contain the
1427   information necessary for a user to repeat the original request on
1428   the new URI.
1429
1430   If the 307 status code is received in response to a request method
1431   that is known to be "safe", as defined in Section 7.1.1, then the
1432   request MAY be automatically redirected by the user agent without
1433   confirmation.  Otherwise, the user agent MUST NOT automatically
1434   redirect the request unless it can be confirmed by the user, since
1435   this might change the conditions under which the request was issued.
1436
14378.4.  Client Error 4xx
1438
1439   The 4xx class of status code is intended for cases in which the
1440   client seems to have erred.  Except when responding to a HEAD
1441   request, the server SHOULD include an entity containing an
1442   explanation of the error situation, and whether it is a temporary or
1443   permanent condition.  These status codes are applicable to any
1444   request method.  User agents SHOULD display any included entity to
1445   the user.
1446
1447   If the client is sending data, a server implementation using TCP
1448   SHOULD be careful to ensure that the client acknowledges receipt of
1449   the packet(s) containing the response, before the server closes the
1450   input connection.  If the client continues sending data to the server
1451   after the close, the server's TCP stack will send a reset packet to
1452
1453
1454
1455Fielding, et al.        Expires September 9, 2010              [Page 26]
1456
1457Internet-Draft              HTTP/1.1, Part 2                  March 2010
1458
1459
1460   the client, which may erase the client's unacknowledged input buffers
1461   before they can be read and interpreted by the HTTP application.
1462
14638.4.1.  400 Bad Request
1464
1465   The request could not be understood by the server due to malformed
1466   syntax.  The client SHOULD NOT repeat the request without
1467   modifications.
1468
14698.4.2.  401 Unauthorized
1470
1471   The request requires user authentication (see Section 2.1 of
1472   [Part7]).
1473
14748.4.3.  402 Payment Required
1475
1476   This code is reserved for future use.
1477
14788.4.4.  403 Forbidden
1479
1480   The server understood the request, but is refusing to fulfill it.
1481   Authorization will not help and the request SHOULD NOT be repeated.
1482   If the request method was not HEAD and the server wishes to make
1483   public why the request has not been fulfilled, it SHOULD describe the
1484   reason for the refusal in the entity.  If the server does not wish to
1485   make this information available to the client, the status code 404
1486   (Not Found) can be used instead.
1487
14888.4.5.  404 Not Found
1489
1490   The server has not found anything matching the request-target.  No
1491   indication is given of whether the condition is temporary or
1492   permanent.  The 410 (Gone) status code SHOULD be used if the server
1493   knows, through some internally configurable mechanism, that an old
1494   resource is permanently unavailable and has no forwarding address.
1495   This status code is commonly used when the server does not wish to
1496   reveal exactly why the request has been refused, or when no other
1497   response is applicable.
1498
14998.4.6.  405 Method Not Allowed
1500
1501   The method specified in the Request-Line is not allowed for the
1502   resource identified by the request-target.  The response MUST include
1503   an Allow header containing a list of valid methods for the requested
1504   resource.
1505
1506
1507
1508
1509
1510
1511Fielding, et al.        Expires September 9, 2010              [Page 27]
1512
1513Internet-Draft              HTTP/1.1, Part 2                  March 2010
1514
1515
15168.4.7.  406 Not Acceptable
1517
1518   The resource identified by the request is only capable of generating
1519   response entities which have content characteristics not acceptable
1520   according to the accept headers sent in the request.
1521
1522   Unless it was a HEAD request, the response SHOULD include an entity
1523   containing a list of available entity characteristics and location(s)
1524   from which the user or user agent can choose the one most
1525   appropriate.  The entity format is specified by the media type given
1526   in the Content-Type header field.  Depending upon the format and the
1527   capabilities of the user agent, selection of the most appropriate
1528   choice MAY be performed automatically.  However, this specification
1529   does not define any standard for such automatic selection.
1530
1531      Note: HTTP/1.1 servers are allowed to return responses which are
1532      not acceptable according to the accept headers sent in the
1533      request.  In some cases, this may even be preferable to sending a
1534      406 response.  User agents are encouraged to inspect the headers
1535      of an incoming response to determine if it is acceptable.
1536
1537   If the response could be unacceptable, a user agent SHOULD
1538   temporarily stop receipt of more data and query the user for a
1539   decision on further actions.
1540
15418.4.8.  407 Proxy Authentication Required
1542
1543   This code is similar to 401 (Unauthorized), but indicates that the
1544   client must first authenticate itself with the proxy (see Section 2.2
1545   of [Part7]).
1546
15478.4.9.  408 Request Timeout
1548
1549   The client did not produce a request within the time that the server
1550   was prepared to wait.  The client MAY repeat the request without
1551   modifications at any later time.
1552
15538.4.10.  409 Conflict
1554
1555   The request could not be completed due to a conflict with the current
1556   state of the resource.  This code is only allowed in situations where
1557   it is expected that the user might be able to resolve the conflict
1558   and resubmit the request.  The response body SHOULD include enough
1559   information for the user to recognize the source of the conflict.
1560   Ideally, the response entity would include enough information for the
1561   user or user agent to fix the problem; however, that might not be
1562   possible and is not required.
1563
1564
1565
1566
1567Fielding, et al.        Expires September 9, 2010              [Page 28]
1568
1569Internet-Draft              HTTP/1.1, Part 2                  March 2010
1570
1571
1572   Conflicts are most likely to occur in response to a PUT request.  For
1573   example, if versioning were being used and the entity being PUT
1574   included changes to a resource which conflict with those made by an
1575   earlier (third-party) request, the server might use the 409 response
1576   to indicate that it can't complete the request.  In this case, the
1577   response entity would likely contain a list of the differences
1578   between the two versions in a format defined by the response Content-
1579   Type.
1580
15818.4.11.  410 Gone
1582
1583   The requested resource is no longer available at the server and no
1584   forwarding address is known.  This condition is expected to be
1585   considered permanent.  Clients with link editing capabilities SHOULD
1586   delete references to the request-target after user approval.  If the
1587   server does not know, or has no facility to determine, whether or not
1588   the condition is permanent, the status code 404 (Not Found) SHOULD be
1589   used instead.  This response is cacheable unless indicated otherwise.
1590
1591   The 410 response is primarily intended to assist the task of web
1592   maintenance by notifying the recipient that the resource is
1593   intentionally unavailable and that the server owners desire that
1594   remote links to that resource be removed.  Such an event is common
1595   for limited-time, promotional services and for resources belonging to
1596   individuals no longer working at the server's site.  It is not
1597   necessary to mark all permanently unavailable resources as "gone" or
1598   to keep the mark for any length of time -- that is left to the
1599   discretion of the server owner.
1600
16018.4.12.  411 Length Required
1602
1603   The server refuses to accept the request without a defined Content-
1604   Length.  The client MAY repeat the request if it adds a valid
1605   Content-Length header field containing the length of the message-body
1606   in the request message.
1607
16088.4.13.  412 Precondition Failed
1609
1610   The precondition given in one or more of the request-header fields
1611   evaluated to false when it was tested on the server, as defined in
1612   Section 3.2 of [Part4].
1613
16148.4.14.  413 Request Entity Too Large
1615
1616   The server is refusing to process a request because the request
1617   entity is larger than the server is willing or able to process.  The
1618   server MAY close the connection to prevent the client from continuing
1619   the request.
1620
1621
1622
1623Fielding, et al.        Expires September 9, 2010              [Page 29]
1624
1625Internet-Draft              HTTP/1.1, Part 2                  March 2010
1626
1627
1628   If the condition is temporary, the server SHOULD include a Retry-
1629   After header field to indicate that it is temporary and after what
1630   time the client MAY try again.
1631
16328.4.15.  414 URI Too Long
1633
1634   The server is refusing to service the request because the request-
1635   target is longer than the server is willing to interpret.  This rare
1636   condition is only likely to occur when a client has improperly
1637   converted a POST request to a GET request with long query
1638   information, when the client has descended into a URI "black hole" of
1639   redirection (e.g., a redirected URI prefix that points to a suffix of
1640   itself), or when the server is under attack by a client attempting to
1641   exploit security holes present in some servers using fixed-length
1642   buffers for reading or manipulating the request-target.
1643
16448.4.16.  415 Unsupported Media Type
1645
1646   The server is refusing to service the request because the entity of
1647   the request is in a format not supported by the requested resource
1648   for the requested method.
1649
16508.4.17.  416 Requested Range Not Satisfiable
1651
1652   The request included a Range request-header field (Section 5.4 of
1653   [Part5]) and none of the range-specifier values in this field overlap
1654   the current extent of the selected resource.  See Section 3.2 of
1655   [Part5]
1656
16578.4.18.  417 Expectation Failed
1658
1659   The expectation given in an Expect request-header field (see
1660   Section 9.2) could not be met by this server, or, if the server is a
1661   proxy, the server has unambiguous evidence that the request could not
1662   be met by the next-hop server.
1663
16648.5.  Server Error 5xx
1665
1666   Response status codes beginning with the digit "5" indicate cases in
1667   which the server is aware that it has erred or is incapable of
1668   performing the request.  Except when responding to a HEAD request,
1669   the server SHOULD include an entity containing an explanation of the
1670   error situation, and whether it is a temporary or permanent
1671   condition.  User agents SHOULD display any included entity to the
1672   user.  These response codes are applicable to any request method.
1673
1674
1675
1676
1677
1678
1679Fielding, et al.        Expires September 9, 2010              [Page 30]
1680
1681Internet-Draft              HTTP/1.1, Part 2                  March 2010
1682
1683
16848.5.1.  500 Internal Server Error
1685
1686   The server encountered an unexpected condition which prevented it
1687   from fulfilling the request.
1688
16898.5.2.  501 Not Implemented
1690
1691   The server does not support the functionality required to fulfill the
1692   request.  This is the appropriate response when the server does not
1693   recognize the request method and is not capable of supporting it for
1694   any resource.
1695
16968.5.3.  502 Bad Gateway
1697
1698   The server, while acting as a gateway or proxy, received an invalid
1699   response from the upstream server it accessed in attempting to
1700   fulfill the request.
1701
17028.5.4.  503 Service Unavailable
1703
1704   The server is currently unable to handle the request due to a
1705   temporary overloading or maintenance of the server.  The implication
1706   is that this is a temporary condition which will be alleviated after
1707   some delay.  If known, the length of the delay MAY be indicated in a
1708   Retry-After header.  If no Retry-After is given, the client SHOULD
1709   handle the response as it would for a 500 response.
1710
1711      Note: The existence of the 503 status code does not imply that a
1712      server must use it when becoming overloaded.  Some servers may
1713      wish to simply refuse the connection.
1714
17158.5.5.  504 Gateway Timeout
1716
1717   The server, while acting as a gateway or proxy, did not receive a
1718   timely response from the upstream server specified by the URI (e.g.,
1719   HTTP, FTP, LDAP) or some other auxiliary server (e.g., DNS) it needed
1720   to access in attempting to complete the request.
1721
1722      Note to implementors: some deployed proxies are known to return
1723      400 or 500 when DNS lookups time out.
1724
17258.5.6.  505 HTTP Version Not Supported
1726
1727   The server does not support, or refuses to support, the protocol
1728   version that was used in the request message.  The server is
1729   indicating that it is unable or unwilling to complete the request
1730   using the same major version as the client, as described in Section
1731   2.5 of [Part1], other than with this error message.  The response
1732
1733
1734
1735Fielding, et al.        Expires September 9, 2010              [Page 31]
1736
1737Internet-Draft              HTTP/1.1, Part 2                  March 2010
1738
1739
1740   SHOULD contain an entity describing why that version is not supported
1741   and what other protocols are supported by that server.
1742
1743
17449.  Header Field Definitions
1745
1746   This section defines the syntax and semantics of HTTP/1.1 header
1747   fields related to request and response semantics.
1748
1749   For entity-header fields, both sender and recipient refer to either
1750   the client or the server, depending on who sends and who receives the
1751   entity.
1752
17539.1.  Allow
1754
1755   The "Allow" response-header field lists the set of methods advertised
1756   as supported by the resource identified by the request-target.  The
1757   purpose of this field is strictly to inform the recipient of valid
1758   methods associated with the resource.
1759
1760     Allow   = "Allow" ":" OWS Allow-v
1761     Allow-v = #Method
1762
1763   Example of use:
1764
1765     Allow: GET, HEAD, PUT
1766
1767   The actual set of allowed methods is defined by the origin server at
1768   the time of each request.
1769
1770   A proxy MUST NOT modify the Allow header field even if it does not
1771   understand all the methods specified, since the user agent might have
1772   other means of communicating with the origin server.
1773
17749.2.  Expect
1775
1776   The "Expect" request-header field is used to indicate that particular
1777   server behaviors are required by the client.
1778
1779     Expect       = "Expect" ":" OWS Expect-v
1780     Expect-v     = 1#expectation
1781
1782     expectation  = "100-continue" / expectation-extension
1783     expectation-extension = token [ "=" ( token / quoted-string )
1784                              *expect-params ]
1785     expect-params = ";" token [ "=" ( token / quoted-string ) ]
1786
1787   A server that does not understand or is unable to comply with any of
1788
1789
1790
1791Fielding, et al.        Expires September 9, 2010              [Page 32]
1792
1793Internet-Draft              HTTP/1.1, Part 2                  March 2010
1794
1795
1796   the expectation values in the Expect field of a request MUST respond
1797   with appropriate error status.  The server MUST respond with a 417
1798   (Expectation Failed) status if any of the expectations cannot be met
1799   or, if there are other problems with the request, some other 4xx
1800   status.
1801
1802   This header field is defined with extensible syntax to allow for
1803   future extensions.  If a server receives a request containing an
1804   Expect field that includes an expectation-extension that it does not
1805   support, it MUST respond with a 417 (Expectation Failed) status.
1806
1807   Comparison of expectation values is case-insensitive for unquoted
1808   tokens (including the 100-continue token), and is case-sensitive for
1809   quoted-string expectation-extensions.
1810
1811   The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy MUST
1812   return a 417 (Expectation Failed) status if it receives a request
1813   with an expectation that it cannot meet.  However, the Expect
1814   request-header itself is end-to-end; it MUST be forwarded if the
1815   request is forwarded.
1816
1817   Many older HTTP/1.0 and HTTP/1.1 applications do not understand the
1818   Expect header.
1819
1820   See Section 7.2.3 of [Part1] for the use of the 100 (Continue)
1821   status.
1822
18239.3.  From
1824
1825   The "From" request-header field, if given, SHOULD contain an Internet
1826   e-mail address for the human user who controls the requesting user
1827   agent.  The address SHOULD be machine-usable, as defined by "mailbox"
1828   in Section 3.4 of [RFC5322]:
1829
1830     From    = "From" ":" OWS From-v
1831     From-v  = mailbox
1832
1833     mailbox = <mailbox, defined in [RFC5322], Section 3.4>
1834
1835   An example is:
1836
1837     From: webmaster@example.org
1838
1839   This header field MAY be used for logging purposes and as a means for
1840   identifying the source of invalid or unwanted requests.  It SHOULD
1841   NOT be used as an insecure form of access protection.  The
1842   interpretation of this field is that the request is being performed
1843   on behalf of the person given, who accepts responsibility for the
1844
1845
1846
1847Fielding, et al.        Expires September 9, 2010              [Page 33]
1848
1849Internet-Draft              HTTP/1.1, Part 2                  March 2010
1850
1851
1852   method performed.  In particular, robot agents SHOULD include this
1853   header so that the person responsible for running the robot can be
1854   contacted if problems occur on the receiving end.
1855
1856   The Internet e-mail address in this field MAY be separate from the
1857   Internet host which issued the request.  For example, when a request
1858   is passed through a proxy the original issuer's address SHOULD be
1859   used.
1860
1861   The client SHOULD NOT send the From header field without the user's
1862   approval, as it might conflict with the user's privacy interests or
1863   their site's security policy.  It is strongly recommended that the
1864   user be able to disable, enable, and modify the value of this field
1865   at any time prior to a request.
1866
18679.4.  Location
1868
1869   The "Location" response-header field is used to identify a newly
1870   created resource, or to redirect the recipient to a different
1871   location for completion of the request.
1872
1873   For 201 (Created) responses, the Location is the URI of the new
1874   resource which was created by the request.  For 3xx responses, the
1875   location SHOULD indicate the server's preferred URI for automatic
1876   redirection to the resource.
1877
1878   The field value consists of a single URI.
1879
1880     Location       = "Location" ":" OWS Location-v
1881     Location-v     = URI
1882
1883   An example is:
1884
1885     Location: http://www.example.org/pub/WWW/People.html
1886
1887   There are circumstances in which a fragment identifier in a Location
1888   URI would not be appropriate:
1889
1890   o  With a 201 Created response, because in this usage the Location
1891      header specifies the URI for the entire created resource.
1892
1893   o  With 305 Use Proxy.
1894
1895      Note: The Content-Location header field (Section 5.7 of [Part3])
1896      differs from Location in that the Content-Location identifies the
1897      original location of the entity enclosed in the response.  It is
1898      therefore possible for a response to contain header fields for
1899      both Location and Content-Location.
1900
1901
1902
1903Fielding, et al.        Expires September 9, 2010              [Page 34]
1904
1905Internet-Draft              HTTP/1.1, Part 2                  March 2010
1906
1907
19089.5.  Max-Forwards
1909
1910   The "Max-Forwards" request-header field provides a mechanism with the
1911   TRACE (Section 7.8) and OPTIONS (Section 7.2) methods to limit the
1912   number of times that the request is forwarded by proxies or gateways.
1913   This can be useful when the client is attempting to trace a request
1914   which appears to be failing or looping in mid-chain.
1915
1916     Max-Forwards   = "Max-Forwards" ":" OWS Max-Forwards-v
1917     Max-Forwards-v = 1*DIGIT
1918
1919   The Max-Forwards value is a decimal integer indicating the remaining
1920   number of times this request message may be forwarded.
1921
1922   Each proxy or gateway recipient of a TRACE or OPTIONS request
1923   containing a Max-Forwards header field MUST check and update its
1924   value prior to forwarding the request.  If the received value is zero
1925   (0), the recipient MUST NOT forward the request; instead, it MUST
1926   respond as the final recipient.  If the received Max-Forwards value
1927   is greater than zero, then the forwarded message MUST contain an
1928   updated Max-Forwards field with a value decremented by one (1).
1929
1930   The Max-Forwards header field MAY be ignored for all other methods
1931   defined by this specification and for any extension methods for which
1932   it is not explicitly referred to as part of that method definition.
1933
19349.6.  Referer
1935
1936   The "Referer" [sic] request-header field allows the client to specify
1937   the URI of the resource from which the request-target was obtained
1938   (the "referrer", although the header field is misspelled.).
1939
1940   The Referer header allows servers to generate lists of back-links to
1941   resources for interest, logging, optimized caching, etc.  It also
1942   allows obsolete or mistyped links to be traced for maintenance.  Some
1943   servers use Referer as a means of controlling where they allow links
1944   from (so-called "deep linking"), but it should be noted that
1945   legitimate requests are not required to contain a Referer header
1946   field.
1947
1948   If the request-target was obtained from a source that does not have
1949   its own URI (e.g., input from the user keyboard), the Referer field
1950   MUST either be sent with the value "about:blank", or not be sent at
1951   all.  Note that this requirement does not apply to sources with non-
1952   HTTP URIs (e.g., FTP).
1953
1954     Referer        = "Referer" ":" OWS Referer-v
1955     Referer-v      = absolute-URI / partial-URI
1956
1957
1958
1959Fielding, et al.        Expires September 9, 2010              [Page 35]
1960
1961Internet-Draft              HTTP/1.1, Part 2                  March 2010
1962
1963
1964   Example:
1965
1966     Referer: http://www.example.org/hypertext/Overview.html
1967
1968   If the field value is a relative URI, it SHOULD be interpreted
1969   relative to the request-target.  The URI MUST NOT include a fragment.
1970   See Section 11.2 for security considerations.
1971
19729.7.  Retry-After
1973
1974   The response-header "Retry-After" field can be used with a 503
1975   (Service Unavailable) response to indicate how long the service is
1976   expected to be unavailable to the requesting client.  This field MAY
1977   also be used with any 3xx (Redirection) response to indicate the
1978   minimum time the user-agent is asked wait before issuing the
1979   redirected request.
1980
1981   The value of this field can be either an HTTP-date or an integer
1982   number of seconds (in decimal) after the time of the response.
1983
1984     Retry-After   = "Retry-After" ":" OWS Retry-After-v
1985     Retry-After-v = HTTP-date / delta-seconds
1986
1987   Time spans are non-negative decimal integers, representing time in
1988   seconds.
1989
1990     delta-seconds  = 1*DIGIT
1991
1992   Two examples of its use are
1993
1994     Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
1995     Retry-After: 120
1996
1997   In the latter example, the delay is 2 minutes.
1998
19999.8.  Server
2000
2001   The "Server" response-header field contains information about the
2002   software used by the origin server to handle the request.
2003
2004   The field can contain multiple product tokens (Section 6.3 of
2005   [Part1]) and comments (Section 3.2 of [Part1]) identifying the server
2006   and any significant subproducts.  The product tokens are listed in
2007   order of their significance for identifying the application.
2008
2009     Server         = "Server" ":" OWS Server-v
2010     Server-v       = product
2011                      *( RWS ( product / comment ) )
2012
2013
2014
2015Fielding, et al.        Expires September 9, 2010              [Page 36]
2016
2017Internet-Draft              HTTP/1.1, Part 2                  March 2010
2018
2019
2020   Example:
2021
2022     Server: CERN/3.0 libwww/2.17
2023
2024   If the response is being forwarded through a proxy, the proxy
2025   application MUST NOT modify the Server response-header.  Instead, it
2026   MUST include a Via field (as described in Section 9.9 of [Part1]).
2027
2028      Note: Revealing the specific software version of the server might
2029      allow the server machine to become more vulnerable to attacks
2030      against software that is known to contain security holes.  Server
2031      implementors are encouraged to make this field a configurable
2032      option.
2033
20349.9.  User-Agent
2035
2036   The "User-Agent" request-header field contains information about the
2037   user agent originating the request.  This is for statistical
2038   purposes, the tracing of protocol violations, and automated
2039   recognition of user agents for the sake of tailoring responses to
2040   avoid particular user agent limitations.
2041
2042   User agents SHOULD include this field with requests.  The field can
2043   contain multiple product tokens (Section 6.3 of [Part1]) and comments
2044   (Section 3.2 of [Part1]) identifying the agent and any subproducts
2045   which form a significant part of the user agent.  By convention, the
2046   product tokens are listed in order of their significance for
2047   identifying the application.
2048
2049     User-Agent     = "User-Agent" ":" OWS User-Agent-v
2050     User-Agent-v   = product
2051                      *( RWS ( product / comment ) )
2052
2053   Example:
2054
2055     User-Agent: CERN-LineMode/2.15 libwww/2.17b3
2056
2057
205810.  IANA Considerations
2059
206010.1.  Method Registry
2061
2062   The registration procedure for HTTP Methods is defined by Section 2.1
2063   of this document.
2064
2065   The HTTP Method Registry located at
2066   <http://www.iana.org/assignments/http-methods> should be populated
2067   with the registrations below:
2068
2069
2070
2071Fielding, et al.        Expires September 9, 2010              [Page 37]
2072
2073Internet-Draft              HTTP/1.1, Part 2                  March 2010
2074
2075
2076   +---------+------+-------------+
2077   | Method  | Safe | Reference   |
2078   +---------+------+-------------+
2079   | CONNECT | no   | Section 7.9 |
2080   | DELETE  | no   | Section 7.7 |
2081   | GET     | yes  | Section 7.3 |
2082   | HEAD    | yes  | Section 7.4 |
2083   | OPTIONS | yes  | Section 7.2 |
2084   | POST    | no   | Section 7.5 |
2085   | PUT     | no   | Section 7.6 |
2086   | TRACE   | yes  | Section 7.8 |
2087   +---------+------+-------------+
2088
208910.2.  Status Code Registry
2090
2091   The registration procedure for HTTP Status Codes -- previously
2092   defined in Section 7.1 of [RFC2817] -- is now defined by Section 4.1
2093   of this document.
2094
2095   The HTTP Status Code Registry located at
2096   <http://www.iana.org/assignments/http-status-codes> should be updated
2097   with the registrations below:
2098
2099
2100
2101
2102
2103
2104
2105
2106
2107
2108
2109
2110
2111
2112
2113
2114
2115
2116
2117
2118
2119
2120
2121
2122
2123
2124
2125
2126
2127Fielding, et al.        Expires September 9, 2010              [Page 38]
2128
2129Internet-Draft              HTTP/1.1, Part 2                  March 2010
2130
2131
2132   +-------+-------------------------------+----------------+
2133   | Value | Description                   | Reference      |
2134   +-------+-------------------------------+----------------+
2135   | 100   | Continue                      | Section 8.1.1  |
2136   | 101   | Switching Protocols           | Section 8.1.2  |
2137   | 200   | OK                            | Section 8.2.1  |
2138   | 201   | Created                       | Section 8.2.2  |
2139   | 202   | Accepted                      | Section 8.2.3  |
2140   | 203   | Non-Authoritative Information | Section 8.2.4  |
2141   | 204   | No Content                    | Section 8.2.5  |
2142   | 205   | Reset Content                 | Section 8.2.6  |
2143   | 300   | Multiple Choices              | Section 8.3.1  |
2144   | 301   | Moved Permanently             | Section 8.3.2  |
2145   | 302   | Found                         | Section 8.3.3  |
2146   | 303   | See Other                     | Section 8.3.4  |
2147   | 305   | Use Proxy                     | Section 8.3.6  |
2148   | 306   | (Unused)                      | Section 8.3.7  |
2149   | 307   | Temporary Redirect            | Section 8.3.8  |
2150   | 400   | Bad Request                   | Section 8.4.1  |
2151   | 402   | Payment Required              | Section 8.4.3  |
2152   | 403   | Forbidden                     | Section 8.4.4  |
2153   | 404   | Not Found                     | Section 8.4.5  |
2154   | 405   | Method Not Allowed            | Section 8.4.6  |
2155   | 406   | Not Acceptable                | Section 8.4.7  |
2156   | 407   | Proxy Authentication Required | Section 8.4.8  |
2157   | 408   | Request Timeout               | Section 8.4.9  |
2158   | 409   | Conflict                      | Section 8.4.10 |
2159   | 410   | Gone                          | Section 8.4.11 |
2160   | 411   | Length Required               | Section 8.4.12 |
2161   | 413   | Request Entity Too Large      | Section 8.4.14 |
2162   | 414   | URI Too Long                  | Section 8.4.15 |
2163   | 415   | Unsupported Media Type        | Section 8.4.16 |
2164   | 417   | Expectation Failed            | Section 8.4.18 |
2165   | 500   | Internal Server Error         | Section 8.5.1  |
2166   | 501   | Not Implemented               | Section 8.5.2  |
2167   | 502   | Bad Gateway                   | Section 8.5.3  |
2168   | 503   | Service Unavailable           | Section 8.5.4  |
2169   | 504   | Gateway Timeout               | Section 8.5.5  |
2170   | 505   | HTTP Version Not Supported    | Section 8.5.6  |
2171   +-------+-------------------------------+----------------+
2172
217310.3.  Message Header Registration
2174
2175   The Message Header Registry located at <http://www.iana.org/
2176   assignments/message-headers/message-header-index.html> should be
2177   updated with the permanent registrations below (see [RFC3864]):
2178
2179
2180
2181
2182
2183Fielding, et al.        Expires September 9, 2010              [Page 39]
2184
2185Internet-Draft              HTTP/1.1, Part 2                  March 2010
2186
2187
2188   +-------------------+----------+----------+-------------+
2189   | Header Field Name | Protocol | Status   | Reference   |
2190   +-------------------+----------+----------+-------------+
2191   | Allow             | http     | standard | Section 9.1 |
2192   | Expect            | http     | standard | Section 9.2 |
2193   | From              | http     | standard | Section 9.3 |
2194   | Location          | http     | standard | Section 9.4 |
2195   | Max-Forwards      | http     | standard | Section 9.5 |
2196   | Referer           | http     | standard | Section 9.6 |
2197   | Retry-After       | http     | standard | Section 9.7 |
2198   | Server            | http     | standard | Section 9.8 |
2199   | User-Agent        | http     | standard | Section 9.9 |
2200   +-------------------+----------+----------+-------------+
2201
2202   The change controller is: "IETF (iesg@ietf.org) - Internet
2203   Engineering Task Force".
2204
2205
220611.  Security Considerations
2207
2208   This section is meant to inform application developers, information
2209   providers, and users of the security limitations in HTTP/1.1 as
2210   described by this document.  The discussion does not include
2211   definitive solutions to the problems revealed, though it does make
2212   some suggestions for reducing security risks.
2213
221411.1.  Transfer of Sensitive Information
2215
2216   Like any generic data transfer protocol, HTTP cannot regulate the
2217   content of the data that is transferred, nor is there any a priori
2218   method of determining the sensitivity of any particular piece of
2219   information within the context of any given request.  Therefore,
2220   applications SHOULD supply as much control over this information as
2221   possible to the provider of that information.  Four header fields are
2222   worth special mention in this context: Server, Via, Referer and From.
2223
2224   Revealing the specific software version of the server might allow the
2225   server machine to become more vulnerable to attacks against software
2226   that is known to contain security holes.  Implementors SHOULD make
2227   the Server header field a configurable option.
2228
2229   Proxies which serve as a portal through a network firewall SHOULD
2230   take special precautions regarding the transfer of header information
2231   that identifies the hosts behind the firewall.  In particular, they
2232   SHOULD remove, or replace with sanitized versions, any Via fields
2233   generated behind the firewall.
2234
2235   The Referer header allows reading patterns to be studied and reverse
2236
2237
2238
2239Fielding, et al.        Expires September 9, 2010              [Page 40]
2240
2241Internet-Draft              HTTP/1.1, Part 2                  March 2010
2242
2243
2244   links drawn.  Although it can be very useful, its power can be abused
2245   if user details are not separated from the information contained in
2246   the Referer.  Even when the personal information has been removed,
2247   the Referer header might indicate a private document's URI whose
2248   publication would be inappropriate.
2249
2250   The information sent in the From field might conflict with the user's
2251   privacy interests or their site's security policy, and hence it
2252   SHOULD NOT be transmitted without the user being able to disable,
2253   enable, and modify the contents of the field.  The user MUST be able
2254   to set the contents of this field within a user preference or
2255   application defaults configuration.
2256
2257   We suggest, though do not require, that a convenient toggle interface
2258   be provided for the user to enable or disable the sending of From and
2259   Referer information.
2260
2261   The User-Agent (Section 9.9) or Server (Section 9.8) header fields
2262   can sometimes be used to determine that a specific client or server
2263   have a particular security hole which might be exploited.
2264   Unfortunately, this same information is often used for other valuable
2265   purposes for which HTTP currently has no better mechanism.
2266
2267   Some methods, like TRACE (Section 7.8) may expose information sent in
2268   request headers in the response entity.  Clients SHOULD be careful
2269   with sensitive information, like Cookies, Authorization credentials
2270   and other headers that might be used to collect data from the client.
2271
227211.2.  Encoding Sensitive Information in URIs
2273
2274   Because the source of a link might be private information or might
2275   reveal an otherwise private information source, it is strongly
2276   recommended that the user be able to select whether or not the
2277   Referer field is sent.  For example, a browser client could have a
2278   toggle switch for browsing openly/anonymously, which would
2279   respectively enable/disable the sending of Referer and From
2280   information.
2281
2282   Clients SHOULD NOT include a Referer header field in a (non-secure)
2283   HTTP request if the referring page was transferred with a secure
2284   protocol.
2285
2286   Authors of services should not use GET-based forms for the submission
2287   of sensitive data because that data will be encoded in the Request-
2288   target.  Many existing servers, proxies, and user agents log or
2289   display the Request-target in places where it might be visible to
2290   third parties.  Such services can use POST-based form submission
2291   instead.
2292
2293
2294
2295Fielding, et al.        Expires September 9, 2010              [Page 41]
2296
2297Internet-Draft              HTTP/1.1, Part 2                  March 2010
2298
2299
230011.3.  Location Headers and Spoofing
2301
2302   If a single server supports multiple organizations that do not trust
2303   one another, then it MUST check the values of Location and Content-
2304   Location headers in responses that are generated under control of
2305   said organizations to make sure that they do not attempt to
2306   invalidate resources over which they have no authority.
2307
2308
230912.  Acknowledgments
2310
2311
231213.  References
2313
231413.1.  Normative References
2315
2316   [Part1]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
2317              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
2318              and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,
2319              and Message Parsing", draft-ietf-httpbis-p1-messaging-09
2320              (work in progress), March 2010.
2321
2322   [Part3]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
2323              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
2324              and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload
2325              and Content Negotiation", draft-ietf-httpbis-p3-payload-09
2326              (work in progress), March 2010.
2327
2328   [Part4]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
2329              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
2330              and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional
2331              Requests", draft-ietf-httpbis-p4-conditional-09 (work in
2332              progress), March 2010.
2333
2334   [Part5]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
2335              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
2336              and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and
2337              Partial Responses", draft-ietf-httpbis-p5-range-09 (work
2338              in progress), March 2010.
2339
2340   [Part6]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
2341              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
2342              Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part
2343              6: Caching", draft-ietf-httpbis-p6-cache-09 (work in
2344              progress), March 2010.
2345
2346   [Part7]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
2347              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
2348
2349
2350
2351Fielding, et al.        Expires September 9, 2010              [Page 42]
2352
2353Internet-Draft              HTTP/1.1, Part 2                  March 2010
2354
2355
2356              and J. Reschke, Ed., "HTTP/1.1, part 7: Authentication",
2357              draft-ietf-httpbis-p7-auth-09 (work in progress),
2358              March 2010.
2359
2360   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
2361              Requirement Levels", BCP 14, RFC 2119, March 1997.
2362
2363   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
2364              Specifications: ABNF", STD 68, RFC 5234, January 2008.
2365
236613.2.  Informative References
2367
2368   [RFC1945]  Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext
2369              Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
2370
2371   [RFC2068]  Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.
2372              Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
2373              RFC 2068, January 1997.
2374
2375   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
2376              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
2377              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
2378
2379   [RFC2817]  Khare, R. and S. Lawrence, "Upgrading to TLS Within
2380              HTTP/1.1", RFC 2817, May 2000.
2381
2382   [RFC3864]  Klyne, G., Nottingham, M., and J. Mogul, "Registration
2383              Procedures for Message Header Fields", BCP 90, RFC 3864,
2384              September 2004.
2385
2386   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
2387              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
2388              May 2008.
2389
2390   [RFC5322]  Resnick, P., "Internet Message Format", RFC 5322,
2391              October 2008.
2392
2393
2394Appendix A.  Compatibility with Previous Versions
2395
2396A.1.  Changes from RFC 2068
2397
2398   Clarified which error code should be used for inbound server failures
2399   (e.g., DNS failures).  (Section 8.5.5).
2400
2401   201 (Created) had a race that required an Etag be sent when a
2402   resource is first created.  (Section 8.2.2).
2403
2404
2405
2406
2407Fielding, et al.        Expires September 9, 2010              [Page 43]
2408
2409Internet-Draft              HTTP/1.1, Part 2                  March 2010
2410
2411
2412   303 (See Also) and 307 (Temporary Redirect) added to address user
2413   agent failure to implement status code 302 properly.  (Section 8.3.4
2414   and 8.3.8)
2415
2416   Rewrite of message transmission requirements to make it much harder
2417   for implementors to get it wrong, as the consequences of errors here
2418   can have significant impact on the Internet, and to deal with the
2419   following problems:
2420
2421   1.  Changing "HTTP/1.1 or later" to "HTTP/1.1", in contexts where
2422       this was incorrectly placing a requirement on the behavior of an
2423       implementation of a future version of HTTP/1.x
2424
2425   2.  Made it clear that user-agents should retry requests, not
2426       "clients" in general.
2427
2428   3.  Converted requirements for clients to ignore unexpected 100
2429       (Continue) responses, and for proxies to forward 100 responses,
2430       into a general requirement for 1xx responses.
2431
2432   4.  Modified some TCP-specific language, to make it clearer that non-
2433       TCP transports are possible for HTTP.
2434
2435   5.  Require that the origin server MUST NOT wait for the request body
2436       before it sends a required 100 (Continue) response.
2437
2438   6.  Allow, rather than require, a server to omit 100 (Continue) if it
2439       has already seen some of the request body.
2440
2441   7.  Allow servers to defend against denial-of-service attacks and
2442       broken clients.
2443
2444   This change adds the Expect header and 417 status code.
2445
2446   Clean up confusion between 403 and 404 responses.  (Section 8.4.4,
2447   8.4.5, and 8.4.11)
2448
2449   The PATCH, LINK, UNLINK methods were defined but not commonly
2450   implemented in previous versions of this specification.  See Section
2451   19.6.1 of [RFC2068].
2452
2453A.2.  Changes from RFC 2616
2454
2455   This document takes over the Status Code Registry, previously defined
2456   in Section 7.1 of [RFC2817].  (Section 4.1)
2457
2458   Clarify definition of POST.  (Section 7.5)
2459
2460
2461
2462
2463Fielding, et al.        Expires September 9, 2010              [Page 44]
2464
2465Internet-Draft              HTTP/1.1, Part 2                  March 2010
2466
2467
2468   Failed to consider that there are many other request methods that are
2469   safe to automatically redirect, and further that the user agent is
2470   able to make that determination based on the request method
2471   semantics.  (Sections 8.3.2, 8.3.3 and 8.3.8)
2472
2473   Deprecate 305 Use Proxy status code, because user agents did not
2474   implement it.  It used to indicate that the requested resource must
2475   be accessed through the proxy given by the Location field.  The
2476   Location field gave the URI of the proxy.  The recipient was expected
2477   to repeat this single request via the proxy.  (Section 8.3.6)
2478
2479   Reclassify Allow header as response header, removing the option to
2480   specify it in a PUT request.  Relax the server requirement on the
2481   contents of the Allow header and remove requirement on clients to
2482   always trust the header value.  (Section 9.1)
2483
2484   Correct syntax of Location header to allow fragment, as referred
2485   symbol wasn't what was expected, and add some clarifications as to
2486   when it would not be appropriate.  (Section 9.4)
2487
2488   Allow Referer value of "about:blank" as alternative to not specifying
2489   it.  (Section 9.6)
2490
2491   In the description of the Server header, the Via field was described
2492   as a SHOULD.  The requirement was and is stated correctly in the
2493   description of the Via header in Section 9.9 of [Part1].
2494   (Section 9.8)
2495
2496
2497Appendix B.  Collected ABNF
2498
2499   Accept = <Accept, defined in [Part3], Section 5.1>
2500   Accept-Charset = <Accept-Charset, defined in [Part3], Section 5.2>
2501   Accept-Encoding = <Accept-Encoding, defined in [Part3], Section 5.3>
2502   Accept-Language = <Accept-Language, defined in [Part3], Section 5.4>
2503   Accept-Ranges = <Accept-Ranges, defined in [Part5], Section 5.1>
2504   Age = <Age, defined in [Part6], Section 3.1>
2505   Allow = "Allow:" OWS Allow-v
2506   Allow-v = [ ( "," / Method ) *( OWS "," [ OWS Method ] ) ]
2507   Authorization = <Authorization, defined in [Part7], Section 3.1>
2508
2509   ETag = <ETag, defined in [Part4], Section 6.1>
2510   Expect = "Expect:" OWS Expect-v
2511   Expect-v = *( "," OWS ) expectation *( OWS "," [ OWS expectation ] )
2512
2513   From = "From:" OWS From-v
2514   From-v = mailbox
2515
2516
2517
2518
2519Fielding, et al.        Expires September 9, 2010              [Page 45]
2520
2521Internet-Draft              HTTP/1.1, Part 2                  March 2010
2522
2523
2524   HTTP-date = <HTTP-date, defined in [Part1], Section 6.1>
2525   Host = <Host, defined in [Part1], Section 2.6>
2526
2527   If-Match = <If-Match, defined in [Part4], Section 6.2>
2528   If-Modified-Since =
2529    <If-Modified-Since, defined in [Part4], Section 6.3>
2530   If-None-Match = <If-None-Match, defined in [Part4], Section 6.4>
2531   If-Range = <If-Range, defined in [Part5], Section 5.3>
2532   If-Unmodified-Since =
2533    <If-Unmodified-Since, defined in [Part4], Section 6.5>
2534
2535   Location = "Location:" OWS Location-v
2536   Location-v = URI
2537
2538   Max-Forwards = "Max-Forwards:" OWS Max-Forwards-v
2539   Max-Forwards-v = 1*DIGIT
2540   Method = %x4F.50.54.49.4F.4E.53 ; OPTIONS
2541    / %x47.45.54 ; GET
2542    / %x48.45.41.44 ; HEAD
2543    / %x50.4F.53.54 ; POST
2544    / %x50.55.54 ; PUT
2545    / %x44.45.4C.45.54.45 ; DELETE
2546    / %x54.52.41.43.45 ; TRACE
2547    / %x43.4F.4E.4E.45.43.54 ; CONNECT
2548    / extension-method
2549
2550   OWS = <OWS, defined in [Part1], Section 1.2.2>
2551
2552   Proxy-Authenticate =
2553    <Proxy-Authenticate, defined in [Part7], Section 3.2>
2554   Proxy-Authorization =
2555    <Proxy-Authorization, defined in [Part7], Section 3.3>
2556
2557   RWS = <RWS, defined in [Part1], Section 1.2.2>
2558   Range = <Range, defined in [Part5], Section 5.4>
2559   Reason-Phrase = *( WSP / VCHAR / obs-text )
2560   Referer = "Referer:" OWS Referer-v
2561   Referer-v = absolute-URI / partial-URI
2562   Retry-After = "Retry-After:" OWS Retry-After-v
2563   Retry-After-v = HTTP-date / delta-seconds
2564
2565   Server = "Server:" OWS Server-v
2566   Server-v = product *( RWS ( product / comment ) )
2567
2568
2569
2570
2571
2572
2573
2574
2575Fielding, et al.        Expires September 9, 2010              [Page 46]
2576
2577Internet-Draft              HTTP/1.1, Part 2                  March 2010
2578
2579
2580   Status-Code = "100" / "101" / "200" / "201" / "202" / "203" / "204" /
2581    "205" / "206" / "300" / "301" / "302" / "303" / "304" / "305" /
2582    "307" / "400" / "401" / "402" / "403" / "404" / "405" / "406" /
2583    "407" / "408" / "409" / "410" / "411" / "412" / "413" / "414" /
2584    "415" / "416" / "417" / "500" / "501" / "502" / "503" / "504" /
2585    "505" / extension-code
2586
2587   TE = <TE, defined in [Part1], Section 9.8>
2588
2589   URI = <URI, defined in [Part1], Section 2.6>
2590   User-Agent = "User-Agent:" OWS User-Agent-v
2591   User-Agent-v = product *( RWS ( product / comment ) )
2592
2593   Vary = <Vary, defined in [Part6], Section 3.5>
2594
2595   WWW-Authenticate =
2596    <WWW-Authenticate, defined in [Part7], Section 3.4>
2597
2598   absolute-URI = <absolute-URI, defined in [Part1], Section 2.6>
2599
2600   comment = <comment, defined in [Part1], Section 3.2>
2601
2602   delta-seconds = 1*DIGIT
2603
2604   expect-params = ";" token [ "=" ( token / quoted-string ) ]
2605   expectation = "100-continue" / expectation-extension
2606   expectation-extension = token [ "=" ( token / quoted-string )
2607    *expect-params ]
2608   extension-code = 3DIGIT
2609   extension-method = token
2610
2611   mailbox = <mailbox, defined in [RFC5322], Section 3.4>
2612
2613   obs-text = <obs-text, defined in [Part1], Section 1.2.2>
2614
2615   partial-URI = <partial-URI, defined in [Part1], Section 2.6>
2616   product = <product, defined in [Part1], Section 6.3>
2617
2618   quoted-string = <quoted-string, defined in [Part1], Section 1.2.2>
2619
2620   request-header = Accept / Accept-Charset / Accept-Encoding /
2621    Accept-Language / Authorization / Expect / From / Host / If-Match /
2622    If-Modified-Since / If-None-Match / If-Range / If-Unmodified-Since /
2623    Max-Forwards / Proxy-Authorization / Range / Referer / TE /
2624    User-Agent
2625   response-header = Accept-Ranges / Age / Allow / ETag / Location /
2626    Proxy-Authenticate / Retry-After / Server / Vary / WWW-Authenticate
2627
2628
2629
2630
2631Fielding, et al.        Expires September 9, 2010              [Page 47]
2632
2633Internet-Draft              HTTP/1.1, Part 2                  March 2010
2634
2635
2636   token = <token, defined in [Part1], Section 1.2.2>
2637
2638   ABNF diagnostics:
2639
2640   ; Reason-Phrase defined but not used
2641   ; Status-Code defined but not used
2642   ; request-header defined but not used
2643   ; response-header defined but not used
2644
2645
2646Appendix C.  Change Log (to be removed by RFC Editor before publication)
2647
2648C.1.  Since RFC2616
2649
2650   Extracted relevant partitions from [RFC2616].
2651
2652C.2.  Since draft-ietf-httpbis-p2-semantics-00
2653
2654   Closed issues:
2655
2656   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/5>: "Via is a MUST"
2657      (<http://purl.org/NET/http-errata#via-must>)
2658
2659   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/6>: "Fragments
2660      allowed in Location"
2661      (<http://purl.org/NET/http-errata#location-fragments>)
2662
2663   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/10>: "Safe Methods
2664      vs Redirection" (<http://purl.org/NET/http-errata#saferedirect>)
2665
2666   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/17>: "Revise
2667      description of the POST method"
2668      (<http://purl.org/NET/http-errata#post>)
2669
2670   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and
2671      Informative references"
2672
2673   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/42>: "RFC2606
2674      Compliance"
2675
2676   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/65>: "Informative
2677      references"
2678
2679   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/84>: "Redundant
2680      cross-references"
2681
2682   Other changes:
2683
2684
2685
2686
2687Fielding, et al.        Expires September 9, 2010              [Page 48]
2688
2689Internet-Draft              HTTP/1.1, Part 2                  March 2010
2690
2691
2692   o  Move definitions of 304 and 412 condition codes to [Part4]
2693
2694C.3.  Since draft-ietf-httpbis-p2-semantics-01
2695
2696   Closed issues:
2697
2698   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/21>: "PUT side
2699      effects"
2700
2701   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/91>: "Duplicate Host
2702      header requirements"
2703
2704   Ongoing work on ABNF conversion
2705   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
2706
2707   o  Move "Product Tokens" section (back) into Part 1, as "token" is
2708      used in the definition of the Upgrade header.
2709
2710   o  Add explicit references to BNF syntax and rules imported from
2711      other parts of the specification.
2712
2713   o  Copy definition of delta-seconds from Part6 instead of referencing
2714      it.
2715
2716C.4.  Since draft-ietf-httpbis-p2-semantics-02
2717
2718   Closed issues:
2719
2720   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/24>: "Requiring
2721      Allow in 405 responses"
2722
2723   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/59>: "Status Code
2724      Registry"
2725
2726   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/61>: "Redirection
2727      vs. Location"
2728
2729   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/70>: "Cacheability
2730      of 303 response"
2731
2732   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/76>: "305 Use Proxy"
2733
2734   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/105>:
2735      "Classification for Allow header"
2736
2737   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/112>: "PUT - 'store
2738      under' vs 'store at'"
2739
2740
2741
2742
2743Fielding, et al.        Expires September 9, 2010              [Page 49]
2744
2745Internet-Draft              HTTP/1.1, Part 2                  March 2010
2746
2747
2748   Ongoing work on IANA Message Header Registration
2749   (<http://tools.ietf.org/wg/httpbis/trac/ticket/40>):
2750
2751   o  Reference RFC 3984, and update header registrations for headers
2752      defined in this document.
2753
2754   Ongoing work on ABNF conversion
2755   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
2756
2757   o  Replace string literals when the string really is case-sensitive
2758      (method).
2759
2760C.5.  Since draft-ietf-httpbis-p2-semantics-03
2761
2762   Closed issues:
2763
2764   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/98>: "OPTIONS
2765      request bodies"
2766
2767   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/119>: "Description
2768      of CONNECT should refer to RFC2817"
2769
2770   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/125>: "Location
2771      Content-Location reference request/response mixup"
2772
2773   Ongoing work on Method Registry
2774   (<http://tools.ietf.org/wg/httpbis/trac/ticket/72>):
2775
2776   o  Added initial proposal for registration process, plus initial
2777      content (non-HTTP/1.1 methods to be added by a separate
2778      specification).
2779
2780C.6.  Since draft-ietf-httpbis-p2-semantics-04
2781
2782   Closed issues:
2783
2784   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/103>: "Content-*"
2785
2786   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/132>: "RFC 2822 is
2787      updated by RFC 5322"
2788
2789   Ongoing work on ABNF conversion
2790   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
2791
2792   o  Use "/" instead of "|" for alternatives.
2793
2794   o  Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
2795      whitespace ("OWS") and required whitespace ("RWS").
2796
2797
2798
2799Fielding, et al.        Expires September 9, 2010              [Page 50]
2800
2801Internet-Draft              HTTP/1.1, Part 2                  March 2010
2802
2803
2804   o  Rewrite ABNFs to spell out whitespace rules, factor out header
2805      value format definitions.
2806
2807C.7.  Since draft-ietf-httpbis-p2-semantics-05
2808
2809   Closed issues:
2810
2811   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/94>: "Reason-Phrase
2812      BNF"
2813
2814   Final work on ABNF conversion
2815   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
2816
2817   o  Add appendix containing collected and expanded ABNF, reorganize
2818      ABNF introduction.
2819
2820C.8.  Since draft-ietf-httpbis-p2-semantics-06
2821
2822   Closed issues:
2823
2824   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/144>: "Clarify when
2825      Referer is sent"
2826
2827   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/164>: "status codes
2828      vs methods"
2829
2830   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/170>: "Do not
2831      require "updates" relation for specs that register status codes or
2832      method names"
2833
2834C.9.  Since draft-ietf-httpbis-p2-semantics-07
2835
2836   Closed issues:
2837
2838   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/27>: "Idempotency"
2839
2840   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/33>: "TRACE security
2841      considerations"
2842
2843   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/110>: "Clarify rules
2844      for determining what entities a response carries"
2845
2846   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/140>: "update note
2847      citing RFC 1945 and 2068"
2848
2849   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/182>: "update note
2850      about redirect limit"
2851
2852
2853
2854
2855Fielding, et al.        Expires September 9, 2010              [Page 51]
2856
2857Internet-Draft              HTTP/1.1, Part 2                  March 2010
2858
2859
2860   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/191>: "Location
2861      header ABNF should use 'URI'"
2862
2863   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/192>: "fragments in
2864      Location vs status 303"
2865
2866   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/198>: "move IANA
2867      registrations for optional status codes"
2868
2869   Partly resolved issues:
2870
2871   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/171>: "Are OPTIONS
2872      and TRACE safe?"
2873
2874C.10.  Since draft-ietf-httpbis-p2-semantics-08
2875
2876   Closed issues:
2877
2878   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/10>: "Safe Methods
2879      vs Redirection" (we missed the introduction to the 3xx status
2880      codes when fixing this previously)
2881
2882
2883Index
2884
2885   1
2886      100 Continue (status code)  20
2887      101 Switching Protocols (status code)  20
2888
2889   2
2890      200 OK (status code)  21
2891      201 Created (status code)  21
2892      202 Accepted (status code)  22
2893      203 Non-Authoritative Information (status code)  22
2894      204 No Content (status code)  22
2895      205 Reset Content (status code)  23
2896      206 Partial Content (status code)  23
2897
2898   3
2899      300 Multiple Choices (status code)  23
2900      301 Moved Permanently (status code)  24
2901      302 Found (status code)  24
2902      303 See Other (status code)  25
2903      304 Not Modified (status code)  25
2904      305 Use Proxy (status code)  26
2905      306 (Unused) (status code)  26
2906      307 Temporary Redirect (status code)  26
2907
2908
2909
2910
2911Fielding, et al.        Expires September 9, 2010              [Page 52]
2912
2913Internet-Draft              HTTP/1.1, Part 2                  March 2010
2914
2915
2916   4
2917      400 Bad Request (status code)  27
2918      401 Unauthorized (status code)  27
2919      402 Payment Required (status code)  27
2920      403 Forbidden (status code)  27
2921      404 Not Found (status code)  27
2922      405 Method Not Allowed (status code)  27
2923      406 Not Acceptable (status code)  28
2924      407 Proxy Authentication Required (status code)  28
2925      408 Request Timeout (status code)  28
2926      409 Conflict (status code)  28
2927      410 Gone (status code)  29
2928      411 Length Required (status code)  29
2929      412 Precondition Failed (status code)  29
2930      413 Request Entity Too Large (status code)  29
2931      414 URI Too Long (status code)  30
2932      415 Unsupported Media Type (status code)  30
2933      416 Requested Range Not Satisfiable (status code)  30
2934      417 Expectation Failed (status code)  30
2935
2936   5
2937      500 Internal Server Error (status code)  31
2938      501 Not Implemented (status code)  31
2939      502 Bad Gateway (status code)  31
2940      503 Service Unavailable (status code)  31
2941      504 Gateway Timeout (status code)  31
2942      505 HTTP Version Not Supported (status code)  31
2943
2944   A
2945      Allow header  32
2946
2947   C
2948      CONNECT method  20
2949
2950   D
2951      DELETE method  19
2952
2953   E
2954      Expect header  32
2955
2956   F
2957      From header  33
2958
2959   G
2960      GET method  16
2961      Grammar
2962         Allow  32
2963         Allow-v  32
2964
2965
2966
2967Fielding, et al.        Expires September 9, 2010              [Page 53]
2968
2969Internet-Draft              HTTP/1.1, Part 2                  March 2010
2970
2971
2972         delta-seconds  36
2973         Expect  32
2974         expect-params  32
2975         Expect-v  32
2976         expectation  32
2977         expectation-extension  32
2978         extension-code  11
2979         extension-method  8
2980         From  33
2981         From-v  33
2982         Location  34
2983         Location-v  34
2984         Max-Forwards  35
2985         Max-Forwards-v  35
2986         Method  8
2987         Reason-Phrase  11
2988         Referer  35
2989         Referer-v  35
2990         request-header  9
2991         response-header  12
2992         Retry-After  36
2993         Retry-After-v  36
2994         Server  36
2995         Server-v  36
2996         Status-Code  11
2997         User-Agent  37
2998         User-Agent-v  37
2999
3000   H
3001      HEAD method  16
3002      Headers
3003         Allow  32
3004         Expect  32
3005         From  33
3006         Location  34
3007         Max-Forwards  35
3008         Referer  35
3009         Retry-After  36
3010         Server  36
3011         User-Agent  37
3012
3013   I
3014      Idempotent Methods  14
3015
3016   L
3017      LINK method  44
3018      Location header  34
3019
3020
3021
3022
3023Fielding, et al.        Expires September 9, 2010              [Page 54]
3024
3025Internet-Draft              HTTP/1.1, Part 2                  March 2010
3026
3027
3028   M
3029      Max-Forwards header  35
3030      Methods
3031         CONNECT  20
3032         DELETE  19
3033         GET  16
3034         HEAD  16
3035         LINK  44
3036         OPTIONS  15
3037         PATCH  44
3038         POST  17
3039         PUT  18
3040         TRACE  19
3041         UNLINK  44
3042
3043   O
3044      OPTIONS method  15
3045
3046   P
3047      PATCH method  44
3048      POST method  17
3049      PUT method  18
3050
3051   R
3052      Referer header  35
3053      Retry-After header  36
3054
3055   S
3056      Safe Methods  14
3057      Server header  36
3058      Status Codes
3059         100 Continue  20
3060         101 Switching Protocols  20
3061         200 OK  21
3062         201 Created  21
3063         202 Accepted  22
3064         203 Non-Authoritative Information  22
3065         204 No Content  22
3066         205 Reset Content  23
3067         206 Partial Content  23
3068         300 Multiple Choices  23
3069         301 Moved Permanently  24
3070         302 Found  24
3071         303 See Other  25
3072         304 Not Modified  25
3073         305 Use Proxy  26
3074         306 (Unused)  26
3075         307 Temporary Redirect  26
3076
3077
3078
3079Fielding, et al.        Expires September 9, 2010              [Page 55]
3080
3081Internet-Draft              HTTP/1.1, Part 2                  March 2010
3082
3083
3084         400 Bad Request  27
3085         401 Unauthorized  27
3086         402 Payment Required  27
3087         403 Forbidden  27
3088         404 Not Found  27
3089         405 Method Not Allowed  27
3090         406 Not Acceptable  28
3091         407 Proxy Authentication Required  28
3092         408 Request Timeout  28
3093         409 Conflict  28
3094         410 Gone  29
3095         411 Length Required  29
3096         412 Precondition Failed  29
3097         413 Request Entity Too Large  29
3098         414 URI Too Long  30
3099         415 Unsupported Media Type  30
3100         416 Requested Range Not Satisfiable  30
3101         417 Expectation Failed  30
3102         500 Internal Server Error  31
3103         501 Not Implemented  31
3104         502 Bad Gateway  31
3105         503 Service Unavailable  31
3106         504 Gateway Timeout  31
3107         505 HTTP Version Not Supported  31
3108
3109   T
3110      TRACE method  19
3111
3112   U
3113      UNLINK method  44
3114      User-Agent header  37
3115
3116
3117Authors' Addresses
3118
3119   Roy T. Fielding (editor)
3120   Day Software
3121   23 Corporate Plaza DR, Suite 280
3122   Newport Beach, CA  92660
3123   USA
3124
3125   Phone: +1-949-706-5300
3126   Fax:   +1-949-706-5305
3127   Email: fielding@gbiv.com
3128   URI:   http://roy.gbiv.com/
3129
3130
3131
3132
3133
3134
3135Fielding, et al.        Expires September 9, 2010              [Page 56]
3136
3137Internet-Draft              HTTP/1.1, Part 2                  March 2010
3138
3139
3140   Jim Gettys
3141   One Laptop per Child
3142   21 Oak Knoll Road
3143   Carlisle, MA  01741
3144   USA
3145
3146   Email: jg@laptop.org
3147   URI:   http://www.laptop.org/
3148
3149
3150   Jeffrey C. Mogul
3151   Hewlett-Packard Company
3152   HP Labs, Large Scale Systems Group
3153   1501 Page Mill Road, MS 1177
3154   Palo Alto, CA  94304
3155   USA
3156
3157   Email: JeffMogul@acm.org
3158
3159
3160   Henrik Frystyk Nielsen
3161   Microsoft Corporation
3162   1 Microsoft Way
3163   Redmond, WA  98052
3164   USA
3165
3166   Email: henrikn@microsoft.com
3167
3168
3169   Larry Masinter
3170   Adobe Systems, Incorporated
3171   345 Park Ave
3172   San Jose, CA  95110
3173   USA
3174
3175   Email: LMM@acm.org
3176   URI:   http://larry.masinter.net/
3177
3178
3179   Paul J. Leach
3180   Microsoft Corporation
3181   1 Microsoft Way
3182   Redmond, WA  98052
3183
3184   Email: paulle@microsoft.com
3185
3186
3187
3188
3189
3190
3191Fielding, et al.        Expires September 9, 2010              [Page 57]
3192
3193Internet-Draft              HTTP/1.1, Part 2                  March 2010
3194
3195
3196   Tim Berners-Lee
3197   World Wide Web Consortium
3198   MIT Computer Science and Artificial Intelligence Laboratory
3199   The Stata Center, Building 32
3200   32 Vassar Street
3201   Cambridge, MA  02139
3202   USA
3203
3204   Email: timbl@w3.org
3205   URI:   http://www.w3.org/People/Berners-Lee/
3206
3207
3208   Yves Lafon (editor)
3209   World Wide Web Consortium
3210   W3C / ERCIM
3211   2004, rte des Lucioles
3212   Sophia-Antipolis, AM  06902
3213   France
3214
3215   Email: ylafon@w3.org
3216   URI:   http://www.raubacapeu.net/people/yves/
3217
3218
3219   Julian F. Reschke (editor)
3220   greenbytes GmbH
3221   Hafenweg 16
3222   Muenster, NW  48155
3223   Germany
3224
3225   Phone: +49 251 2807760
3226   Fax:   +49 251 2807761
3227   Email: julian.reschke@greenbytes.de
3228   URI:   http://greenbytes.de/tech/webdav/
3229
3230
3231
3232
3233
3234
3235
3236
3237
3238
3239
3240
3241
3242
3243
3244
3245
3246
3247Fielding, et al.        Expires September 9, 2010              [Page 58]
3248
Note: See TracBrowser for help on using the repository browser.