idnits 2.17.1
draft-ietf-httpbis-p2-semantics-14.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
-- The draft header indicates that this document updates RFC2817, but the
abstract doesn't seem to mention this, which it should.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
(Using the creation date from RFC2817, updated by this document, for
RFC5378 checks: 1998-11-18)
-- The document seems to contain a disclaimer for pre-RFC5378 work, and may
have content which was first submitted before 10 November 2008. The
disclaimer is necessary when there are original authors that you have
been unable to contact, or if some do not wish to grant the BCP78 rights
to the IETF Trust. If you are able to get all authors (current and
original) to grant those rights, you can and should remove the
disclaimer; otherwise, the disclaimer is needed and you can ignore this
comment. (See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (April 18, 2011) is 4750 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Outdated reference: A later version (-26) exists of
draft-ietf-httpbis-p1-messaging-14
== Outdated reference: A later version (-20) exists of
draft-ietf-httpbis-p3-payload-14
== Outdated reference: A later version (-26) exists of
draft-ietf-httpbis-p4-conditional-14
== Outdated reference: A later version (-26) exists of
draft-ietf-httpbis-p5-range-14
== Outdated reference: A later version (-26) exists of
draft-ietf-httpbis-p6-cache-14
== Outdated reference: A later version (-26) exists of
draft-ietf-httpbis-p7-auth-14
-- Obsolete informational reference (is this intentional?): RFC 2068
(Obsoleted by RFC 2616)
-- Obsolete informational reference (is this intentional?): RFC 2616
(Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235)
-- Obsolete informational reference (is this intentional?): RFC 5226
(Obsoleted by RFC 8126)
Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 6 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 HTTPbis Working Group R. Fielding, Ed.
3 Internet-Draft Adobe
4 Obsoletes: 2616 (if approved) J. Gettys
5 Updates: 2817 (if approved) Alcatel-Lucent
6 Intended status: Standards Track J. Mogul
7 Expires: October 20, 2011 HP
8 H. Frystyk
9 Microsoft
10 L. Masinter
11 Adobe
12 P. Leach
13 Microsoft
14 T. Berners-Lee
15 W3C/MIT
16 Y. Lafon, Ed.
17 W3C
18 J. Reschke, Ed.
19 greenbytes
20 April 18, 2011
22 HTTP/1.1, part 2: Message Semantics
23 draft-ietf-httpbis-p2-semantics-14
25 Abstract
27 The Hypertext Transfer Protocol (HTTP) is an application-level
28 protocol for distributed, collaborative, hypermedia information
29 systems. HTTP has been in use by the World Wide Web global
30 information initiative since 1990. This document is Part 2 of the
31 seven-part specification that defines the protocol referred to as
32 "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines
33 the semantics of HTTP messages as expressed by request methods,
34 request header fields, response status codes, and response header
35 fields.
37 Editorial Note (To be removed by RFC Editor)
39 Discussion of this draft should take place on the HTTPBIS working
40 group mailing list (ietf-http-wg@w3.org), which is archived at
41 .
43 The current issues list is at
44 and related
45 documents (including fancy diffs) can be found at
46 .
48 The changes in this draft are summarized in Appendix C.15.
50 Status of This Memo
52 This Internet-Draft is submitted in full conformance with the
53 provisions of BCP 78 and BCP 79.
55 Internet-Drafts are working documents of the Internet Engineering
56 Task Force (IETF). Note that other groups may also distribute
57 working documents as Internet-Drafts. The list of current Internet-
58 Drafts is at http://datatracker.ietf.org/drafts/current/.
60 Internet-Drafts are draft documents valid for a maximum of six months
61 and may be updated, replaced, or obsoleted by other documents at any
62 time. It is inappropriate to use Internet-Drafts as reference
63 material or to cite them other than as "work in progress."
65 This Internet-Draft will expire on October 20, 2011.
67 Copyright Notice
69 Copyright (c) 2011 IETF Trust and the persons identified as the
70 document authors. All rights reserved.
72 This document is subject to BCP 78 and the IETF Trust's Legal
73 Provisions Relating to IETF Documents
74 (http://trustee.ietf.org/license-info) in effect on the date of
75 publication of this document. Please review these documents
76 carefully, as they describe your rights and restrictions with respect
77 to this document. Code Components extracted from this document must
78 include Simplified BSD License text as described in Section 4.e of
79 the Trust Legal Provisions and are provided without warranty as
80 described in the Simplified BSD License.
82 This document may contain material from IETF Documents or IETF
83 Contributions published or made publicly available before November
84 10, 2008. The person(s) controlling the copyright in some of this
85 material may not have granted the IETF Trust the right to allow
86 modifications of such material outside the IETF Standards Process.
87 Without obtaining an adequate license from the person(s) controlling
88 the copyright in such materials, this document may not be modified
89 outside the IETF Standards Process, and derivative works of it may
90 not be created outside the IETF Standards Process, except to format
91 it for publication as an RFC or to translate it into languages other
92 than English.
94 Table of Contents
96 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
97 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6
98 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6
99 1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 7
100 1.2.2. ABNF Rules defined in other Parts of the
101 Specification . . . . . . . . . . . . . . . . . . . . 7
102 2. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
103 2.1. Overview of Methods . . . . . . . . . . . . . . . . . . . 8
104 2.2. Method Registry . . . . . . . . . . . . . . . . . . . . . 8
105 2.2.1. Considerations for New Methods . . . . . . . . . . . . 8
106 3. Request Header Fields . . . . . . . . . . . . . . . . . . . . 9
107 4. Status Code and Reason Phrase . . . . . . . . . . . . . . . . 10
108 4.1. Overview of Status Codes . . . . . . . . . . . . . . . . . 10
109 4.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 12
110 4.2.1. Considerations for New Status Codes . . . . . . . . . 12
111 5. Response Header Fields . . . . . . . . . . . . . . . . . . . . 13
112 6. Representation . . . . . . . . . . . . . . . . . . . . . . . . 13
113 6.1. Identifying the Resource Associated with a
114 Representation . . . . . . . . . . . . . . . . . . . . . . 13
115 7. Method Definitions . . . . . . . . . . . . . . . . . . . . . . 14
116 7.1. Safe and Idempotent Methods . . . . . . . . . . . . . . . 14
117 7.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . 14
118 7.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . . 15
119 7.2. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 15
120 7.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
121 7.4. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
122 7.5. POST . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
123 7.6. PUT . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
124 7.7. DELETE . . . . . . . . . . . . . . . . . . . . . . . . . . 20
125 7.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . . . 21
126 7.9. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . . 21
127 7.9.1. Establishing a Tunnel with CONNECT . . . . . . . . . . 22
128 8. Status Code Definitions . . . . . . . . . . . . . . . . . . . 23
129 8.1. Informational 1xx . . . . . . . . . . . . . . . . . . . . 23
130 8.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 23
131 8.1.2. 101 Switching Protocols . . . . . . . . . . . . . . . 23
132 8.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 24
133 8.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 24
134 8.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 24
135 8.2.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 25
136 8.2.4. 203 Non-Authoritative Information . . . . . . . . . . 25
137 8.2.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 25
138 8.2.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 26
139 8.2.7. 206 Partial Content . . . . . . . . . . . . . . . . . 26
140 8.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 26
141 8.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 27
142 8.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 27
143 8.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 28
144 8.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 28
145 8.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . . 29
146 8.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 29
147 8.3.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 29
148 8.3.8. 307 Temporary Redirect . . . . . . . . . . . . . . . . 29
149 8.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 30
150 8.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 30
151 8.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . . 30
152 8.4.3. 402 Payment Required . . . . . . . . . . . . . . . . . 30
153 8.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 30
154 8.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . . 31
155 8.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . . 31
156 8.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 31
157 8.4.8. 407 Proxy Authentication Required . . . . . . . . . . 32
158 8.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . . 32
159 8.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 32
160 8.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 32
161 8.4.12. 411 Length Required . . . . . . . . . . . . . . . . . 33
162 8.4.13. 412 Precondition Failed . . . . . . . . . . . . . . . 33
163 8.4.14. 413 Request Entity Too Large . . . . . . . . . . . . . 33
164 8.4.15. 414 URI Too Long . . . . . . . . . . . . . . . . . . . 33
165 8.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . . 33
166 8.4.17. 416 Requested Range Not Satisfiable . . . . . . . . . 34
167 8.4.18. 417 Expectation Failed . . . . . . . . . . . . . . . . 34
168 8.4.19. 426 Upgrade Required . . . . . . . . . . . . . . . . . 34
169 8.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 34
170 8.5.1. 500 Internal Server Error . . . . . . . . . . . . . . 34
171 8.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 35
172 8.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 35
173 8.5.4. 503 Service Unavailable . . . . . . . . . . . . . . . 35
174 8.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 35
175 8.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 35
176 9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 36
177 9.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . . . 36
178 9.2. Expect . . . . . . . . . . . . . . . . . . . . . . . . . . 36
179 9.3. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
180 9.4. Location . . . . . . . . . . . . . . . . . . . . . . . . . 38
181 9.5. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . . 39
182 9.6. Referer . . . . . . . . . . . . . . . . . . . . . . . . . 39
183 9.7. Retry-After . . . . . . . . . . . . . . . . . . . . . . . 40
184 9.8. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 40
185 9.9. User-Agent . . . . . . . . . . . . . . . . . . . . . . . . 41
186 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
187 10.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 41
188 10.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 42
189 10.3. Header Field Registration . . . . . . . . . . . . . . . . 43
190 11. Security Considerations . . . . . . . . . . . . . . . . . . . 44
191 11.1. Transfer of Sensitive Information . . . . . . . . . . . . 44
192 11.2. Encoding Sensitive Information in URIs . . . . . . . . . . 45
193 11.3. Location Headers and Spoofing . . . . . . . . . . . . . . 46
194 11.4. Security Considerations for CONNECT . . . . . . . . . . . 46
195 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 46
196 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46
197 13.1. Normative References . . . . . . . . . . . . . . . . . . . 46
198 13.2. Informative References . . . . . . . . . . . . . . . . . . 47
199 Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 48
200 Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 49
201 Appendix C. Change Log (to be removed by RFC Editor before
202 publication) . . . . . . . . . . . . . . . . . . . . 51
203 C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 51
204 C.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 51
205 C.3. Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . . 52
206 C.4. Since draft-ietf-httpbis-p2-semantics-02 . . . . . . . . . 52
207 C.5. Since draft-ietf-httpbis-p2-semantics-03 . . . . . . . . . 53
208 C.6. Since draft-ietf-httpbis-p2-semantics-04 . . . . . . . . . 53
209 C.7. Since draft-ietf-httpbis-p2-semantics-05 . . . . . . . . . 54
210 C.8. Since draft-ietf-httpbis-p2-semantics-06 . . . . . . . . . 54
211 C.9. Since draft-ietf-httpbis-p2-semantics-07 . . . . . . . . . 54
212 C.10. Since draft-ietf-httpbis-p2-semantics-08 . . . . . . . . . 55
213 C.11. Since draft-ietf-httpbis-p2-semantics-09 . . . . . . . . . 55
214 C.12. Since draft-ietf-httpbis-p2-semantics-10 . . . . . . . . . 55
215 C.13. Since draft-ietf-httpbis-p2-semantics-11 . . . . . . . . . 56
216 C.14. Since draft-ietf-httpbis-p2-semantics-12 . . . . . . . . . 56
217 C.15. Since draft-ietf-httpbis-p2-semantics-13 . . . . . . . . . 58
218 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
220 1. Introduction
222 This document defines HTTP/1.1 request and response semantics. Each
223 HTTP message, as defined in [Part1], is in the form of either a
224 request or a response. An HTTP server listens on a connection for
225 HTTP requests and responds to each request, in the order received on
226 that connection, with one or more HTTP response messages. This
227 document defines the commonly agreed upon semantics of the HTTP
228 uniform interface, the intentions defined by each request method, and
229 the various response messages that might be expected as a result of
230 applying that method to the target resource.
232 This document is currently disorganized in order to minimize the
233 changes between drafts and enable reviewers to see the smaller errata
234 changes. A future draft will reorganize the sections to better
235 reflect the content. In particular, the sections will be ordered
236 according to the typical processing of an HTTP request message (after
237 message parsing): resource mapping, methods, request modifying header
238 fields, response status, status modifying header fields, and resource
239 metadata. The current mess reflects how widely dispersed these
240 topics and associated requirements had become in [RFC2616].
242 1.1. Requirements
244 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
245 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
246 document are to be interpreted as described in [RFC2119].
248 An implementation is not compliant if it fails to satisfy one or more
249 of the "MUST" or "REQUIRED" level requirements for the protocols it
250 implements. An implementation that satisfies all the "MUST" or
251 "REQUIRED" level and all the "SHOULD" level requirements for its
252 protocols is said to be "unconditionally compliant"; one that
253 satisfies all the "MUST" level requirements but not all the "SHOULD"
254 level requirements for its protocols is said to be "conditionally
255 compliant".
257 1.2. Syntax Notation
259 This specification uses the ABNF syntax defined in Section 1.2 of
260 [Part1] (which extends the syntax defined in [RFC5234] with a list
261 rule). Appendix B shows the collected ABNF, with the list rule
262 expanded.
264 The following core rules are included by reference, as defined in
265 [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
266 (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
267 HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit
268 sequence of data), SP (space), VCHAR (any visible USASCII character),
269 and WSP (whitespace).
271 1.2.1. Core Rules
273 The core rules below are defined in Section 1.2.2 of [Part1]:
275 quoted-string =
276 token =
277 OWS =
278 RWS =
279 obs-text =
281 1.2.2. ABNF Rules defined in other Parts of the Specification
283 The ABNF rules below are defined in other parts:
285 absolute-URI =
286 comment =
287 HTTP-date =
288 partial-URI =
289 product =
290 URI-reference =
292 2. Method
294 The Method token indicates the request method to be performed on the
295 target resource (Section 4.3 of [Part1]). The method is case-
296 sensitive.
298 Method = token
300 The list of methods allowed by a resource can be specified in an
301 Allow header field (Section 9.1). The status code of the response
302 always notifies the client whether a method is currently allowed on a
303 resource, since the set of allowed methods can change dynamically.
304 An origin server SHOULD respond with the status code 405 (Method Not
305 Allowed) if the method is known by the origin server but not allowed
306 for the resource, and 501 (Not Implemented) if the method is
307 unrecognized or not implemented by the origin server. The methods
308 GET and HEAD MUST be supported by all general-purpose servers. All
309 other methods are OPTIONAL; however, if the above methods are
310 implemented, they MUST be implemented with the same semantics as
311 those specified in Section 7.
313 2.1. Overview of Methods
315 The methods listed below are defined in Section 7.
317 +-------------+---------------+
318 | Method Name | Defined in... |
319 +-------------+---------------+
320 | OPTIONS | Section 7.2 |
321 | GET | Section 7.3 |
322 | HEAD | Section 7.4 |
323 | POST | Section 7.5 |
324 | PUT | Section 7.6 |
325 | DELETE | Section 7.7 |
326 | TRACE | Section 7.8 |
327 | CONNECT | Section 7.9 |
328 +-------------+---------------+
330 Note that this list is not exhaustive -- it does not include request
331 methods defined in other specifications.
333 2.2. Method Registry
335 The HTTP Method Registry defines the name space for the Method token
336 in the Request line of an HTTP request.
338 Registrations MUST include the following fields:
340 o Method Name (see Section 2)
342 o Safe ("yes" or "no", see Section 7.1.1)
344 o Pointer to specification text
346 Values to be added to this name space are subject to IETF review
347 ([RFC5226], Section 4.1).
349 The registry itself is maintained at
350 .
352 2.2.1. Considerations for New Methods
354 When it is necessary to express new semantics for a HTTP request that
355 aren't specific to a single application or media type, and currently
356 defined methods are inadequate, it may be appropriate to register a
357 new method.
359 HTTP methods are generic; that is, they are potentially applicable to
360 any resource, not just one particular media type, "type" of resource,
361 or application. As such, it is preferred that new HTTP methods be
362 registered in a document that isn't specific to a single application,
363 so that this is clear.
365 Due to the parsing rules defined in Section 3.3 of [Part1],
366 definitions of HTTP methods cannot prohibit the presence of a
367 message-body on either the request or the response message (with
368 responses to HEAD requests being the single exception). Definitions
369 of new methods cannot change this rule, but they can specify that
370 only zero-length bodies (as opposed to absent bodies) are allowed.
372 New method definitions need to indicate whether they are safe
373 (Section 7.1.1), what semantics (if any) the request body has, and
374 whether they are idempotent (Section 7.1.2). They also need to state
375 whether they can be cached ([Part6]); in particular what conditions a
376 cache may store the response, and under what conditions such a stored
377 response may be used to satisfy a subsequent request.
379 3. Request Header Fields
381 The request header fields allow the client to pass additional
382 information about the request, and about the client itself, to the
383 server. These fields act as request modifiers, with semantics
384 equivalent to the parameters on a programming language method
385 invocation.
387 +---------------------+------------------------+
388 | Header Field Name | Defined in... |
389 +---------------------+------------------------+
390 | Accept | Section 6.1 of [Part3] |
391 | Accept-Charset | Section 6.2 of [Part3] |
392 | Accept-Encoding | Section 6.3 of [Part3] |
393 | Accept-Language | Section 6.4 of [Part3] |
394 | Authorization | Section 4.1 of [Part7] |
395 | Expect | Section 9.2 |
396 | From | Section 9.3 |
397 | Host | Section 9.4 of [Part1] |
398 | If-Match | Section 3.1 of [Part4] |
399 | If-Modified-Since | Section 3.3 of [Part4] |
400 | If-None-Match | Section 3.2 of [Part4] |
401 | If-Range | Section 5.3 of [Part5] |
402 | If-Unmodified-Since | Section 3.4 of [Part4] |
403 | Max-Forwards | Section 9.5 |
404 | Proxy-Authorization | Section 4.3 of [Part7] |
405 | Range | Section 5.4 of [Part5] |
406 | Referer | Section 9.6 |
407 | TE | Section 9.5 of [Part1] |
408 | User-Agent | Section 9.9 |
409 +---------------------+------------------------+
411 4. Status Code and Reason Phrase
413 The Status-Code element is a 3-digit integer result code of the
414 attempt to understand and satisfy the request.
416 The Reason-Phrase is intended to give a short textual description of
417 the Status-Code and is intended for a human user. The client does
418 not need to examine or display the Reason-Phrase.
420 Status-Code = 3DIGIT
421 Reason-Phrase = *( WSP / VCHAR / obs-text )
423 HTTP status codes are extensible. HTTP applications are not required
424 to understand the meaning of all registered status codes, though such
425 understanding is obviously desirable. However, applications MUST
426 understand the class of any status code, as indicated by the first
427 digit, and treat any unrecognized response as being equivalent to the
428 x00 status code of that class, with the exception that an
429 unrecognized response MUST NOT be cached. For example, if an
430 unrecognized status code of 431 is received by the client, it can
431 safely assume that there was something wrong with its request and
432 treat the response as if it had received a 400 status code. In such
433 cases, user agents SHOULD present to the user the representation
434 enclosed with the response, since that representation is likely to
435 include human-readable information which will explain the unusual
436 status.
438 4.1. Overview of Status Codes
440 The status codes listed below are defined in Section 8 of this
441 specification, Section 4 of [Part4], Section 3 of [Part5], and
442 Section 3 of [Part7]. The reason phrases listed here are only
443 recommendations -- they can be replaced by local equivalents without
444 affecting the protocol.
446 +-------------+------------------------------+----------------------+
447 | Status-Code | Reason-Phrase | Defined in... |
448 +-------------+------------------------------+----------------------+
449 | 100 | Continue | Section 8.1.1 |
450 | 101 | Switching Protocols | Section 8.1.2 |
451 | 200 | OK | Section 8.2.1 |
452 | 201 | Created | Section 8.2.2 |
453 | 202 | Accepted | Section 8.2.3 |
454 | 203 | Non-Authoritative | Section 8.2.4 |
455 | | Information | |
456 | 204 | No Content | Section 8.2.5 |
457 | 205 | Reset Content | Section 8.2.6 |
458 | 206 | Partial Content | Section 3.1 of |
459 | | | [Part5] |
460 | 300 | Multiple Choices | Section 8.3.1 |
461 | 301 | Moved Permanently | Section 8.3.2 |
462 | 302 | Found | Section 8.3.3 |
463 | 303 | See Other | Section 8.3.4 |
464 | 304 | Not Modified | Section 4.1 of |
465 | | | [Part4] |
466 | 305 | Use Proxy | Section 8.3.6 |
467 | 307 | Temporary Redirect | Section 8.3.8 |
468 | 400 | Bad Request | Section 8.4.1 |
469 | 401 | Unauthorized | Section 3.1 of |
470 | | | [Part7] |
471 | 402 | Payment Required | Section 8.4.3 |
472 | 403 | Forbidden | Section 8.4.4 |
473 | 404 | Not Found | Section 8.4.5 |
474 | 405 | Method Not Allowed | Section 8.4.6 |
475 | 406 | Not Acceptable | Section 8.4.7 |
476 | 407 | Proxy Authentication | Section 3.2 of |
477 | | Required | [Part7] |
478 | 408 | Request Time-out | Section 8.4.9 |
479 | 409 | Conflict | Section 8.4.10 |
480 | 410 | Gone | Section 8.4.11 |
481 | 411 | Length Required | Section 8.4.12 |
482 | 412 | Precondition Failed | Section 4.2 of |
483 | | | [Part4] |
484 | 413 | Request Entity Too Large | Section 8.4.14 |
485 | 414 | URI Too Long | Section 8.4.15 |
486 | 415 | Unsupported Media Type | Section 8.4.16 |
487 | 416 | Requested range not | Section 3.2 of |
488 | | satisfiable | [Part5] |
489 | 417 | Expectation Failed | Section 8.4.18 |
490 | 426 | Upgrade Required | Section 8.4.19 |
491 | 500 | Internal Server Error | Section 8.5.1 |
492 | 501 | Not Implemented | Section 8.5.2 |
493 | 502 | Bad Gateway | Section 8.5.3 |
494 | 503 | Service Unavailable | Section 8.5.4 |
495 | 504 | Gateway Time-out | Section 8.5.5 |
496 | 505 | HTTP Version not supported | Section 8.5.6 |
497 +-------------+------------------------------+----------------------+
499 Note that this list is not exhaustive -- it does not include
500 extension status codes defined in other specifications.
502 4.2. Status Code Registry
504 The HTTP Status Code Registry defines the name space for the Status-
505 Code token in the Status-Line of an HTTP response.
507 Values to be added to this name space are subject to IETF review
508 ([RFC5226], Section 4.1).
510 The registry itself is maintained at
511 .
513 4.2.1. Considerations for New Status Codes
515 When it is necessary to express new semantics for a HTTP response
516 that aren't specific to a single application or media type, and
517 currently defined status codes are inadequate, a new status code can
518 be registered.
520 HTTP status codes are generic; that is, they are potentially
521 applicable to any resource, not just one particular media type,
522 "type" of resource, or application. As such, it is preferred that
523 new HTTP status codes be registered in a document that isn't specific
524 to a single application, so that this is clear.
526 Definitions of new HTTP status codes typically explain the request
527 conditions that produce a response containing the status code (e.g.,
528 combinations of request headers and/or method(s)), along with any
529 interactions with response headers (e.g., those that are required,
530 those that modify the semantics of the response).
532 New HTTP status codes are required to fall under one of the
533 categories defined in Section 8. To allow existing parsers to
534 properly handle them, new status codes cannot disallow a response
535 body, although they can mandate a zero-length response body. They
536 can require the presence of one or more particular HTTP response
537 header(s).
539 Likewise, their definitions can specify that caches are allowed to
540 use heuristics to determine their freshness (see [Part6]; by default,
541 it is not allowed), and can define how to determine the resource
542 which they carry a representation for (see Section 6.1; by default,
543 it is anonymous).
545 5. Response Header Fields
547 The response header fields allow the server to pass additional
548 information about the response which cannot be placed in the Status-
549 Line. These header fields give information about the server and
550 about further access to the target resource (Section 4.3 of [Part1]).
552 +--------------------+------------------------+
553 | Header Field Name | Defined in... |
554 +--------------------+------------------------+
555 | Accept-Ranges | Section 5.1 of [Part5] |
556 | Age | Section 3.1 of [Part6] |
557 | Allow | Section 9.1 |
558 | ETag | Section 2.2 of [Part4] |
559 | Location | Section 9.4 |
560 | Proxy-Authenticate | Section 4.2 of [Part7] |
561 | Retry-After | Section 9.7 |
562 | Server | Section 9.8 |
563 | Vary | Section 3.5 of [Part6] |
564 | WWW-Authenticate | Section 4.4 of [Part7] |
565 +--------------------+------------------------+
567 6. Representation
569 Request and Response messages MAY transfer a representation if not
570 otherwise restricted by the request method or response status code.
571 A representation consists of metadata (representation header fields)
572 and data (representation body). When a complete or partial
573 representation is enclosed in an HTTP message, it is referred to as
574 the payload of the message. HTTP representations are defined in
575 [Part3].
577 A representation body is only present in a message when a message-
578 body is present, as described in Section 3.3 of [Part1]. The
579 representation body is obtained from the message-body by decoding any
580 Transfer-Encoding that might have been applied to ensure safe and
581 proper transfer of the message.
583 6.1. Identifying the Resource Associated with a Representation
585 It is sometimes necessary to determine an identifier for the resource
586 associated with a representation.
588 An HTTP request representation, when present, is always associated
589 with an anonymous (i.e., unidentified) resource.
591 In the common case, an HTTP response is a representation of the
592 target resource (see Section 4.3 of [Part1]). However, this is not
593 always the case. To determine the URI of the resource a response is
594 associated with, the following rules are used (with the first
595 applicable one being selected):
597 1. If the response status code is 200 or 203 and the request method
598 was GET, the response payload is a representation of the target
599 resource.
601 2. If the response status code is 204, 206, or 304 and the request
602 method was GET or HEAD, the response payload is a partial
603 representation of the target resource (see Section 2.8 of
604 [Part6]).
606 3. If the response has a Content-Location header field, and that URI
607 is the same as the effective request URI, the response payload is
608 a representation of the target resource.
610 4. If the response has a Content-Location header field, and that URI
611 is not the same as the effective request URI, then the response
612 asserts that its payload is a representation of the resource
613 identified by the Content-Location URI. However, such an
614 assertion cannot be trusted unless it can be verified by other
615 means (not defined by HTTP).
617 5. Otherwise, the response is a representation of an anonymous
618 (i.e., unidentified) resource.
620 [[TODO-req-uri: The comparison function is going to have to be
621 defined somewhere, because we already need to compare URIs for things
622 like cache invalidation.]]
624 7. Method Definitions
626 The set of common request methods for HTTP/1.1 is defined below.
627 Although this set can be expanded, additional methods cannot be
628 assumed to share the same semantics for separately extended clients
629 and servers.
631 7.1. Safe and Idempotent Methods
633 7.1.1. Safe Methods
635 Implementors need to be aware that the software represents the user
636 in their interactions over the Internet, and need to allow the user
637 to be aware of any actions they take which might have an unexpected
638 significance to themselves or others.
640 In particular, the convention has been established that the GET,
641 HEAD, OPTIONS, and TRACE request methods SHOULD NOT have the
642 significance of taking an action other than retrieval. These request
643 methods ought to be considered "safe". This allows user agents to
644 represent other methods, such as POST, PUT and DELETE, in a special
645 way, so that the user is made aware of the fact that a possibly
646 unsafe action is being requested.
648 Naturally, it is not possible to ensure that the server does not
649 generate side-effects as a result of performing a GET request; in
650 fact, some dynamic resources consider that a feature. The important
651 distinction here is that the user did not request the side-effects,
652 so therefore cannot be held accountable for them.
654 7.1.2. Idempotent Methods
656 Request methods can also have the property of "idempotence" in that,
657 aside from error or expiration issues, the intended effect of
658 multiple identical requests is the same as for a single request.
659 PUT, DELETE, and all safe request methods are idempotent. It is
660 important to note that idempotence refers only to changes requested
661 by the client: a server is free to change its state due to multiple
662 requests for the purpose of tracking those requests, versioning of
663 results, etc.
665 7.2. OPTIONS
667 The OPTIONS method requests information about the communication
668 options available on the request/response chain identified by the
669 effective request URI. This method allows a client to determine the
670 options and/or requirements associated with a resource, or the
671 capabilities of a server, without implying a resource action or
672 initiating a resource retrieval.
674 Responses to the OPTIONS method are not cacheable.
676 If the OPTIONS request includes a message-body (as indicated by the
677 presence of Content-Length or Transfer-Encoding), then the media type
678 MUST be indicated by a Content-Type field. Although this
679 specification does not define any use for such a body, future
680 extensions to HTTP might use the OPTIONS body to make more detailed
681 queries on the server.
683 If the request-target is an asterisk ("*"), the OPTIONS request is
684 intended to apply to the server in general rather than to a specific
685 resource. Since a server's communication options typically depend on
686 the resource, the "*" request is only useful as a "ping" or "no-op"
687 type of method; it does nothing beyond allowing the client to test
688 the capabilities of the server. For example, this can be used to
689 test a proxy for HTTP/1.1 compliance (or lack thereof).
691 If the request-target is not an asterisk, the OPTIONS request applies
692 only to the options that are available when communicating with that
693 resource.
695 A 200 response SHOULD include any header fields that indicate
696 optional features implemented by the server and applicable to that
697 resource (e.g., Allow), possibly including extensions not defined by
698 this specification. The response body, if any, SHOULD also include
699 information about the communication options. The format for such a
700 body is not defined by this specification, but might be defined by
701 future extensions to HTTP. Content negotiation MAY be used to select
702 the appropriate response format. If no response body is included,
703 the response MUST include a Content-Length field with a field-value
704 of "0".
706 The Max-Forwards header field MAY be used to target a specific proxy
707 in the request chain (see Section 9.5). If no Max-Forwards field is
708 present in the request, then the forwarded request MUST NOT include a
709 Max-Forwards field.
711 7.3. GET
713 The GET method requests transfer of a current representation of the
714 target resource.
716 If the target resource is a data-producing process, it is the
717 produced data which shall be returned as the representation in the
718 response and not the source text of the process, unless that text
719 happens to be the output of the process.
721 The semantics of the GET method change to a "conditional GET" if the
722 request message includes an If-Modified-Since, If-Unmodified-Since,
723 If-Match, If-None-Match, or If-Range header field. A conditional GET
724 requests that the representation be transferred only under the
725 circumstances described by the conditional header field(s). The
726 conditional GET request is intended to reduce unnecessary network
727 usage by allowing cached representations to be refreshed without
728 requiring multiple requests or transferring data already held by the
729 client.
731 The semantics of the GET method change to a "partial GET" if the
732 request message includes a Range header field. A partial GET
733 requests that only part of the representation be transferred, as
734 described in Section 5.4 of [Part5]. The partial GET request is
735 intended to reduce unnecessary network usage by allowing partially-
736 retrieved representations to be completed without transferring data
737 already held by the client.
739 Bodies on GET requests have no defined semantics. Note that sending
740 a body on a GET request might cause some existing implementations to
741 reject the request.
743 The response to a GET request is cacheable and MAY be used to satisfy
744 subsequent GET and HEAD requests (see [Part6]).
746 See Section 11.2 for security considerations when used for forms.
748 7.4. HEAD
750 The HEAD method is identical to GET except that the server MUST NOT
751 return a message-body in the response. The metadata contained in the
752 HTTP header fields in response to a HEAD request SHOULD be identical
753 to the information sent in response to a GET request. This method
754 can be used for obtaining metadata about the representation implied
755 by the request without transferring the representation body. This
756 method is often used for testing hypertext links for validity,
757 accessibility, and recent modification.
759 The response to a HEAD request is cacheable and MAY be used to
760 satisfy a subsequent HEAD request; see [Part6]. It also MAY be used
761 to update a previously cached representation from that resource; if
762 the new field values indicate that the cached representation differs
763 from the current representation (as would be indicated by a change in
764 Content-Length, Content-MD5, ETag or Last-Modified), then the cache
765 MUST treat the cache entry as stale.
767 Bodies on HEAD requests have no defined semantics. Note that sending
768 a body on a HEAD request might cause some existing implementations to
769 reject the request.
771 7.5. POST
773 The POST method requests that the origin server accept the
774 representation enclosed in the request as data to be processed by the
775 target resource. POST is designed to allow a uniform method to cover
776 the following functions:
778 o Annotation of existing resources;
780 o Posting a message to a bulletin board, newsgroup, mailing list, or
781 similar group of articles;
783 o Providing a block of data, such as the result of submitting a
784 form, to a data-handling process;
786 o Extending a database through an append operation.
788 The actual function performed by the POST method is determined by the
789 server and is usually dependent on the effective request URI.
791 The action performed by the POST method might not result in a
792 resource that can be identified by a URI. In this case, either 200
793 (OK) or 204 (No Content) is the appropriate response status code,
794 depending on whether or not the response includes a representation
795 that describes the result.
797 If a resource has been created on the origin server, the response
798 SHOULD be 201 (Created) and contain a representation which describes
799 the status of the request and refers to the new resource, and a
800 Location header field (see Section 9.4).
802 Responses to POST requests are only cacheable when they include
803 explicit freshness information (see Section 2.3.1 of [Part6]). A
804 cached POST response with a Content-Location header field (see
805 Section 6.7 of [Part3]) whose value is the effective Request URI MAY
806 be used to satisfy subsequent GET and HEAD requests.
808 Note that POST caching is not widely implemented. However, the 303
809 (See Other) response can be used to direct the user agent to retrieve
810 a cacheable resource.
812 7.6. PUT
814 The PUT method requests that the state of the target resource be
815 created or replaced with the state defined by the representation
816 enclosed in the request message payload. A successful PUT of a given
817 representation would suggest that a subsequent GET on that same
818 target resource will result in an equivalent representation being
819 returned in a 200 (OK) response. However, there is no guarantee that
820 such a state change will be observable, since the target resource
821 might be acted upon by other user agents in parallel, or might be
822 subject to dynamic processing by the origin server, before any
823 subsequent GET is received. A successful response only implies that
824 the user agent's intent was achieved at the time of its processing by
825 the origin server.
827 If the target resource does not have a current representation and the
828 PUT successfully creates one, then the origin server MUST inform the
829 user agent by sending a 201 (Created) response. If the target
830 resource does have a current representation and that representation
831 is successfully modified in accordance with the state of the enclosed
832 representation, then either a 200 (OK) or 204 (No Content) response
833 SHOULD be sent to indicate successful completion of the request.
835 Unrecognized header fields SHOULD be ignored (i.e., not saved as part
836 of the resource state).
838 An origin server SHOULD verify that the PUT representation is
839 consistent with any constraints which the server has for the target
840 resource that cannot or will not be changed by the PUT. This is
841 particularly important when the origin server uses internal
842 configuration information related to the URI in order to set the
843 values for representation metadata on GET responses. When a PUT
844 representation is inconsistent with the target resource, the origin
845 server SHOULD either make them consistent, by transforming the
846 representation or changing the resource configuration, or respond
847 with an appropriate error message containing sufficient information
848 to explain why the representation is unsuitable. The 409 (Conflict)
849 or 415 (Unsupported Media Type) status codes are suggested, with the
850 latter being specific to constraints on Content-Type values.
852 For example, if the target resource is configured to always have a
853 Content-Type of "text/html" and the representation being PUT has a
854 Content-Type of "image/jpeg", then the origin server SHOULD do one
855 of: (a) reconfigure the target resource to reflect the new media
856 type; (b) transform the PUT representation to a format consistent
857 with that of the resource before saving it as the new resource state;
858 or, (c) reject the request with a 415 response indicating that the
859 target resource is limited to "text/html", perhaps including a link
860 to a different resource that would be a suitable target for the new
861 representation.
863 HTTP does not define exactly how a PUT method affects the state of an
864 origin server beyond what can be expressed by the intent of the user
865 agent request and the semantics of the origin server response. It
866 does not define what a resource might be, in any sense of that word,
867 beyond the interface provided via HTTP. It does not define how
868 resource state is "stored", nor how such storage might change as a
869 result of a change in resource state, nor how the origin server
870 translates resource state into representations. Generally speaking,
871 all implementation details behind the resource interface are
872 intentionally hidden by the server.
874 The fundamental difference between the POST and PUT methods is
875 highlighted by the different intent for the target resource. The
876 target resource in a POST request is intended to handle the enclosed
877 representation as a data-accepting process, such as for a gateway to
878 some other protocol or a document that accepts annotations. In
879 contrast, the target resource in a PUT request is intended to take
880 the enclosed representation as a new or replacement value. Hence,
881 the intent of PUT is idempotent and visible to intermediaries, even
882 though the exact effect is only known by the origin server.
884 Proper interpretation of a PUT request presumes that the user agent
885 knows what target resource is desired. A service that is intended to
886 select a proper URI on behalf of the client, after receiving a state-
887 changing request, SHOULD be implemented using the POST method rather
888 than PUT. If the origin server will not make the requested PUT state
889 change to the target resource and instead wishes to have it applied
890 to a different resource, such as when the resource has been moved to
891 a different URI, then the origin server MUST send a 301 (Moved
892 Permanently) response; the user agent MAY then make its own decision
893 regarding whether or not to redirect the request.
895 A PUT request applied to the target resource MAY have side-effects on
896 other resources. For example, an article might have a URI for
897 identifying "the current version" (a resource) which is separate from
898 the URIs identifying each particular version (different resources
899 that at one point shared the same state as the current version
900 resource). A successful PUT request on "the current version" URI
901 might therefore create a new version resource in addition to changing
902 the state of the target resource, and might also cause links to be
903 added between the related resources.
905 An origin server SHOULD reject any PUT request that contains a
906 Content-Range header field, since it might be misinterpreted as
907 partial content (or might be partial content that is being mistakenly
908 PUT as a full representation). Partial content updates are possible
909 by targeting a separately identified resource with state that
910 overlaps a portion of the larger resource, or by using a different
911 method that has been specifically defined for partial updates (for
912 example, the PATCH method defined in [RFC5789]).
914 Responses to the PUT method are not cacheable. If a PUT request
915 passes through a cache that has one or more stored responses for the
916 effective request URI, those stored responses will be invalidated
917 (see Section 2.5 of [Part6]).
919 7.7. DELETE
921 The DELETE method requests that the origin server delete the target
922 resource. This method MAY be overridden by human intervention (or
923 other means) on the origin server. The client cannot be guaranteed
924 that the operation has been carried out, even if the status code
925 returned from the origin server indicates that the action has been
926 completed successfully. However, the server SHOULD NOT indicate
927 success unless, at the time the response is given, it intends to
928 delete the resource or move it to an inaccessible location.
930 A successful response SHOULD be 200 (OK) if the response includes an
931 representation describing the status, 202 (Accepted) if the action
932 has not yet been enacted, or 204 (No Content) if the action has been
933 enacted but the response does not include a representation.
935 Bodies on DELETE requests have no defined semantics. Note that
936 sending a body on a DELETE request might cause some existing
937 implementations to reject the request.
939 Responses to the DELETE method are not cacheable. If a DELETE
940 request passes through a cache that has one or more stored responses
941 for the effective request URI, those stored responses will be
942 invalidated (see Section 2.5 of [Part6]).
944 7.8. TRACE
946 The TRACE method requests a remote, application-layer loop-back of
947 the request message. The final recipient of the request SHOULD
948 reflect the message received back to the client as the message-body
949 of a 200 (OK) response. The final recipient is either the origin
950 server or the first proxy to receive a Max-Forwards value of zero (0)
951 in the request (see Section 9.5). A TRACE request MUST NOT include a
952 message-body.
954 TRACE allows the client to see what is being received at the other
955 end of the request chain and use that data for testing or diagnostic
956 information. The value of the Via header field (Section 9.9 of
957 [Part1]) is of particular interest, since it acts as a trace of the
958 request chain. Use of the Max-Forwards header field allows the
959 client to limit the length of the request chain, which is useful for
960 testing a chain of proxies forwarding messages in an infinite loop.
962 If the request is valid, the response SHOULD have a Content-Type of
963 "message/http" (see Section 10.3.1 of [Part1]) and contain a message-
964 body that encloses a copy of the entire request message. Responses
965 to the TRACE method are not cacheable.
967 7.9. CONNECT
969 The CONNECT method requests that the proxy establish a tunnel to the
970 request-target and then restrict its behavior to blind forwarding of
971 packets until the connection is closed.
973 When using CONNECT, the request-target MUST use the authority form
974 (Section 4.1.2 of [Part1]); i.e., the request-target consists of only
975 the host name and port number of the tunnel destination, separated by
976 a colon. For example,
978 CONNECT server.example.com:80 HTTP/1.1
979 Host: server.example.com:80
981 Other HTTP mechanisms can be used normally with the CONNECT method --
982 except end-to-end protocol Upgrade requests, since the tunnel must be
983 established first.
985 For example, proxy authentication might be used to establish the
986 authority to create a tunnel:
988 CONNECT server.example.com:80 HTTP/1.1
989 Host: server.example.com:80
990 Proxy-Authorization: basic aGVsbG86d29ybGQ=
992 Bodies on CONNECT requests have no defined semantics. Note that
993 sending a body on a CONNECT request might cause some existing
994 implementations to reject the request.
996 Like any other pipelined HTTP/1.1 request, data to be tunnel may be
997 sent immediately after the blank line. The usual caveats also apply:
998 data may be discarded if the eventual response is negative, and the
999 connection may be reset with no response if more than one TCP segment
1000 is outstanding.
1002 7.9.1. Establishing a Tunnel with CONNECT
1004 Any successful (2xx) response to a CONNECT request indicates that the
1005 proxy has established a connection to the requested host and port,
1006 and has switched to tunneling the current connection to that server
1007 connection.
1009 It may be the case that the proxy itself can only reach the requested
1010 origin server through another proxy. In this case, the first proxy
1011 SHOULD make a CONNECT request of that next proxy, requesting a tunnel
1012 to the authority. A proxy MUST NOT respond with any 2xx status code
1013 unless it has either a direct or tunnel connection established to the
1014 authority.
1016 An origin server which receives a CONNECT request for itself MAY
1017 respond with a 2xx status code to indicate that a connection is
1018 established.
1020 If at any point either one of the peers gets disconnected, any
1021 outstanding data that came from that peer will be passed to the other
1022 one, and after that also the other connection will be terminated by
1023 the proxy. If there is outstanding data to that peer undelivered,
1024 that data will be discarded.
1026 8. Status Code Definitions
1028 Each Status-Code is described below, including any metadata required
1029 in the response.
1031 8.1. Informational 1xx
1033 This class of status code indicates a provisional response,
1034 consisting only of the Status-Line and optional header fields, and is
1035 terminated by an empty line. There are no required header fields for
1036 this class of status code. Since HTTP/1.0 did not define any 1xx
1037 status codes, servers MUST NOT send a 1xx response to an HTTP/1.0
1038 client except under experimental conditions.
1040 A client MUST be prepared to accept one or more 1xx status responses
1041 prior to a regular response, even if the client does not expect a 100
1042 (Continue) status message. Unexpected 1xx status responses MAY be
1043 ignored by a user agent.
1045 Proxies MUST forward 1xx responses, unless the connection between the
1046 proxy and its client has been closed, or unless the proxy itself
1047 requested the generation of the 1xx response. (For example, if a
1048 proxy adds a "Expect: 100-continue" field when it forwards a request,
1049 then it need not forward the corresponding 100 (Continue)
1050 response(s).)
1052 8.1.1. 100 Continue
1054 The client SHOULD continue with its request. This interim response
1055 is used to inform the client that the initial part of the request has
1056 been received and has not yet been rejected by the server. The
1057 client SHOULD continue by sending the remainder of the request or, if
1058 the request has already been completed, ignore this response. The
1059 server MUST send a final response after the request has been
1060 completed. See Section 7.2.3 of [Part1] for detailed discussion of
1061 the use and handling of this status code.
1063 8.1.2. 101 Switching Protocols
1065 The server understands and is willing to comply with the client's
1066 request, via the Upgrade message header field (Section 9.8 of
1067 [Part1]), for a change in the application protocol being used on this
1068 connection. The server will switch protocols to those defined by the
1069 response's Upgrade header field immediately after the empty line
1070 which terminates the 101 response.
1072 The protocol SHOULD be switched only when it is advantageous to do
1073 so. For example, switching to a newer version of HTTP is
1074 advantageous over older versions, and switching to a real-time,
1075 synchronous protocol might be advantageous when delivering resources
1076 that use such features.
1078 8.2. Successful 2xx
1080 This class of status code indicates that the client's request was
1081 successfully received, understood, and accepted.
1083 8.2.1. 200 OK
1085 The request has succeeded. The payload returned with the response is
1086 dependent on the method used in the request, for example:
1088 GET a representation of the target resource is sent in the response;
1090 HEAD the same representation as GET, except without the message-
1091 body;
1093 POST a representation describing or containing the result of the
1094 action;
1096 TRACE a representation containing the request message as received by
1097 the end server.
1099 Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to
1100 determine freshness for 200 responses.
1102 8.2.2. 201 Created
1104 The request has been fulfilled and has resulted in a new resource
1105 being created. The newly created resource can be referenced by the
1106 URI(s) returned in the payload of the response, with the most
1107 specific URI for the resource given by a Location header field. The
1108 response SHOULD include a payload containing a list of resource
1109 characteristics and location(s) from which the user or user agent can
1110 choose the one most appropriate. The payload format is specified by
1111 the media type given in the Content-Type header field. The origin
1112 server MUST create the resource before returning the 201 status code.
1113 If the action cannot be carried out immediately, the server SHOULD
1114 respond with 202 (Accepted) response instead.
1116 A 201 response MAY contain an ETag response header field indicating
1117 the current value of the entity-tag for the representation of the
1118 resource just created (see Section 2.2 of [Part4]).
1120 8.2.3. 202 Accepted
1122 The request has been accepted for processing, but the processing has
1123 not been completed. The request might or might not eventually be
1124 acted upon, as it might be disallowed when processing actually takes
1125 place. There is no facility for re-sending a status code from an
1126 asynchronous operation such as this.
1128 The 202 response is intentionally non-committal. Its purpose is to
1129 allow a server to accept a request for some other process (perhaps a
1130 batch-oriented process that is only run once per day) without
1131 requiring that the user agent's connection to the server persist
1132 until the process is completed. The representation returned with
1133 this response SHOULD include an indication of the request's current
1134 status and either a pointer to a status monitor or some estimate of
1135 when the user can expect the request to be fulfilled.
1137 8.2.4. 203 Non-Authoritative Information
1139 The returned metadata in the header fields is not the definitive set
1140 as available from the origin server, but is gathered from a local or
1141 a third-party copy. The set presented MAY be a subset or superset of
1142 the original version. For example, including local annotation
1143 information about the resource might result in a superset of the
1144 metadata known by the origin server. Use of this response code is
1145 not required and is only appropriate when the response would
1146 otherwise be 200 (OK).
1148 Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to
1149 determine freshness for 203 responses.
1151 8.2.5. 204 No Content
1153 The 204 (No Content) status code indicates that the server has
1154 successfully fulfilled the request and that there is no additional
1155 content to return in the response payload body. Metadata in the
1156 response header fields refer to the target resource and its current
1157 representation after the requested action.
1159 For example, if a 204 status code is received in response to a PUT
1160 request and the response contains an ETag header field, then the PUT
1161 was successful and the ETag field-value contains the entity-tag for
1162 the new representation of that target resource.
1164 The 204 response allows a server to indicate that the action has been
1165 successfully applied to the target resource while implying that the
1166 user agent SHOULD NOT traverse away from its current "document view"
1167 (if any). The server assumes that the user agent will provide some
1168 indication of the success to its user, in accord with its own
1169 interface, and apply any new or updated metadata in the response to
1170 the active representation. For example, a 204 status code is
1171 commonly used with document editing interfaces corresponding to a
1172 "save" action, such that the document being saved remains available
1173 to the user for editing. It is also frequently used with interfaces
1174 that expect automated data transfers to be prevalent, such as within
1175 distributed version control systems.
1177 The 204 response MUST NOT include a message-body, and thus is always
1178 terminated by the first empty line after the header fields.
1180 8.2.6. 205 Reset Content
1182 The server has fulfilled the request and the user agent SHOULD reset
1183 the document view which caused the request to be sent. This response
1184 is primarily intended to allow input for actions to take place via
1185 user input, followed by a clearing of the form in which the input is
1186 given so that the user can easily initiate another input action.
1188 The message-body included with the response MUST be empty. Note that
1189 receivers still need to parse the response according to the algorithm
1190 defined in Section 3.3 of [Part1].
1192 8.2.7. 206 Partial Content
1194 The server has fulfilled the partial GET request for the resource and
1195 the enclosed payload is a partial representation as defined in
1196 Section 3.1 of [Part5].
1198 Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to
1199 determine freshness for 206 responses.
1201 8.3. Redirection 3xx
1203 This class of status code indicates that further action needs to be
1204 taken by the user agent in order to fulfill the request. The action
1205 required MAY be carried out by the user agent without interaction
1206 with the user if and only if the method used in the second request is
1207 known to be "safe", as defined in Section 7.1.1. A client SHOULD
1208 detect infinite redirection loops, since such loops generate network
1209 traffic for each redirection.
1211 Note: An earlier version of this specification recommended a
1212 maximum of five redirections ([RFC2068], Section 10.3). Content
1213 developers need to be aware that some clients might implement such
1214 a fixed limitation.
1216 8.3.1. 300 Multiple Choices
1218 The target resource has more than one representation, each with its
1219 own specific location, and agent-driven negotiation information
1220 (Section 5 of [Part3]) is being provided so that the user (or user
1221 agent) can select a preferred representation by redirecting its
1222 request to that location.
1224 Unless it was a HEAD request, the response SHOULD include a
1225 representation containing a list of representation metadata and
1226 location(s) from which the user or user agent can choose the one most
1227 appropriate. The data format is specified by the media type given in
1228 the Content-Type header field. Depending upon the format and the
1229 capabilities of the user agent, selection of the most appropriate
1230 choice MAY be performed automatically. However, this specification
1231 does not define any standard for such automatic selection.
1233 If the server has a preferred choice of representation, it SHOULD
1234 include the specific URI for that representation in the Location
1235 field; user agents MAY use the Location field value for automatic
1236 redirection.
1238 Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to
1239 determine freshness for 300 responses.
1241 8.3.2. 301 Moved Permanently
1243 The target resource has been assigned a new permanent URI and any
1244 future references to this resource SHOULD use one of the returned
1245 URIs. Clients with link editing capabilities ought to automatically
1246 re-link references to the effective request URI to one or more of the
1247 new references returned by the server, where possible.
1249 Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to
1250 determine freshness for 301 responses.
1252 The new permanent URI SHOULD be given by the Location field in the
1253 response. Unless the request method was HEAD, the representation of
1254 the response SHOULD contain a short hypertext note with a hyperlink
1255 to the new URI(s).
1257 If the 301 status code is received in response to a request method
1258 that is known to be "safe", as defined in Section 7.1.1, then the
1259 request MAY be automatically redirected by the user agent without
1260 confirmation. Otherwise, the user agent MUST NOT automatically
1261 redirect the request unless it can be confirmed by the user, since
1262 this might change the conditions under which the request was issued.
1264 Note: When automatically redirecting a POST request after
1265 receiving a 301 status code, some existing HTTP/1.0 user agents
1266 will erroneously change it into a GET request.
1268 8.3.3. 302 Found
1270 The target resource resides temporarily under a different URI. Since
1271 the redirection might be altered on occasion, the client SHOULD
1272 continue to use the effective request URI for future requests.
1274 The temporary URI SHOULD be given by the Location field in the
1275 response. Unless the request method was HEAD, the representation of
1276 the response SHOULD contain a short hypertext note with a hyperlink
1277 to the new URI(s).
1279 If the 302 status code is received in response to a request method
1280 that is known to be "safe", as defined in Section 7.1.1, then the
1281 request MAY be automatically redirected by the user agent without
1282 confirmation. Otherwise, the user agent MUST NOT automatically
1283 redirect the request unless it can be confirmed by the user, since
1284 this might change the conditions under which the request was issued.
1286 Note: HTTP/1.0 ([RFC1945], Section 9.3) and the first version of
1287 HTTP/1.1 ([RFC2068], Section 10.3.3) specify that the client is
1288 not allowed to change the method on the redirected request.
1289 However, most existing user agent implementations treat 302 as if
1290 it were a 303 response, performing a GET on the Location field-
1291 value regardless of the original request method. Therefore, a
1292 previous version of this specification ([RFC2616], Section 10.3.3)
1293 has added the status codes 303 and 307 for servers that wish to
1294 make unambiguously clear which kind of reaction is expected of the
1295 client.
1297 8.3.4. 303 See Other
1299 The server directs the user agent to a different resource, indicated
1300 by a URI in the Location header field, that provides an indirect
1301 response to the original request. The user agent MAY perform a GET
1302 request on the URI in the Location field in order to obtain a
1303 representation corresponding to the response, be redirected again, or
1304 end with an error status. The Location URI is not a substitute
1305 reference for the effective request URI.
1307 The 303 status code is generally applicable to any HTTP method. It
1308 is primarily used to allow the output of a POST action to redirect
1309 the user agent to a selected resource, since doing so provides the
1310 information corresponding to the POST response in a form that can be
1311 separately identified, bookmarked, and cached independent of the
1312 original request.
1314 A 303 response to a GET request indicates that the requested resource
1315 does not have a representation of its own that can be transferred by
1316 the server over HTTP. The Location URI indicates a resource that is
1317 descriptive of the target resource, such that the follow-on
1318 representation might be useful to recipients without implying that it
1319 adequately represents the target resource. Note that answers to the
1320 questions of what can be represented, what representations are
1321 adequate, and what might be a useful description are outside the
1322 scope of HTTP and thus entirely determined by the URI owner(s).
1324 Except for responses to a HEAD request, the representation of a 303
1325 response SHOULD contain a short hypertext note with a hyperlink to
1326 the Location URI.
1328 8.3.5. 304 Not Modified
1330 The response to the request has not been modified since the
1331 conditions indicated by the client's conditional GET request, as
1332 defined in Section 4.1 of [Part4].
1334 8.3.6. 305 Use Proxy
1336 The 305 status code was defined in a previous version of this
1337 specification (see Appendix A), and is now deprecated.
1339 8.3.7. 306 (Unused)
1341 The 306 status code was used in a previous version of the
1342 specification, is no longer used, and the code is reserved.
1344 8.3.8. 307 Temporary Redirect
1346 The target resource resides temporarily under a different URI. Since
1347 the redirection can change over time, the client SHOULD continue to
1348 use the effective request URI for future requests.
1350 The temporary URI SHOULD be given by the Location field in the
1351 response. Unless the request method was HEAD, the representation of
1352 the response SHOULD contain a short hypertext note with a hyperlink
1353 to the new URI(s), since many pre-HTTP/1.1 user agents do not
1354 understand the 307 status code. Therefore, the note SHOULD contain
1355 the information necessary for a user to repeat the original request
1356 on the new URI.
1358 If the 307 status code is received in response to a request method
1359 that is known to be "safe", as defined in Section 7.1.1, then the
1360 request MAY be automatically redirected by the user agent without
1361 confirmation. Otherwise, the user agent MUST NOT automatically
1362 redirect the request unless it can be confirmed by the user, since
1363 this might change the conditions under which the request was issued.
1365 8.4. Client Error 4xx
1367 The 4xx class of status code is intended for cases in which the
1368 client seems to have erred. Except when responding to a HEAD
1369 request, the server SHOULD include a representation containing an
1370 explanation of the error situation, and whether it is a temporary or
1371 permanent condition. These status codes are applicable to any
1372 request method. User agents SHOULD display any included
1373 representation to the user.
1375 If the client is sending data, a server implementation using TCP
1376 SHOULD be careful to ensure that the client acknowledges receipt of
1377 the packet(s) containing the response, before the server closes the
1378 input connection. If the client continues sending data to the server
1379 after the close, the server's TCP stack will send a reset packet to
1380 the client, which might erase the client's unacknowledged input
1381 buffers before they can be read and interpreted by the HTTP
1382 application.
1384 8.4.1. 400 Bad Request
1386 The request could not be understood by the server due to malformed
1387 syntax. The client SHOULD NOT repeat the request without
1388 modifications.
1390 8.4.2. 401 Unauthorized
1392 The request requires user authentication (see Section 3.1 of
1393 [Part7]).
1395 8.4.3. 402 Payment Required
1397 This code is reserved for future use.
1399 8.4.4. 403 Forbidden
1401 The server understood the request, but is refusing to fulfill it.
1402 Authorization will not help and the request SHOULD NOT be repeated.
1404 If the request method was not HEAD and the server wishes to make
1405 public why the request has not been fulfilled, it SHOULD describe the
1406 reason for the refusal in the representation. If the server does not
1407 wish to make this information available to the client, the status
1408 code 404 (Not Found) can be used instead.
1410 8.4.5. 404 Not Found
1412 The server has not found anything matching the effective request URI.
1413 No indication is given of whether the condition is temporary or
1414 permanent. The 410 (Gone) status code SHOULD be used if the server
1415 knows, through some internally configurable mechanism, that an old
1416 resource is permanently unavailable and has no forwarding address.
1417 This status code is commonly used when the server does not wish to
1418 reveal exactly why the request has been refused, or when no other
1419 response is applicable.
1421 8.4.6. 405 Method Not Allowed
1423 The method specified in the Request-Line is not allowed for the
1424 target resource. The response MUST include an Allow header field
1425 containing a list of valid methods for the requested resource.
1427 8.4.7. 406 Not Acceptable
1429 The resource identified by the request is only capable of generating
1430 response representations which have content characteristics not
1431 acceptable according to the accept header fields sent in the request.
1433 Unless it was a HEAD request, the response SHOULD include a
1434 representation containing a list of available representation
1435 characteristics and location(s) from which the user or user agent can
1436 choose the one most appropriate. The data format is specified by the
1437 media type given in the Content-Type header field. Depending upon
1438 the format and the capabilities of the user agent, selection of the
1439 most appropriate choice MAY be performed automatically. However,
1440 this specification does not define any standard for such automatic
1441 selection.
1443 Note: HTTP/1.1 servers are allowed to return responses which are
1444 not acceptable according to the accept header fields sent in the
1445 request. In some cases, this might even be preferable to sending
1446 a 406 response. User agents are encouraged to inspect the header
1447 fields of an incoming response to determine if it is acceptable.
1449 If the response could be unacceptable, a user agent SHOULD
1450 temporarily stop receipt of more data and query the user for a
1451 decision on further actions.
1453 8.4.8. 407 Proxy Authentication Required
1455 This code is similar to 401 (Unauthorized), but indicates that the
1456 client must first authenticate itself with the proxy (see Section 3.2
1457 of [Part7]).
1459 8.4.9. 408 Request Timeout
1461 The client did not produce a request within the time that the server
1462 was prepared to wait. The client MAY repeat the request without
1463 modifications at any later time.
1465 8.4.10. 409 Conflict
1467 The request could not be completed due to a conflict with the current
1468 state of the resource. This code is only allowed in situations where
1469 it is expected that the user might be able to resolve the conflict
1470 and resubmit the request. The response body SHOULD include enough
1471 information for the user to recognize the source of the conflict.
1472 Ideally, the response representation would include enough information
1473 for the user or user agent to fix the problem; however, that might
1474 not be possible and is not required.
1476 Conflicts are most likely to occur in response to a PUT request. For
1477 example, if versioning were being used and the representation being
1478 PUT included changes to a resource which conflict with those made by
1479 an earlier (third-party) request, the server might use the 409
1480 response to indicate that it can't complete the request. In this
1481 case, the response representation would likely contain a list of the
1482 differences between the two versions in a format defined by the
1483 response Content-Type.
1485 8.4.11. 410 Gone
1487 The target resource is no longer available at the server and no
1488 forwarding address is known. This condition is expected to be
1489 considered permanent. Clients with link editing capabilities SHOULD
1490 delete references to the effective request URI after user approval.
1491 If the server does not know, or has no facility to determine, whether
1492 or not the condition is permanent, the status code 404 (Not Found)
1493 SHOULD be used instead.
1495 The 410 response is primarily intended to assist the task of web
1496 maintenance by notifying the recipient that the resource is
1497 intentionally unavailable and that the server owners desire that
1498 remote links to that resource be removed. Such an event is common
1499 for limited-time, promotional services and for resources belonging to
1500 individuals no longer working at the server's site. It is not
1501 necessary to mark all permanently unavailable resources as "gone" or
1502 to keep the mark for any length of time -- that is left to the
1503 discretion of the server owner.
1505 Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to
1506 determine freshness for 410 responses.
1508 8.4.12. 411 Length Required
1510 The server refuses to accept the request without a defined Content-
1511 Length. The client MAY repeat the request if it adds a valid
1512 Content-Length header field containing the length of the message-body
1513 in the request message.
1515 8.4.13. 412 Precondition Failed
1517 The precondition given in one or more of the header fields evaluated
1518 to false when it was tested on the server, as defined in Section 4.2
1519 of [Part4].
1521 8.4.14. 413 Request Entity Too Large
1523 The server is refusing to process a request because the request
1524 representation is larger than the server is willing or able to
1525 process. The server MAY close the connection to prevent the client
1526 from continuing the request.
1528 If the condition is temporary, the server SHOULD include a Retry-
1529 After header field to indicate that it is temporary and after what
1530 time the client MAY try again.
1532 8.4.15. 414 URI Too Long
1534 The server is refusing to service the request because the effective
1535 request URI is longer than the server is willing to interpret. This
1536 rare condition is only likely to occur when a client has improperly
1537 converted a POST request to a GET request with long query
1538 information, when the client has descended into a URI "black hole" of
1539 redirection (e.g., a redirected URI prefix that points to a suffix of
1540 itself), or when the server is under attack by a client attempting to
1541 exploit security holes present in some servers using fixed-length
1542 buffers for reading or manipulating the effective request URI.
1544 8.4.16. 415 Unsupported Media Type
1546 The server is refusing to service the request because the request
1547 payload is in a format not supported by this request method on the
1548 target resource.
1550 8.4.17. 416 Requested Range Not Satisfiable
1552 The request included a Range header field (Section 5.4 of [Part5])
1553 and none of the range-specifier values in this field overlap the
1554 current extent of the selected resource. See Section 3.2 of [Part5].
1556 8.4.18. 417 Expectation Failed
1558 The expectation given in an Expect header field (see Section 9.2)
1559 could not be met by this server, or, if the server is a proxy, the
1560 server has unambiguous evidence that the request could not be met by
1561 the next-hop server.
1563 8.4.19. 426 Upgrade Required
1565 The request can not be completed without a prior protocol upgrade.
1566 This response MUST include an Upgrade header field (Section 9.8 of
1567 [Part1]) specifying the required protocols.
1569 Example:
1571 HTTP/1.1 426 Upgrade Required
1572 Upgrade: HTTP/2.0
1573 Connection: Upgrade
1575 The server SHOULD include a message body in the 426 response which
1576 indicates in human readable form the reason for the error and
1577 describes any alternative courses which may be available to the user.
1579 8.5. Server Error 5xx
1581 Response status codes beginning with the digit "5" indicate cases in
1582 which the server is aware that it has erred or is incapable of
1583 performing the request. Except when responding to a HEAD request,
1584 the server SHOULD include a representation containing an explanation
1585 of the error situation, and whether it is a temporary or permanent
1586 condition. User agents SHOULD display any included representation to
1587 the user. These response codes are applicable to any request method.
1589 8.5.1. 500 Internal Server Error
1591 The server encountered an unexpected condition which prevented it
1592 from fulfilling the request.
1594 8.5.2. 501 Not Implemented
1596 The server does not support the functionality required to fulfill the
1597 request. This is the appropriate response when the server does not
1598 recognize the request method and is not capable of supporting it for
1599 any resource.
1601 8.5.3. 502 Bad Gateway
1603 The server, while acting as a gateway or proxy, received an invalid
1604 response from the upstream server it accessed in attempting to
1605 fulfill the request.
1607 8.5.4. 503 Service Unavailable
1609 The server is currently unable to handle the request due to a
1610 temporary overloading or maintenance of the server. The implication
1611 is that this is a temporary condition which will be alleviated after
1612 some delay. If known, the length of the delay MAY be indicated in a
1613 Retry-After header field. If no Retry-After is given, the client
1614 SHOULD handle the response as it would for a 500 response.
1616 Note: The existence of the 503 status code does not imply that a
1617 server must use it when becoming overloaded. Some servers might
1618 wish to simply refuse the connection.
1620 8.5.5. 504 Gateway Timeout
1622 The server, while acting as a gateway or proxy, did not receive a
1623 timely response from the upstream server specified by the URI (e.g.,
1624 HTTP, FTP, LDAP) or some other auxiliary server (e.g., DNS) it needed
1625 to access in attempting to complete the request.
1627 Note to implementors: some deployed proxies are known to return
1628 400 or 500 when DNS lookups time out.
1630 8.5.6. 505 HTTP Version Not Supported
1632 The server does not support, or refuses to support, the protocol
1633 version that was used in the request message. The server is
1634 indicating that it is unable or unwilling to complete the request
1635 using the same major version as the client, as described in Section
1636 2.5 of [Part1], other than with this error message. The response
1637 SHOULD contain a representation describing why that version is not
1638 supported and what other protocols are supported by that server.
1640 9. Header Field Definitions
1642 This section defines the syntax and semantics of HTTP/1.1 header
1643 fields related to request and response semantics.
1645 9.1. Allow
1647 The "Allow" header field lists the set of methods advertised as
1648 supported by the target resource. The purpose of this field is
1649 strictly to inform the recipient of valid request methods associated
1650 with the resource.
1652 Allow = #Method
1654 Example of use:
1656 Allow: GET, HEAD, PUT
1658 The actual set of allowed methods is defined by the origin server at
1659 the time of each request.
1661 A proxy MUST NOT modify the Allow header field -- it does not need to
1662 understand all the methods specified in order to handle them
1663 according to the generic message handling rules.
1665 9.2. Expect
1667 The "Expect" header field is used to indicate that particular server
1668 behaviors are required by the client.
1670 Expect = 1#expectation
1672 expectation = "100-continue" / expectation-extension
1673 expectation-extension = token [ "=" ( token / quoted-string )
1674 *expect-params ]
1675 expect-params = ";" token [ "=" ( token / quoted-string ) ]
1677 A server that does not understand or is unable to comply with any of
1678 the expectation values in the Expect field of a request MUST respond
1679 with appropriate error status code. The server MUST respond with a
1680 417 (Expectation Failed) status code if any of the expectations
1681 cannot be met or, if there are other problems with the request, some
1682 other 4xx status code.
1684 This header field is defined with extensible syntax to allow for
1685 future extensions. If a server receives a request containing an
1686 Expect field that includes an expectation-extension that it does not
1687 support, it MUST respond with a 417 (Expectation Failed) status code.
1689 Comparison of expectation values is case-insensitive for unquoted
1690 tokens (including the 100-continue token), and is case-sensitive for
1691 quoted-string expectation-extensions.
1693 The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy MUST
1694 return a 417 (Expectation Failed) status code if it receives a
1695 request with an expectation that it cannot meet. However, the Expect
1696 header field itself is end-to-end; it MUST be forwarded if the
1697 request is forwarded.
1699 Many older HTTP/1.0 and HTTP/1.1 applications do not understand the
1700 Expect header field.
1702 See Section 7.2.3 of [Part1] for the use of the 100 (Continue) status
1703 code.
1705 9.3. From
1707 The "From" header field, if given, SHOULD contain an Internet e-mail
1708 address for the human user who controls the requesting user agent.
1709 The address SHOULD be machine-usable, as defined by "mailbox" in
1710 Section 3.4 of [RFC5322]:
1712 From = mailbox
1714 mailbox =
1716 An example is:
1718 From: webmaster@example.org
1720 This header field MAY be used for logging purposes and as a means for
1721 identifying the source of invalid or unwanted requests. It SHOULD
1722 NOT be used as an insecure form of access protection. The
1723 interpretation of this field is that the request is being performed
1724 on behalf of the person given, who accepts responsibility for the
1725 method performed. In particular, robot agents SHOULD include this
1726 header field so that the person responsible for running the robot can
1727 be contacted if problems occur on the receiving end.
1729 The Internet e-mail address in this field MAY be separate from the
1730 Internet host which issued the request. For example, when a request
1731 is passed through a proxy the original issuer's address SHOULD be
1732 used.
1734 The client SHOULD NOT send the From header field without the user's
1735 approval, as it might conflict with the user's privacy interests or
1736 their site's security policy. It is strongly recommended that the
1737 user be able to disable, enable, and modify the value of this field
1738 at any time prior to a request.
1740 9.4. Location
1742 The "Location" header field is used to identify a newly created
1743 resource, or to redirect the recipient to a different location for
1744 completion of the request.
1746 For 201 (Created) responses, the Location is the URI of the new
1747 resource which was created by the request. For 3xx responses, the
1748 location SHOULD indicate the server's preferred URI for automatic
1749 redirection to the resource.
1751 The field value consists of a single URI-reference. When it has the
1752 form of a relative reference ([RFC3986], Section 4.2), the final
1753 value is computed by resolving it against the effective request URI
1754 ([RFC3986], Section 5).
1756 Location = URI-reference
1758 Examples are:
1760 Location: http://www.example.org/pub/WWW/People.html#tim
1762 Location: /index.html
1764 There are circumstances in which a fragment identifier in a Location
1765 URI would not be appropriate:
1767 o With a 201 Created response, because in this usage the Location
1768 header field specifies the URI for the entire created resource.
1770 o With 305 Use Proxy.
1772 Note: This specification does not define precedence rules for the
1773 case where the original URI, as navigated to by the user agent,
1774 and the Location header field value both contain fragment
1775 identifiers. Thus be aware that including fragment identifiers
1776 might inconvenience anyone relying on the semantics of the
1777 original URI's fragment identifier.
1779 Note: The Content-Location header field (Section 6.7 of [Part3])
1780 differs from Location in that the Content-Location identifies the
1781 most specific resource corresponding to the enclosed
1782 representation. It is therefore possible for a response to
1783 contain header fields for both Location and Content-Location.
1785 9.5. Max-Forwards
1787 The "Max-Forwards" header field provides a mechanism with the TRACE
1788 (Section 7.8) and OPTIONS (Section 7.2) methods to limit the number
1789 of times that the request is forwarded by proxies. This can be
1790 useful when the client is attempting to trace a request which appears
1791 to be failing or looping in mid-chain.
1793 Max-Forwards = 1*DIGIT
1795 The Max-Forwards value is a decimal integer indicating the remaining
1796 number of times this request message can be forwarded.
1798 Each recipient of a TRACE or OPTIONS request containing a Max-
1799 Forwards header field MUST check and update its value prior to
1800 forwarding the request. If the received value is zero (0), the
1801 recipient MUST NOT forward the request; instead, it MUST respond as
1802 the final recipient. If the received Max-Forwards value is greater
1803 than zero, then the forwarded message MUST contain an updated Max-
1804 Forwards field with a value decremented by one (1).
1806 The Max-Forwards header field MAY be ignored for all other request
1807 methods.
1809 9.6. Referer
1811 The "Referer" [sic] header field allows the client to specify the URI
1812 of the resource from which the effective request URI was obtained
1813 (the "referrer", although the header field is misspelled.).
1815 The Referer header field allows servers to generate lists of back-
1816 links to resources for interest, logging, optimized caching, etc. It
1817 also allows obsolete or mistyped links to be traced for maintenance.
1818 Some servers use Referer as a means of controlling where they allow
1819 links from (so-called "deep linking"), but legitimate requests do not
1820 always contain a Referer header field.
1822 If the effective request URI was obtained from a source that does not
1823 have its own URI (e.g., input from the user keyboard), the Referer
1824 field MUST either be sent with the value "about:blank", or not be
1825 sent at all. Note that this requirement does not apply to sources
1826 with non-HTTP URIs (e.g., FTP).
1828 Referer = absolute-URI / partial-URI
1830 Example:
1832 Referer: http://www.example.org/hypertext/Overview.html
1834 If the field value is a relative URI, it SHOULD be interpreted
1835 relative to the effective request URI. The URI MUST NOT include a
1836 fragment. See Section 11.2 for security considerations.
1838 9.7. Retry-After
1840 The header "Retry-After" field can be used with a 503 (Service
1841 Unavailable) response to indicate how long the service is expected to
1842 be unavailable to the requesting client. This field MAY also be used
1843 with any 3xx (Redirection) response to indicate the minimum time the
1844 user-agent is asked wait before issuing the redirected request.
1846 The value of this field can be either an HTTP-date or an integer
1847 number of seconds (in decimal) after the time of the response.
1849 Retry-After = HTTP-date / delta-seconds
1851 Time spans are non-negative decimal integers, representing time in
1852 seconds.
1854 delta-seconds = 1*DIGIT
1856 Two examples of its use are
1858 Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
1859 Retry-After: 120
1861 In the latter example, the delay is 2 minutes.
1863 9.8. Server
1865 The "Server" header field contains information about the software
1866 used by the origin server to handle the request.
1868 The field can contain multiple product tokens (Section 6.3 of
1869 [Part1]) and comments (Section 3.2 of [Part1]) identifying the server
1870 and any significant subproducts. The product tokens are listed in
1871 order of their significance for identifying the application.
1873 Server = product *( RWS ( product / comment ) )
1875 Example:
1877 Server: CERN/3.0 libwww/2.17
1879 If the response is being forwarded through a proxy, the proxy
1880 application MUST NOT modify the Server header field. Instead, it
1881 MUST include a Via field (as described in Section 9.9 of [Part1]).
1883 Note: Revealing the specific software version of the server might
1884 allow the server machine to become more vulnerable to attacks
1885 against software that is known to contain security holes. Server
1886 implementors are encouraged to make this field a configurable
1887 option.
1889 9.9. User-Agent
1891 The "User-Agent" header field contains information about the user
1892 agent originating the request. User agents SHOULD include this field
1893 with requests.
1895 Typically, it is used for statistical purposes, the tracing of
1896 protocol violations, and tailoring responses to avoid particular user
1897 agent limitations.
1899 The field can contain multiple product tokens (Section 6.3 of
1900 [Part1]) and comments (Section 3.2 of [Part1]) identifying the agent
1901 and its significant subproducts. By convention, the product tokens
1902 are listed in order of their significance for identifying the
1903 application.
1905 Because this field is usually sent on every request a user agent
1906 makes, implementations are encouraged not to include needlessly fine-
1907 grained detail, and to limit (or even prohibit) the addition of
1908 subproducts by third parties. Overly long and detailed User-Agent
1909 field values make requests larger and can also be used to identify
1910 ("fingerprint") the user against their wishes.
1912 Likewise, implementations are encouraged not to use the product
1913 tokens of other implementations in order to declare compatibility
1914 with them, as this circumvents the purpose of the field. Finally,
1915 they are encouraged not to use comments to identify products; doing
1916 so makes the field value more difficult to parse.
1918 User-Agent = product *( RWS ( product / comment ) )
1920 Example:
1922 User-Agent: CERN-LineMode/2.15 libwww/2.17b3
1924 10. IANA Considerations
1926 10.1. Method Registry
1928 The registration procedure for HTTP request methods is defined by
1929 Section 2.2 of this document.
1931 The HTTP Method Registry shall be created at
1932 and be populated with
1933 the registrations below:
1935 +---------+------+-------------+
1936 | Method | Safe | Reference |
1937 +---------+------+-------------+
1938 | CONNECT | no | Section 7.9 |
1939 | DELETE | no | Section 7.7 |
1940 | GET | yes | Section 7.3 |
1941 | HEAD | yes | Section 7.4 |
1942 | OPTIONS | yes | Section 7.2 |
1943 | POST | no | Section 7.5 |
1944 | PUT | no | Section 7.6 |
1945 | TRACE | yes | Section 7.8 |
1946 +---------+------+-------------+
1948 10.2. Status Code Registry
1950 The registration procedure for HTTP Status Codes -- previously
1951 defined in Section 7.1 of [RFC2817] -- is now defined by Section 4.2
1952 of this document.
1954 The HTTP Status Code Registry located at
1955 shall be updated
1956 with the registrations below:
1958 +-------+-------------------------------+----------------+
1959 | Value | Description | Reference |
1960 +-------+-------------------------------+----------------+
1961 | 100 | Continue | Section 8.1.1 |
1962 | 101 | Switching Protocols | Section 8.1.2 |
1963 | 200 | OK | Section 8.2.1 |
1964 | 201 | Created | Section 8.2.2 |
1965 | 202 | Accepted | Section 8.2.3 |
1966 | 203 | Non-Authoritative Information | Section 8.2.4 |
1967 | 204 | No Content | Section 8.2.5 |
1968 | 205 | Reset Content | Section 8.2.6 |
1969 | 300 | Multiple Choices | Section 8.3.1 |
1970 | 301 | Moved Permanently | Section 8.3.2 |
1971 | 302 | Found | Section 8.3.3 |
1972 | 303 | See Other | Section 8.3.4 |
1973 | 305 | Use Proxy | Section 8.3.6 |
1974 | 306 | (Unused) | Section 8.3.7 |
1975 | 307 | Temporary Redirect | Section 8.3.8 |
1976 | 400 | Bad Request | Section 8.4.1 |
1977 | 402 | Payment Required | Section 8.4.3 |
1978 | 403 | Forbidden | Section 8.4.4 |
1979 | 404 | Not Found | Section 8.4.5 |
1980 | 405 | Method Not Allowed | Section 8.4.6 |
1981 | 406 | Not Acceptable | Section 8.4.7 |
1982 | 407 | Proxy Authentication Required | Section 8.4.8 |
1983 | 408 | Request Timeout | Section 8.4.9 |
1984 | 409 | Conflict | Section 8.4.10 |
1985 | 410 | Gone | Section 8.4.11 |
1986 | 411 | Length Required | Section 8.4.12 |
1987 | 413 | Request Entity Too Large | Section 8.4.14 |
1988 | 414 | URI Too Long | Section 8.4.15 |
1989 | 415 | Unsupported Media Type | Section 8.4.16 |
1990 | 417 | Expectation Failed | Section 8.4.18 |
1991 | 426 | Upgrade Required | Section 8.4.19 |
1992 | 500 | Internal Server Error | Section 8.5.1 |
1993 | 501 | Not Implemented | Section 8.5.2 |
1994 | 502 | Bad Gateway | Section 8.5.3 |
1995 | 503 | Service Unavailable | Section 8.5.4 |
1996 | 504 | Gateway Timeout | Section 8.5.5 |
1997 | 505 | HTTP Version Not Supported | Section 8.5.6 |
1998 +-------+-------------------------------+----------------+
2000 10.3. Header Field Registration
2002 The Message Header Field Registry located at shall be
2004 updated with the permanent registrations below (see [RFC3864]):
2006 +-------------------+----------+----------+-------------+
2007 | Header Field Name | Protocol | Status | Reference |
2008 +-------------------+----------+----------+-------------+
2009 | Allow | http | standard | Section 9.1 |
2010 | Expect | http | standard | Section 9.2 |
2011 | From | http | standard | Section 9.3 |
2012 | Location | http | standard | Section 9.4 |
2013 | Max-Forwards | http | standard | Section 9.5 |
2014 | Referer | http | standard | Section 9.6 |
2015 | Retry-After | http | standard | Section 9.7 |
2016 | Server | http | standard | Section 9.8 |
2017 | User-Agent | http | standard | Section 9.9 |
2018 +-------------------+----------+----------+-------------+
2020 The change controller is: "IETF (iesg@ietf.org) - Internet
2021 Engineering Task Force".
2023 11. Security Considerations
2025 This section is meant to inform application developers, information
2026 providers, and users of the security limitations in HTTP/1.1 as
2027 described by this document. The discussion does not include
2028 definitive solutions to the problems revealed, though it does make
2029 some suggestions for reducing security risks.
2031 11.1. Transfer of Sensitive Information
2033 Like any generic data transfer protocol, HTTP cannot regulate the
2034 content of the data that is transferred, nor is there any a priori
2035 method of determining the sensitivity of any particular piece of
2036 information within the context of any given request. Therefore,
2037 applications SHOULD supply as much control over this information as
2038 possible to the provider of that information. Four header fields are
2039 worth special mention in this context: Server, Via, Referer and From.
2041 Revealing the specific software version of the server might allow the
2042 server machine to become more vulnerable to attacks against software
2043 that is known to contain security holes. Implementors SHOULD make
2044 the Server header field a configurable option.
2046 Proxies which serve as a portal through a network firewall SHOULD
2047 take special precautions regarding the transfer of header information
2048 that identifies the hosts behind the firewall. In particular, they
2049 SHOULD remove, or replace with sanitized versions, any Via fields
2050 generated behind the firewall.
2052 The Referer header field allows reading patterns to be studied and
2053 reverse links drawn. Although it can be very useful, its power can
2054 be abused if user details are not separated from the information
2055 contained in the Referer. Even when the personal information has
2056 been removed, the Referer header field might indicate a private
2057 document's URI whose publication would be inappropriate.
2059 The information sent in the From field might conflict with the user's
2060 privacy interests or their site's security policy, and hence it
2061 SHOULD NOT be transmitted without the user being able to disable,
2062 enable, and modify the contents of the field. The user MUST be able
2063 to set the contents of this field within a user preference or
2064 application defaults configuration.
2066 We suggest, though do not require, that a convenient toggle interface
2067 be provided for the user to enable or disable the sending of From and
2068 Referer information.
2070 The User-Agent (Section 9.9) or Server (Section 9.8) header fields
2071 can sometimes be used to determine that a specific client or server
2072 have a particular security hole which might be exploited.
2073 Unfortunately, this same information is often used for other valuable
2074 purposes for which HTTP currently has no better mechanism.
2076 Furthermore, the User-Agent header field may contain enough entropy
2077 to be used, possibly in conjunction with other material, to uniquely
2078 identify the user.
2080 Some request methods, like TRACE (Section 7.8), expose information
2081 that was sent in request header fields within the body of their
2082 response. Clients SHOULD be careful with sensitive information, like
2083 Cookies, Authorization credentials, and other header fields that
2084 might be used to collect data from the client.
2086 11.2. Encoding Sensitive Information in URIs
2088 Because the source of a link might be private information or might
2089 reveal an otherwise private information source, it is strongly
2090 recommended that the user be able to select whether or not the
2091 Referer field is sent. For example, a browser client could have a
2092 toggle switch for browsing openly/anonymously, which would
2093 respectively enable/disable the sending of Referer and From
2094 information.
2096 Clients SHOULD NOT include a Referer header field in a (non-secure)
2097 HTTP request if the referring page was transferred with a secure
2098 protocol.
2100 Authors of services SHOULD NOT use GET-based forms for the submission
2101 of sensitive data because that data will be placed in the request-
2102 target. Many existing servers, proxies, and user agents log or
2103 display the request-target in places where it might be visible to
2104 third parties. Such services can use POST-based form submission
2105 instead.
2107 11.3. Location Headers and Spoofing
2109 If a single server supports multiple organizations that do not trust
2110 one another, then it MUST check the values of Location and Content-
2111 Location header fields in responses that are generated under control
2112 of said organizations to make sure that they do not attempt to
2113 invalidate resources over which they have no authority.
2115 11.4. Security Considerations for CONNECT
2117 Since tunneled data is opaque to the proxy, there are additional
2118 risks to tunneling to other well-known or reserved ports. A HTTP
2119 client CONNECTing to port 25 could relay spam via SMTP, for example.
2120 As such, proxies SHOULD restrict CONNECT access to a small number of
2121 known ports.
2123 12. Acknowledgments
2125 13. References
2127 13.1. Normative References
2129 [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
2130 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
2131 and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,
2132 and Message Parsing", draft-ietf-httpbis-p1-messaging-14
2133 (work in progress), April 2011.
2135 [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
2136 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
2137 and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload
2138 and Content Negotiation", draft-ietf-httpbis-p3-payload-14
2139 (work in progress), April 2011.
2141 [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
2142 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
2143 and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional
2144 Requests", draft-ietf-httpbis-p4-conditional-14 (work in
2145 progress), April 2011.
2147 [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
2148 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
2149 and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and
2150 Partial Responses", draft-ietf-httpbis-p5-range-14 (work
2151 in progress), April 2011.
2153 [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
2154 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
2155 Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part
2156 6: Caching", draft-ietf-httpbis-p6-cache-14 (work in
2157 progress), April 2011.
2159 [Part7] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
2160 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
2161 and J. Reschke, Ed., "HTTP/1.1, part 7: Authentication",
2162 draft-ietf-httpbis-p7-auth-14 (work in progress),
2163 April 2011.
2165 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
2166 Requirement Levels", BCP 14, RFC 2119, March 1997.
2168 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
2169 Resource Identifier (URI): Generic Syntax", STD 66,
2170 RFC 3986, January 2005.
2172 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
2173 Specifications: ABNF", STD 68, RFC 5234, January 2008.
2175 13.2. Informative References
2177 [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext
2178 Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
2180 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.
2181 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
2182 RFC 2068, January 1997.
2184 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
2185 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
2186 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
2188 [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within
2189 HTTP/1.1", RFC 2817, May 2000.
2191 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
2192 Procedures for Message Header Fields", BCP 90, RFC 3864,
2193 September 2004.
2195 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
2196 IANA Considerations Section in RFCs", BCP 26, RFC 5226,
2197 May 2008.
2199 [RFC5322] Resnick, P., "Internet Message Format", RFC 5322,
2200 October 2008.
2202 [RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP",
2203 RFC 5789, March 2010.
2205 Appendix A. Changes from RFC 2616
2207 This document takes over the Status Code Registry, previously defined
2208 in Section 7.1 of [RFC2817]. (Section 4.2)
2210 Clarify definition of POST. (Section 7.5)
2212 Remove requirement to handle all Content-* header fields; ban use of
2213 Content-Range with PUT. (Section 7.6)
2215 Take over definition of CONNECT method from [RFC2817]. (Section 7.9)
2217 Failed to consider that there are many other request methods that are
2218 safe to automatically redirect, and further that the user agent is
2219 able to make that determination based on the request method
2220 semantics. (Sections 8.3.2, 8.3.3 and 8.3.8)
2222 Deprecate 305 Use Proxy status code, because user agents did not
2223 implement it. It used to indicate that the target resource must be
2224 accessed through the proxy given by the Location field. The Location
2225 field gave the URI of the proxy. The recipient was expected to
2226 repeat this single request via the proxy. (Section 8.3.6)
2228 Define status 426 (Upgrade Required) (this was incorporated from
2229 [RFC2817]). (Section 8.4.19)
2231 Change ABNF productions for header fields to only define the field
2232 value. (Section 9)
2234 Reclassify "Allow" as response header field, removing the option to
2235 specify it in a PUT request. Relax the server requirement on the
2236 contents of the Allow header field and remove requirement on clients
2237 to always trust the header field value. (Section 9.1)
2239 Correct syntax of Location header field to allow URI references
2240 (including relative references and fragments), as referred symbol
2241 "absoluteURI" wasn't what was expected, and add some clarifications
2242 as to when use of fragments would not be appropriate. (Section 9.4)
2244 Restrict Max-Forwards header field to OPTIONS and TRACE (previously,
2245 extension methods could have used it as well). (Section 9.5)
2246 Allow Referer field value of "about:blank" as alternative to not
2247 specifying it. (Section 9.6)
2249 In the description of the Server header field, the Via field was
2250 described as a SHOULD. The requirement was and is stated correctly
2251 in the description of the Via header field in Section 9.9 of [Part1].
2252 (Section 9.8)
2254 Appendix B. Collected ABNF
2255 Allow = [ ( "," / Method ) *( OWS "," [ OWS Method ] ) ]
2257 Expect = *( "," OWS ) expectation *( OWS "," [ OWS expectation ] )
2259 From = mailbox
2261 HTTP-date =
2263 Location = URI-reference
2265 Max-Forwards = 1*DIGIT
2266 Method = token
2268 OWS =
2270 RWS =
2271 Reason-Phrase = *( WSP / VCHAR / obs-text )
2272 Referer = absolute-URI / partial-URI
2273 Retry-After = HTTP-date / delta-seconds
2275 Server = product *( RWS ( product / comment ) )
2276 Status-Code = 3DIGIT
2278 URI-reference =
2279 User-Agent = product *( RWS ( product / comment ) )
2281 absolute-URI =
2283 comment =
2285 delta-seconds = 1*DIGIT
2287 expect-params = ";" token [ "=" ( token / quoted-string ) ]
2288 expectation = "100-continue" / expectation-extension
2289 expectation-extension = token [ "=" ( token / quoted-string )
2290 *expect-params ]
2292 mailbox =
2294 obs-text =
2296 partial-URI =
2297 product =
2299 quoted-string =
2301 token =
2302 ABNF diagnostics:
2304 ; Allow defined but not used
2305 ; Expect defined but not used
2306 ; From defined but not used
2307 ; Location defined but not used
2308 ; Max-Forwards defined but not used
2309 ; Reason-Phrase defined but not used
2310 ; Referer defined but not used
2311 ; Retry-After defined but not used
2312 ; Server defined but not used
2313 ; Status-Code defined but not used
2314 ; User-Agent defined but not used
2316 Appendix C. Change Log (to be removed by RFC Editor before publication)
2318 C.1. Since RFC 2616
2320 Extracted relevant partitions from [RFC2616].
2322 C.2. Since draft-ietf-httpbis-p2-semantics-00
2324 Closed issues:
2326 o : "Via is a MUST"
2327 ()
2329 o : "Fragments
2330 allowed in Location"
2331 ()
2333 o : "Safe Methods
2334 vs Redirection" ()
2336 o : "Revise
2337 description of the POST method"
2338 ()
2340 o : "Normative and
2341 Informative references"
2343 o : "RFC2606
2344 Compliance"
2346 o : "Informative
2347 references"
2349 o : "Redundant
2350 cross-references"
2352 Other changes:
2354 o Move definitions of 304 and 412 condition codes to [Part4]
2356 C.3. Since draft-ietf-httpbis-p2-semantics-01
2358 Closed issues:
2360 o : "PUT side
2361 effects"
2363 o : "Duplicate Host
2364 header requirements"
2366 Ongoing work on ABNF conversion
2367 ():
2369 o Move "Product Tokens" section (back) into Part 1, as "token" is
2370 used in the definition of the Upgrade header field.
2372 o Add explicit references to BNF syntax and rules imported from
2373 other parts of the specification.
2375 o Copy definition of delta-seconds from Part6 instead of referencing
2376 it.
2378 C.4. Since draft-ietf-httpbis-p2-semantics-02
2380 Closed issues:
2382 o : "Requiring
2383 Allow in 405 responses"
2385 o : "Status Code
2386 Registry"
2388 o : "Redirection
2389 vs. Location"
2391 o : "Cacheability
2392 of 303 response"
2394 o : "305 Use Proxy"
2395 o :
2396 "Classification for Allow header"
2398 o : "PUT - 'store
2399 under' vs 'store at'"
2401 Ongoing work on IANA Message Header Field Registration
2402 ():
2404 o Reference RFC 3984, and update header field registrations for
2405 headers defined in this document.
2407 Ongoing work on ABNF conversion
2408 ():
2410 o Replace string literals when the string really is case-sensitive
2411 (method).
2413 C.5. Since draft-ietf-httpbis-p2-semantics-03
2415 Closed issues:
2417 o : "OPTIONS
2418 request bodies"
2420 o : "Description
2421 of CONNECT should refer to RFC2817"
2423 o : "Location
2424 Content-Location reference request/response mixup"
2426 Ongoing work on Method Registry
2427 ():
2429 o Added initial proposal for registration process, plus initial
2430 content (non-HTTP/1.1 methods to be added by a separate
2431 specification).
2433 C.6. Since draft-ietf-httpbis-p2-semantics-04
2435 Closed issues:
2437 o : "Content-*"
2439 o : "RFC 2822 is
2440 updated by RFC 5322"
2442 Ongoing work on ABNF conversion
2443 ():
2445 o Use "/" instead of "|" for alternatives.
2447 o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
2448 whitespace ("OWS") and required whitespace ("RWS").
2450 o Rewrite ABNFs to spell out whitespace rules, factor out header
2451 field value format definitions.
2453 C.7. Since draft-ietf-httpbis-p2-semantics-05
2455 Closed issues:
2457 o : "Reason-Phrase
2458 BNF"
2460 Final work on ABNF conversion
2461 ():
2463 o Add appendix containing collected and expanded ABNF, reorganize
2464 ABNF introduction.
2466 C.8. Since draft-ietf-httpbis-p2-semantics-06
2468 Closed issues:
2470 o : "Clarify when
2471 Referer is sent"
2473 o : "status codes
2474 vs methods"
2476 o : "Do not
2477 require "updates" relation for specs that register status codes or
2478 method names"
2480 C.9. Since draft-ietf-httpbis-p2-semantics-07
2482 Closed issues:
2484 o : "Idempotency"
2486 o : "TRACE security
2487 considerations"
2489 o : "Clarify rules
2490 for determining what entities a response carries"
2492 o : "update note
2493 citing RFC 1945 and 2068"
2495 o : "update note
2496 about redirect limit"
2498 o : "Location
2499 header ABNF should use 'URI'"
2501 o : "fragments in
2502 Location vs status 303"
2504 o : "move IANA
2505 registrations for optional status codes"
2507 Partly resolved issues:
2509 o : "Are OPTIONS
2510 and TRACE safe?"
2512 C.10. Since draft-ietf-httpbis-p2-semantics-08
2514 Closed issues:
2516 o : "Safe Methods
2517 vs Redirection" (we missed the introduction to the 3xx status
2518 codes when fixing this previously)
2520 C.11. Since draft-ietf-httpbis-p2-semantics-09
2522 Closed issues:
2524 o : "Fragment
2525 combination / precedence during redirects"
2527 Partly resolved issues:
2529 o : "Location
2530 header payload handling"
2532 o : "Term for the
2533 requested resource's URI"
2535 C.12. Since draft-ietf-httpbis-p2-semantics-10
2537 Closed issues:
2539 o : "Clarify
2540 'Requested Variant'"
2542 o : "Clarify
2543 entity / representation / variant terminology"
2545 o : "Methods and
2546 Caching"
2548 o : "OPTIONS vs
2549 Max-Forwards"
2551 o : "Status codes
2552 and caching"
2554 o : "consider
2555 removing the 'changes from 2068' sections"
2557 C.13. Since draft-ietf-httpbis-p2-semantics-11
2559 Closed issues:
2561 o :
2562 "Considerations for new status codes"
2564 o :
2565 "Considerations for new methods"
2567 o : "User-Agent
2568 guidelines" (relating to the 'User-Agent' header field)
2570 C.14. Since draft-ietf-httpbis-p2-semantics-12
2572 Closed issues:
2574 o : "Fragment
2575 combination / precedence during redirects" (added warning about
2576 having a fragid on the redirect may cause inconvenience in some
2577 cases)
2579 o : "Content-* vs.
2580 PUT"
2582 o : "205 Bodies"
2584 o : "Understanding
2585 Content-* on non-PUT requests"
2587 o : "Content-*"
2589 o : "Header type
2590 defaulting"
2592 o : "PUT - 'store
2593 under' vs 'store at'"
2595 o : "duplicate
2596 ABNF for Reason-Phrase"
2598 o : "Note special
2599 status of Content-* prefix in header registration procedures"
2601 o : "Max-Forwards
2602 vs extension methods"
2604 o : "What is the
2605 value space of HTTP status codes?" (actually fixed in
2606 draft-ietf-httpbis-p2-semantics-11)
2608 o : "Header
2609 Classification"
2611 o : "PUT side
2612 effect: invalidation or just stale?"
2614 o : "proxies not
2615 supporting certain methods"
2617 o : "Migrate
2618 CONNECT from RFC2817 to p2"
2620 o : "Migrate
2621 Upgrade details from RFC2817"
2623 o : "clarify PUT
2624 semantics'"
2626 o : "duplicate
2627 ABNF for 'Method'"
2629 o : "untangle
2630 ABNFs for header fields"
2632 C.15. Since draft-ietf-httpbis-p2-semantics-13
2634 Closed issues:
2636 o : "untangle
2637 ABNFs for header fields"
2639 o : "message-body
2640 in CONNECT request"
2642 Index
2644 1
2645 100 Continue (status code) 23
2646 101 Switching Protocols (status code) 23
2648 2
2649 200 OK (status code) 24
2650 201 Created (status code) 24
2651 202 Accepted (status code) 25
2652 203 Non-Authoritative Information (status code) 25
2653 204 No Content (status code) 25
2654 205 Reset Content (status code) 26
2655 206 Partial Content (status code) 26
2657 3
2658 300 Multiple Choices (status code) 27
2659 301 Moved Permanently (status code) 27
2660 302 Found (status code) 28
2661 303 See Other (status code) 28
2662 304 Not Modified (status code) 29
2663 305 Use Proxy (status code) 29
2664 306 (Unused) (status code) 29
2665 307 Temporary Redirect (status code) 29
2667 4
2668 400 Bad Request (status code) 30
2669 401 Unauthorized (status code) 30
2670 402 Payment Required (status code) 30
2671 403 Forbidden (status code) 30
2672 404 Not Found (status code) 31
2673 405 Method Not Allowed (status code) 31
2674 406 Not Acceptable (status code) 31
2675 407 Proxy Authentication Required (status code) 32
2676 408 Request Timeout (status code) 32
2677 409 Conflict (status code) 32
2678 410 Gone (status code) 32
2679 411 Length Required (status code) 33
2680 412 Precondition Failed (status code) 33
2681 413 Request Entity Too Large (status code) 33
2682 414 URI Too Long (status code) 33
2683 415 Unsupported Media Type (status code) 33
2684 416 Requested Range Not Satisfiable (status code) 34
2685 417 Expectation Failed (status code) 34
2686 426 Upgrade Required (status code) 34
2688 5
2689 500 Internal Server Error (status code) 34
2690 501 Not Implemented (status code) 35
2691 502 Bad Gateway (status code) 35
2692 503 Service Unavailable (status code) 35
2693 504 Gateway Timeout (status code) 35
2694 505 HTTP Version Not Supported (status code) 35
2696 A
2697 Allow header field 36
2699 C
2700 CONNECT method 21
2702 D
2703 DELETE method 20
2705 E
2706 Expect header field 36
2708 F
2709 From header field 37
2711 G
2712 GET method 16
2713 Grammar
2714 Allow 36
2715 delta-seconds 40
2716 Expect 36
2717 expect-params 36
2718 expectation 36
2719 expectation-extension 36
2720 extension-code 10
2721 From 37
2722 Location 38
2723 Max-Forwards 39
2724 Method 7
2725 Reason-Phrase 10
2726 Referer 39
2727 Retry-After 40
2728 Server 40
2729 Status-Code 10
2730 User-Agent 41
2732 H
2733 HEAD method 17
2734 Header Fields
2735 Allow 36
2736 Expect 36
2737 From 37
2738 Location 38
2739 Max-Forwards 39
2740 Referer 39
2741 Retry-After 40
2742 Server 40
2743 User-Agent 41
2745 I
2746 Idempotent Methods 15
2748 L
2749 Location header field 38
2751 M
2752 Max-Forwards header field 39
2753 Methods
2754 CONNECT 21
2755 DELETE 20
2756 GET 16
2757 HEAD 17
2758 OPTIONS 15
2759 POST 17
2760 PUT 18
2761 TRACE 21
2763 O
2764 OPTIONS method 15
2766 P
2767 POST method 17
2768 PUT method 18
2770 R
2771 Referer header field 39
2772 Retry-After header field 40
2774 S
2775 Safe Methods 14
2776 Server header field 40
2777 Status Codes
2778 100 Continue 23
2779 101 Switching Protocols 23
2780 200 OK 24
2781 201 Created 24
2782 202 Accepted 25
2783 203 Non-Authoritative Information 25
2784 204 No Content 25
2785 205 Reset Content 26
2786 206 Partial Content 26
2787 300 Multiple Choices 27
2788 301 Moved Permanently 27
2789 302 Found 28
2790 303 See Other 28
2791 304 Not Modified 29
2792 305 Use Proxy 29
2793 306 (Unused) 29
2794 307 Temporary Redirect 29
2795 400 Bad Request 30
2796 401 Unauthorized 30
2797 402 Payment Required 30
2798 403 Forbidden 30
2799 404 Not Found 31
2800 405 Method Not Allowed 31
2801 406 Not Acceptable 31
2802 407 Proxy Authentication Required 32
2803 408 Request Timeout 32
2804 409 Conflict 32
2805 410 Gone 32
2806 411 Length Required 33
2807 412 Precondition Failed 33
2808 413 Request Entity Too Large 33
2809 414 URI Too Long 33
2810 415 Unsupported Media Type 33
2811 416 Requested Range Not Satisfiable 34
2812 417 Expectation Failed 34
2813 426 Upgrade Required 34
2814 500 Internal Server Error 34
2815 501 Not Implemented 35
2816 502 Bad Gateway 35
2817 503 Service Unavailable 35
2818 504 Gateway Timeout 35
2819 505 HTTP Version Not Supported 35
2821 T
2822 TRACE method 21
2824 U
2825 User-Agent header field 41
2827 Authors' Addresses
2829 Roy T. Fielding (editor)
2830 Adobe Systems Incorporated
2831 345 Park Ave
2832 San Jose, CA 95110
2833 USA
2835 EMail: fielding@gbiv.com
2836 URI: http://roy.gbiv.com/
2838 Jim Gettys
2839 Alcatel-Lucent Bell Labs
2840 21 Oak Knoll Road
2841 Carlisle, MA 01741
2842 USA
2844 EMail: jg@freedesktop.org
2845 URI: http://gettys.wordpress.com/
2847 Jeffrey C. Mogul
2848 Hewlett-Packard Company
2849 HP Labs, Large Scale Systems Group
2850 1501 Page Mill Road, MS 1177
2851 Palo Alto, CA 94304
2852 USA
2854 EMail: JeffMogul@acm.org
2856 Henrik Frystyk Nielsen
2857 Microsoft Corporation
2858 1 Microsoft Way
2859 Redmond, WA 98052
2860 USA
2862 EMail: henrikn@microsoft.com
2863 Larry Masinter
2864 Adobe Systems Incorporated
2865 345 Park Ave
2866 San Jose, CA 95110
2867 USA
2869 EMail: LMM@acm.org
2870 URI: http://larry.masinter.net/
2872 Paul J. Leach
2873 Microsoft Corporation
2874 1 Microsoft Way
2875 Redmond, WA 98052
2877 EMail: paulle@microsoft.com
2879 Tim Berners-Lee
2880 World Wide Web Consortium
2881 MIT Computer Science and Artificial Intelligence Laboratory
2882 The Stata Center, Building 32
2883 32 Vassar Street
2884 Cambridge, MA 02139
2885 USA
2887 EMail: timbl@w3.org
2888 URI: http://www.w3.org/People/Berners-Lee/
2890 Yves Lafon (editor)
2891 World Wide Web Consortium
2892 W3C / ERCIM
2893 2004, rte des Lucioles
2894 Sophia-Antipolis, AM 06902
2895 France
2897 EMail: ylafon@w3.org
2898 URI: http://www.raubacapeu.net/people/yves/
2899 Julian F. Reschke (editor)
2900 greenbytes GmbH
2901 Hafenweg 16
2902 Muenster, NW 48155
2903 Germany
2905 Phone: +49 251 2807760
2906 Fax: +49 251 2807761
2907 EMail: julian.reschke@greenbytes.de
2908 URI: http://greenbytes.de/tech/webdav/