idnits 2.17.1
draft-ietf-httpbis-p2-semantics-18.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 (January 4, 2012) is 4489 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-18
== Outdated reference: A later version (-20) exists of
draft-ietf-httpbis-p3-payload-18
== Outdated reference: A later version (-26) exists of
draft-ietf-httpbis-p4-conditional-18
== Outdated reference: A later version (-26) exists of
draft-ietf-httpbis-p5-range-18
== Outdated reference: A later version (-26) exists of
draft-ietf-httpbis-p6-cache-18
== Outdated reference: A later version (-26) exists of
draft-ietf-httpbis-p7-auth-18
-- 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)
-- Obsolete informational reference (is this intentional?): RFC 5987
(Obsoleted by RFC 8187)
Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 7 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: July 7, 2012 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 January 4, 2012
22 HTTP/1.1, part 2: Message Semantics
23 draft-ietf-httpbis-p2-semantics-18
25 Abstract
27 The Hypertext Transfer Protocol (HTTP) is an application-level
28 protocol for distributed, collaborative, hypertext 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.
34 Part 2 defines the semantics of HTTP messages as expressed by request
35 methods, request header fields, response status codes, and response
36 header fields.
38 Editorial Note (To be removed by RFC Editor)
40 Discussion of this draft should take place on the HTTPBIS working
41 group mailing list (ietf-http-wg@w3.org), which is archived at
42 .
44 The current issues list is at
45 and related
46 documents (including fancy diffs) can be found at
47 .
49 The changes in this draft are summarized in Appendix C.19.
51 Status of This Memo
53 This Internet-Draft is submitted in full conformance with the
54 provisions of BCP 78 and BCP 79.
56 Internet-Drafts are working documents of the Internet Engineering
57 Task Force (IETF). Note that other groups may also distribute
58 working documents as Internet-Drafts. The list of current Internet-
59 Drafts is at http://datatracker.ietf.org/drafts/current/.
61 Internet-Drafts are draft documents valid for a maximum of six months
62 and may be updated, replaced, or obsoleted by other documents at any
63 time. It is inappropriate to use Internet-Drafts as reference
64 material or to cite them other than as "work in progress."
66 This Internet-Draft will expire on July 7, 2012.
68 Copyright Notice
70 Copyright (c) 2012 IETF Trust and the persons identified as the
71 document authors. All rights reserved.
73 This document is subject to BCP 78 and the IETF Trust's Legal
74 Provisions Relating to IETF Documents
75 (http://trustee.ietf.org/license-info) in effect on the date of
76 publication of this document. Please review these documents
77 carefully, as they describe your rights and restrictions with respect
78 to this document. Code Components extracted from this document must
79 include Simplified BSD License text as described in Section 4.e of
80 the Trust Legal Provisions and are provided without warranty as
81 described in the Simplified BSD License.
83 This document may contain material from IETF Documents or IETF
84 Contributions published or made publicly available before November
85 10, 2008. The person(s) controlling the copyright in some of this
86 material may not have granted the IETF Trust the right to allow
87 modifications of such material outside the IETF Standards Process.
88 Without obtaining an adequate license from the person(s) controlling
89 the copyright in such materials, this document may not be modified
90 outside the IETF Standards Process, and derivative works of it may
91 not be created outside the IETF Standards Process, except to format
92 it for publication as an RFC or to translate it into languages other
93 than English.
95 Table of Contents
96 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
97 1.1. Conformance and Error Handling . . . . . . . . . . . . . . 6
98 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7
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 . . . . . . . . . . . . 9
106 3. Header Fields . . . . . . . . . . . . . . . . . . . . . . . . 9
107 3.1. Considerations for Creating Header Fields . . . . . . . . 9
108 3.2. Request Header Fields . . . . . . . . . . . . . . . . . . 11
109 3.3. Response Header Fields . . . . . . . . . . . . . . . . . . 12
110 4. Status Code and Reason Phrase . . . . . . . . . . . . . . . . 13
111 4.1. Overview of Status Codes . . . . . . . . . . . . . . . . . 13
112 4.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 15
113 4.2.1. Considerations for New Status Codes . . . . . . . . . 15
114 5. Representation . . . . . . . . . . . . . . . . . . . . . . . . 16
115 5.1. Identifying the Resource Associated with a
116 Representation . . . . . . . . . . . . . . . . . . . . . . 16
117 6. Method Definitions . . . . . . . . . . . . . . . . . . . . . . 17
118 6.1. Safe and Idempotent Methods . . . . . . . . . . . . . . . 17
119 6.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . 17
120 6.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . . 17
121 6.2. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 18
122 6.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
123 6.4. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
124 6.5. POST . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
125 6.6. PUT . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
126 6.7. DELETE . . . . . . . . . . . . . . . . . . . . . . . . . . 23
127 6.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . . . 23
128 6.9. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . . 24
129 6.9.1. Establishing a Tunnel with CONNECT . . . . . . . . . . 25
130 7. Status Code Definitions . . . . . . . . . . . . . . . . . . . 25
131 7.1. Informational 1xx . . . . . . . . . . . . . . . . . . . . 26
132 7.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 26
133 7.1.2. 101 Switching Protocols . . . . . . . . . . . . . . . 26
134 7.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 27
135 7.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 27
136 7.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 27
137 7.2.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 28
138 7.2.4. 203 Non-Authoritative Information . . . . . . . . . . 28
139 7.2.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 28
140 7.2.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 29
141 7.2.7. 206 Partial Content . . . . . . . . . . . . . . . . . 29
142 7.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 29
143 7.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 30
144 7.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 31
145 7.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 32
146 7.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 32
147 7.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . . 33
148 7.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 33
149 7.3.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 33
150 7.3.8. 307 Temporary Redirect . . . . . . . . . . . . . . . . 33
151 7.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 34
152 7.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 34
153 7.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . . 34
154 7.4.3. 402 Payment Required . . . . . . . . . . . . . . . . . 34
155 7.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 34
156 7.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . . 35
157 7.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . . 35
158 7.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 35
159 7.4.8. 407 Proxy Authentication Required . . . . . . . . . . 36
160 7.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . . 36
161 7.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 36
162 7.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 36
163 7.4.12. 411 Length Required . . . . . . . . . . . . . . . . . 37
164 7.4.13. 412 Precondition Failed . . . . . . . . . . . . . . . 37
165 7.4.14. 413 Request Representation Too Large . . . . . . . . . 37
166 7.4.15. 414 URI Too Long . . . . . . . . . . . . . . . . . . . 37
167 7.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . . 37
168 7.4.17. 416 Requested Range Not Satisfiable . . . . . . . . . 38
169 7.4.18. 417 Expectation Failed . . . . . . . . . . . . . . . . 38
170 7.4.19. 426 Upgrade Required . . . . . . . . . . . . . . . . . 38
171 7.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 38
172 7.5.1. 500 Internal Server Error . . . . . . . . . . . . . . 38
173 7.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 39
174 7.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 39
175 7.5.4. 503 Service Unavailable . . . . . . . . . . . . . . . 39
176 7.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 39
177 7.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 39
178 8. Date/Time Formats . . . . . . . . . . . . . . . . . . . . . . 40
179 9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 42
180 9.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . . . 42
181 9.2. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
182 9.3. Expect . . . . . . . . . . . . . . . . . . . . . . . . . . 44
183 9.4. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
184 9.5. Location . . . . . . . . . . . . . . . . . . . . . . . . . 45
185 9.6. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . . 46
186 9.7. Referer . . . . . . . . . . . . . . . . . . . . . . . . . 47
187 9.8. Retry-After . . . . . . . . . . . . . . . . . . . . . . . 47
188 9.9. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 48
189 9.10. User-Agent . . . . . . . . . . . . . . . . . . . . . . . . 48
190 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49
191 10.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 49
192 10.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 50
193 10.3. Header Field Registration . . . . . . . . . . . . . . . . 51
194 11. Security Considerations . . . . . . . . . . . . . . . . . . . 52
195 11.1. Transfer of Sensitive Information . . . . . . . . . . . . 52
196 11.2. Encoding Sensitive Information in URIs . . . . . . . . . . 53
197 11.3. Location Headers and Spoofing . . . . . . . . . . . . . . 54
198 11.4. Security Considerations for CONNECT . . . . . . . . . . . 54
199 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 54
200 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54
201 13.1. Normative References . . . . . . . . . . . . . . . . . . . 54
202 13.2. Informative References . . . . . . . . . . . . . . . . . . 55
203 Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 56
204 Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 57
205 Appendix C. Change Log (to be removed by RFC Editor before
206 publication) . . . . . . . . . . . . . . . . . . . . 60
207 C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 60
208 C.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 60
209 C.3. Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . . 60
210 C.4. Since draft-ietf-httpbis-p2-semantics-02 . . . . . . . . . 61
211 C.5. Since draft-ietf-httpbis-p2-semantics-03 . . . . . . . . . 62
212 C.6. Since draft-ietf-httpbis-p2-semantics-04 . . . . . . . . . 62
213 C.7. Since draft-ietf-httpbis-p2-semantics-05 . . . . . . . . . 62
214 C.8. Since draft-ietf-httpbis-p2-semantics-06 . . . . . . . . . 63
215 C.9. Since draft-ietf-httpbis-p2-semantics-07 . . . . . . . . . 63
216 C.10. Since draft-ietf-httpbis-p2-semantics-08 . . . . . . . . . 64
217 C.11. Since draft-ietf-httpbis-p2-semantics-09 . . . . . . . . . 64
218 C.12. Since draft-ietf-httpbis-p2-semantics-10 . . . . . . . . . 64
219 C.13. Since draft-ietf-httpbis-p2-semantics-11 . . . . . . . . . 65
220 C.14. Since draft-ietf-httpbis-p2-semantics-12 . . . . . . . . . 65
221 C.15. Since draft-ietf-httpbis-p2-semantics-13 . . . . . . . . . 66
222 C.16. Since draft-ietf-httpbis-p2-semantics-14 . . . . . . . . . 67
223 C.17. Since draft-ietf-httpbis-p2-semantics-15 . . . . . . . . . 67
224 C.18. Since draft-ietf-httpbis-p2-semantics-16 . . . . . . . . . 67
225 C.19. Since draft-ietf-httpbis-p2-semantics-17 . . . . . . . . . 67
226 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
228 1. Introduction
230 This document defines HTTP/1.1 request and response semantics. Each
231 HTTP message, as defined in [Part1], is in the form of either a
232 request or a response. An HTTP server listens on a connection for
233 HTTP requests and responds to each request, in the order received on
234 that connection, with one or more HTTP response messages. This
235 document defines the commonly agreed upon semantics of the HTTP
236 uniform interface, the intentions defined by each request method, and
237 the various response messages that might be expected as a result of
238 applying that method to the target resource.
240 This document is currently disorganized in order to minimize the
241 changes between drafts and enable reviewers to see the smaller errata
242 changes. A future draft will reorganize the sections to better
243 reflect the content. In particular, the sections will be ordered
244 according to the typical processing of an HTTP request message (after
245 message parsing): resource mapping, methods, request modifying header
246 fields, response status, status modifying header fields, and resource
247 metadata. The current mess reflects how widely dispersed these
248 topics and associated requirements had become in [RFC2616].
250 1.1. Conformance and Error Handling
252 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
253 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
254 document are to be interpreted as described in [RFC2119].
256 This document defines conformance criteria for several roles in HTTP
257 communication, including Senders, Recipients, Clients, Servers, User-
258 Agents, Origin Servers, Intermediaries, Proxies and Gateways. See
259 Section 2 of [Part1] for definitions of these terms.
261 An implementation is considered conformant if it complies with all of
262 the requirements associated with its role(s). Note that SHOULD-level
263 requirements are relevant here, unless one of the documented
264 exceptions is applicable.
266 This document also uses ABNF to define valid protocol elements
267 (Section 1.2). In addition to the prose requirements placed upon
268 them, Senders MUST NOT generate protocol elements that are invalid.
270 Unless noted otherwise, Recipients MAY take steps to recover a usable
271 protocol element from an invalid construct. However, HTTP does not
272 define specific error handling mechanisms, except in cases where it
273 has direct impact on security. This is because different uses of the
274 protocol require different error handling strategies; for example, a
275 Web browser may wish to transparently recover from a response where
276 the Location header field doesn't parse according to the ABNF,
277 whereby in a systems control protocol using HTTP, this type of error
278 recovery could lead to dangerous consequences.
280 1.2. Syntax Notation
282 This specification uses the ABNF syntax defined in Section 1.2 of
283 [Part1] (which extends the syntax defined in [RFC5234] with a list
284 rule). Appendix B shows the collected ABNF, with the list rule
285 expanded.
287 The following core rules are included by reference, as defined in
288 [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
289 (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
290 HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line
291 feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any
292 visible US-ASCII character).
294 1.2.1. Core Rules
296 The core rules below are defined in [Part1]:
298 BWS =
299 OWS =
300 RWS =
301 obs-text =
302 quoted-string =
303 token =
305 1.2.2. ABNF Rules defined in other Parts of the Specification
307 The ABNF rules below are defined in other parts:
309 absolute-URI =
310 comment =
311 partial-URI =
312 product =
313 URI-reference =
315 2. Method
317 The Method token indicates the request method to be performed on the
318 target resource (Section 4.3 of [Part1]). The method is case-
319 sensitive.
321 Method = token
323 The list of methods allowed by a resource can be specified in an
324 Allow header field (Section 9.1). The status code of the response
325 always notifies the client whether a method is currently allowed on a
326 resource, since the set of allowed methods can change dynamically.
327 An origin server SHOULD respond with the status code 405 (Method Not
328 Allowed) if the method is known by the origin server but not allowed
329 for the resource, and 501 (Not Implemented) if the method is
330 unrecognized or not implemented by the origin server. The methods
331 GET and HEAD MUST be supported by all general-purpose servers. All
332 other methods are OPTIONAL; however, if the above methods are
333 implemented, they MUST be implemented with the same semantics as
334 those specified in Section 6.
336 2.1. Overview of Methods
338 The methods listed below are defined in Section 6.
340 +-------------+---------------+
341 | Method Name | Defined in... |
342 +-------------+---------------+
343 | OPTIONS | Section 6.2 |
344 | GET | Section 6.3 |
345 | HEAD | Section 6.4 |
346 | POST | Section 6.5 |
347 | PUT | Section 6.6 |
348 | DELETE | Section 6.7 |
349 | TRACE | Section 6.8 |
350 | CONNECT | Section 6.9 |
351 +-------------+---------------+
353 Note that this list is not exhaustive -- it does not include request
354 methods defined in other specifications.
356 2.2. Method Registry
358 The HTTP Method Registry defines the name space for the Method token
359 in the Request line of an HTTP request.
361 Registrations MUST include the following fields:
363 o Method Name (see Section 2)
365 o Safe ("yes" or "no", see Section 6.1.1)
367 o Pointer to specification text
369 Values to be added to this name space are subject to IETF review
370 ([RFC5226], Section 4.1).
372 The registry itself is maintained at
373 .
375 2.2.1. Considerations for New Methods
377 When it is necessary to express new semantics for a HTTP request that
378 aren't specific to a single application or media type, and currently
379 defined methods are inadequate, it may be appropriate to register a
380 new method.
382 HTTP methods are generic; that is, they are potentially applicable to
383 any resource, not just one particular media type, "type" of resource,
384 or application. As such, it is preferred that new HTTP methods be
385 registered in a document that isn't specific to a single application,
386 so that this is clear.
388 Due to the parsing rules defined in Section 3.3 of [Part1],
389 definitions of HTTP methods cannot prohibit the presence of a
390 message-body on either the request or the response message (with
391 responses to HEAD requests being the single exception). Definitions
392 of new methods cannot change this rule, but they can specify that
393 only zero-length bodies (as opposed to absent bodies) are allowed.
395 New method definitions need to indicate whether they are safe
396 (Section 6.1.1), what semantics (if any) the request body has, and
397 whether they are idempotent (Section 6.1.2). They also need to state
398 whether they can be cached ([Part6]); in particular what conditions a
399 cache may store the response, and under what conditions such a stored
400 response may be used to satisfy a subsequent request.
402 3. Header Fields
404 Header fields are key value pairs that can be used to communicate
405 data about the message, its payload, the target resource, or about
406 the connection itself (i.e., control data). See Section 3.2 of
407 [Part1] for a general definition of their syntax.
409 3.1. Considerations for Creating Header Fields
411 New header fields are registered using the procedures described in
412 [RFC3864].
414 The requirements for header field names are defined in Section 4.1 of
415 [RFC3864]. Authors of specifications defining new fields are advised
416 to keep the name as short as practical, and not to prefix them with
417 "X-" if they are to be registered (either immediately or in the
418 future).
420 New header field values typically have their syntax defined using
421 ABNF ([RFC5234]), using the extensions defined in Section 1.2.1 of
422 [Part1] as necessary, and are usually constrained to the range of
423 ASCII characters. Header fields needing a greater range of
424 characters can use an encoding such as the one defined in [RFC5987].
426 Because commas (",") are used as a generic delimiter between field-
427 values, they need to be treated with care if they are allowed in the
428 field-value's payload. Typically, components that might contain a
429 comma are protected with double-quotes using the quoted-string ABNF
430 production (Section 3.2.3 of [Part1]).
432 For example, a textual date and a URI (either of which might contain
433 a comma) could be safely carried in field-values like these:
435 Example-URI-Field: "http://example.com/a.html,foo",
436 "http://without-a-comma.example.com/"
437 Example-Date-Field: "Sat, 04 May 1996", "Wed, 14 Sep 2005"
439 Note that double quote delimiters almost always are used with the
440 quoted-string production; using a different syntax inside double
441 quotes will likely cause unnecessary confusion.
443 Many header fields use a format including (case-insensitively) named
444 parameters (for instance, Content-Type, defined in Section 6.8 of
445 [Part3]). Allowing both unquoted (token) and quoted (quoted-string)
446 syntax for the parameter value enables recipients to use existing
447 parser components. When allowing both forms, the meaning of a
448 parameter value ought to be independent of the syntax used for it
449 (for an example, see the notes on parameter handling for media types
450 in Section 2.3 of [Part3]).
452 Authors of specifications defining new header fields are advised to
453 consider documenting:
455 o Whether the field is a single value, or whether it can be a list
456 (delimited by commas; see Section 3.2 of [Part1]).
458 If it does not use the list syntax, document how to treat messages
459 where the header field occurs multiple times (a sensible default
460 would be to ignore the header field, but this might not always be
461 the right choice).
463 Note that intermediaries and software libraries might combine
464 multiple header field instances into a single one, despite the
465 header field not allowing this. A robust format enables
466 recipients to discover these situations (good example: "Content-
467 Type", as the comma can only appear inside quoted strings; bad
468 example: "Location", as a comma can occur inside a URI).
470 o Under what conditions the header field can be used; e.g., only in
471 responses or requests, in all messages, only on responses to a
472 particular request method.
474 o Whether it is appropriate to list the field-name in the Connection
475 header (i.e., if the header is to be hop-by-hop, see Section 8.1
476 of [Part1]).
478 o Under what conditions intermediaries are allowed to modify the
479 header field's value, insert or delete it.
481 o How the header might interact with caching (see [Part6]).
483 o Whether the header field is useful or allowable in trailers (see
484 Section 5.1.1 of [Part1]).
486 o Whether the header field should be preserved across redirects.
488 3.2. Request Header Fields
490 The request header fields allow the client to pass additional
491 information about the request, and about the client itself, to the
492 server. These fields act as request modifiers, with semantics
493 equivalent to the parameters on a programming language method
494 invocation.
496 +---------------------+------------------------+
497 | Header Field Name | Defined in... |
498 +---------------------+------------------------+
499 | Accept | Section 6.1 of [Part3] |
500 | Accept-Charset | Section 6.2 of [Part3] |
501 | Accept-Encoding | Section 6.3 of [Part3] |
502 | Accept-Language | Section 6.4 of [Part3] |
503 | Authorization | Section 4.1 of [Part7] |
504 | Expect | Section 9.3 |
505 | From | Section 9.4 |
506 | Host | Section 8.3 of [Part1] |
507 | If-Match | Section 3.1 of [Part4] |
508 | If-Modified-Since | Section 3.3 of [Part4] |
509 | If-None-Match | Section 3.2 of [Part4] |
510 | If-Range | Section 5.3 of [Part5] |
511 | If-Unmodified-Since | Section 3.4 of [Part4] |
512 | Max-Forwards | Section 9.6 |
513 | Proxy-Authorization | Section 4.3 of [Part7] |
514 | Range | Section 5.4 of [Part5] |
515 | Referer | Section 9.7 |
516 | TE | Section 8.4 of [Part1] |
517 | User-Agent | Section 9.10 |
518 +---------------------+------------------------+
520 3.3. Response Header Fields
522 The response header fields allow the server to pass additional
523 information about the response which cannot be placed in the Status-
524 Line. These header fields give information about the server and
525 about further access to the target resource (Section 4.3 of [Part1]).
527 +--------------------+------------------------+
528 | Header Field Name | Defined in... |
529 +--------------------+------------------------+
530 | Accept-Ranges | Section 5.1 of [Part5] |
531 | Age | Section 3.1 of [Part6] |
532 | Allow | Section 9.1 |
533 | Date | Section 9.2 |
534 | ETag | Section 2.3 of [Part4] |
535 | Location | Section 9.5 |
536 | Proxy-Authenticate | Section 4.2 of [Part7] |
537 | Retry-After | Section 9.8 |
538 | Server | Section 9.9 |
539 | Vary | Section 3.5 of [Part6] |
540 | WWW-Authenticate | Section 4.4 of [Part7] |
541 +--------------------+------------------------+
543 4. Status Code and Reason Phrase
545 The Status-Code element is a 3-digit integer result code of the
546 attempt to understand and satisfy the request.
548 The Reason-Phrase is intended to give a short textual description of
549 the Status-Code and is intended for a human user. The client does
550 not need to examine or display the Reason-Phrase.
552 Status-Code = 3DIGIT
553 Reason-Phrase = *( HTAB / SP / VCHAR / obs-text )
555 HTTP status codes are extensible. HTTP applications are not required
556 to understand the meaning of all registered status codes, though such
557 understanding is obviously desirable. However, applications MUST
558 understand the class of any status code, as indicated by the first
559 digit, and treat any unrecognized response as being equivalent to the
560 x00 status code of that class, with the exception that an
561 unrecognized response MUST NOT be cached. For example, if an
562 unrecognized status code of 431 is received by the client, it can
563 safely assume that there was something wrong with its request and
564 treat the response as if it had received a 400 status code. In such
565 cases, user agents SHOULD present to the user the representation
566 enclosed with the response, since that representation is likely to
567 include human-readable information which will explain the unusual
568 status.
570 4.1. Overview of Status Codes
572 The status codes listed below are defined in Section 7 of this
573 specification, Section 4 of [Part4], Section 3 of [Part5], and
574 Section 3 of [Part7]. The reason phrases listed here are only
575 recommendations -- they can be replaced by local equivalents without
576 affecting the protocol.
578 +-------------+------------------------------+----------------------+
579 | Status-Code | Reason-Phrase | Defined in... |
580 +-------------+------------------------------+----------------------+
581 | 100 | Continue | Section 7.1.1 |
582 | 101 | Switching Protocols | Section 7.1.2 |
583 | 200 | OK | Section 7.2.1 |
584 | 201 | Created | Section 7.2.2 |
585 | 202 | Accepted | Section 7.2.3 |
586 | 203 | Non-Authoritative | Section 7.2.4 |
587 | | Information | |
588 | 204 | No Content | Section 7.2.5 |
589 | 205 | Reset Content | Section 7.2.6 |
590 | 206 | Partial Content | Section 3.1 of |
591 | | | [Part5] |
592 | 300 | Multiple Choices | Section 7.3.1 |
593 | 301 | Moved Permanently | Section 7.3.2 |
594 | 302 | Found | Section 7.3.3 |
595 | 303 | See Other | Section 7.3.4 |
596 | 304 | Not Modified | Section 4.1 of |
597 | | | [Part4] |
598 | 305 | Use Proxy | Section 7.3.6 |
599 | 307 | Temporary Redirect | Section 7.3.8 |
600 | 400 | Bad Request | Section 7.4.1 |
601 | 401 | Unauthorized | Section 3.1 of |
602 | | | [Part7] |
603 | 402 | Payment Required | Section 7.4.3 |
604 | 403 | Forbidden | Section 7.4.4 |
605 | 404 | Not Found | Section 7.4.5 |
606 | 405 | Method Not Allowed | Section 7.4.6 |
607 | 406 | Not Acceptable | Section 7.4.7 |
608 | 407 | Proxy Authentication | Section 3.2 of |
609 | | Required | [Part7] |
610 | 408 | Request Time-out | Section 7.4.9 |
611 | 409 | Conflict | Section 7.4.10 |
612 | 410 | Gone | Section 7.4.11 |
613 | 411 | Length Required | Section 7.4.12 |
614 | 412 | Precondition Failed | Section 4.2 of |
615 | | | [Part4] |
616 | 413 | Request Representation Too | Section 7.4.14 |
617 | | Large | |
618 | 414 | URI Too Long | Section 7.4.15 |
619 | 415 | Unsupported Media Type | Section 7.4.16 |
620 | 416 | Requested range not | Section 3.2 of |
621 | | satisfiable | [Part5] |
622 | 417 | Expectation Failed | Section 7.4.18 |
623 | 426 | Upgrade Required | Section 7.4.19 |
624 | 500 | Internal Server Error | Section 7.5.1 |
625 | 501 | Not Implemented | Section 7.5.2 |
626 | 502 | Bad Gateway | Section 7.5.3 |
627 | 503 | Service Unavailable | Section 7.5.4 |
628 | 504 | Gateway Time-out | Section 7.5.5 |
629 | 505 | HTTP Version not supported | Section 7.5.6 |
630 +-------------+------------------------------+----------------------+
632 Note that this list is not exhaustive -- it does not include
633 extension status codes defined in other specifications.
635 4.2. Status Code Registry
637 The HTTP Status Code Registry defines the name space for the Status-
638 Code token in the Status-Line of an HTTP response.
640 Values to be added to this name space are subject to IETF review
641 ([RFC5226], Section 4.1).
643 The registry itself is maintained at
644 .
646 4.2.1. Considerations for New Status Codes
648 When it is necessary to express new semantics for a HTTP response
649 that aren't specific to a single application or media type, and
650 currently defined status codes are inadequate, a new status code can
651 be registered.
653 HTTP status codes are generic; that is, they are potentially
654 applicable to any resource, not just one particular media type,
655 "type" of resource, or application. As such, it is preferred that
656 new HTTP status codes be registered in a document that isn't specific
657 to a single application, so that this is clear.
659 Definitions of new HTTP status codes typically explain the request
660 conditions that produce a response containing the status code (e.g.,
661 combinations of request headers and/or method(s)), along with any
662 interactions with response headers (e.g., those that are required,
663 those that modify the semantics of the response).
665 New HTTP status codes are required to fall under one of the
666 categories defined in Section 7. To allow existing parsers to
667 properly handle them, new status codes cannot disallow a response
668 body, although they can mandate a zero-length response body. They
669 can require the presence of one or more particular HTTP response
670 header(s).
672 Likewise, their definitions can specify that caches are allowed to
673 use heuristics to determine their freshness (see [Part6]; by default,
674 it is not allowed), and can define how to determine the resource
675 which they carry a representation for (see Section 5.1; by default,
676 it is anonymous).
678 5. Representation
680 Request and Response messages MAY transfer a representation if not
681 otherwise restricted by the request method or response status code.
682 A representation consists of metadata (representation header fields)
683 and data (representation body). When a complete or partial
684 representation is enclosed in an HTTP message, it is referred to as
685 the payload of the message. HTTP representations are defined in
686 [Part3].
688 A representation body is only present in a message when a message-
689 body is present, as described in Section 3.3 of [Part1]. The
690 representation body is obtained from the message-body by decoding any
691 Transfer-Encoding that might have been applied to ensure safe and
692 proper transfer of the message.
694 5.1. Identifying the Resource Associated with a Representation
696 It is sometimes necessary to determine an identifier for the resource
697 associated with a representation.
699 An HTTP request representation, when present, is always associated
700 with an anonymous (i.e., unidentified) resource.
702 In the common case, an HTTP response is a representation of the
703 target resource (see Section 4.3 of [Part1]). However, this is not
704 always the case. To determine the URI of the resource a response is
705 associated with, the following rules are used (with the first
706 applicable one being selected):
708 1. If the response status code is 200 or 203 and the request method
709 was GET, the response payload is a representation of the target
710 resource.
712 2. If the response status code is 204, 206, or 304 and the request
713 method was GET or HEAD, the response payload is a partial
714 representation of the target resource.
716 3. If the response has a Content-Location header field, and that URI
717 is the same as the effective request URI, the response payload is
718 a representation of the target resource.
720 4. If the response has a Content-Location header field, and that URI
721 is not the same as the effective request URI, then the response
722 asserts that its payload is a representation of the resource
723 identified by the Content-Location URI. However, such an
724 assertion cannot be trusted unless it can be verified by other
725 means (not defined by HTTP).
727 5. Otherwise, the response is a representation of an anonymous
728 (i.e., unidentified) resource.
730 [[TODO-req-uri: The comparison function is going to have to be
731 defined somewhere, because we already need to compare URIs for things
732 like cache invalidation.]]
734 6. Method Definitions
736 The set of common request methods for HTTP/1.1 is defined below.
737 Although this set can be expanded, additional methods cannot be
738 assumed to share the same semantics for separately extended clients
739 and servers.
741 6.1. Safe and Idempotent Methods
743 6.1.1. Safe Methods
745 Implementors need to be aware that the software represents the user
746 in their interactions over the Internet, and need to allow the user
747 to be aware of any actions they take which might have an unexpected
748 significance to themselves or others.
750 In particular, the convention has been established that the GET,
751 HEAD, OPTIONS, and TRACE request methods SHOULD NOT have the
752 significance of taking an action other than retrieval. These request
753 methods ought to be considered "safe". This allows user agents to
754 represent other methods, such as POST, PUT and DELETE, in a special
755 way, so that the user is made aware of the fact that a possibly
756 unsafe action is being requested.
758 Naturally, it is not possible to ensure that the server does not
759 generate side-effects as a result of performing a GET request; in
760 fact, some dynamic resources consider that a feature. The important
761 distinction here is that the user did not request the side-effects,
762 so therefore cannot be held accountable for them.
764 6.1.2. Idempotent Methods
766 Request methods can also have the property of "idempotence" in that,
767 aside from error or expiration issues, the intended effect of
768 multiple identical requests is the same as for a single request.
769 PUT, DELETE, and all safe request methods are idempotent. It is
770 important to note that idempotence refers only to changes requested
771 by the client: a server is free to change its state due to multiple
772 requests for the purpose of tracking those requests, versioning of
773 results, etc.
775 6.2. OPTIONS
777 The OPTIONS method requests information about the communication
778 options available on the request/response chain identified by the
779 effective request URI. This method allows a client to determine the
780 options and/or requirements associated with a resource, or the
781 capabilities of a server, without implying a resource action or
782 initiating a resource retrieval.
784 Responses to the OPTIONS method are not cacheable.
786 If the OPTIONS request includes a message-body (as indicated by the
787 presence of Content-Length or Transfer-Encoding), then the media type
788 MUST be indicated by a Content-Type field. Although this
789 specification does not define any use for such a body, future
790 extensions to HTTP might use the OPTIONS body to make more detailed
791 queries on the server.
793 If the request-target is an asterisk ("*"), the OPTIONS request is
794 intended to apply to the server in general rather than to a specific
795 resource. Since a server's communication options typically depend on
796 the resource, the "*" request is only useful as a "ping" or "no-op"
797 type of method; it does nothing beyond allowing the client to test
798 the capabilities of the server. For example, this can be used to
799 test a proxy for HTTP/1.1 compliance (or lack thereof).
801 If the request-target is not an asterisk, the OPTIONS request applies
802 only to the options that are available when communicating with that
803 resource.
805 A 200 response SHOULD include any header fields that indicate
806 optional features implemented by the server and applicable to that
807 resource (e.g., Allow), possibly including extensions not defined by
808 this specification. The response body, if any, SHOULD also include
809 information about the communication options. The format for such a
810 body is not defined by this specification, but might be defined by
811 future extensions to HTTP. Content negotiation MAY be used to select
812 the appropriate response format. If no response body is included,
813 the response MUST include a Content-Length field with a field-value
814 of "0".
816 The Max-Forwards header field MAY be used to target a specific proxy
817 in the request chain (see Section 9.6). If no Max-Forwards field is
818 present in the request, then the forwarded request MUST NOT include a
819 Max-Forwards field.
821 6.3. GET
823 The GET method requests transfer of a current representation of the
824 target resource.
826 If the target resource is a data-producing process, it is the
827 produced data which shall be returned as the representation in the
828 response and not the source text of the process, unless that text
829 happens to be the output of the process.
831 The semantics of the GET method change to a "conditional GET" if the
832 request message includes an If-Modified-Since, If-Unmodified-Since,
833 If-Match, If-None-Match, or If-Range header field. A conditional GET
834 requests that the representation be transferred only under the
835 circumstances described by the conditional header field(s). The
836 conditional GET request is intended to reduce unnecessary network
837 usage by allowing cached representations to be refreshed without
838 requiring multiple requests or transferring data already held by the
839 client.
841 The semantics of the GET method change to a "partial GET" if the
842 request message includes a Range header field. A partial GET
843 requests that only part of the representation be transferred, as
844 described in Section 5.4 of [Part5]. The partial GET request is
845 intended to reduce unnecessary network usage by allowing partially-
846 retrieved representations to be completed without transferring data
847 already held by the client.
849 Bodies on GET requests have no defined semantics. Note that sending
850 a body on a GET request might cause some existing implementations to
851 reject the request.
853 The response to a GET request is cacheable and MAY be used to satisfy
854 subsequent GET and HEAD requests (see [Part6]).
856 See Section 11.2 for security considerations when used for forms.
858 6.4. HEAD
860 The HEAD method is identical to GET except that the server MUST NOT
861 return a message-body in the response. The metadata contained in the
862 HTTP header fields in response to a HEAD request SHOULD be identical
863 to the information sent in response to a GET request. This method
864 can be used for obtaining metadata about the representation implied
865 by the request without transferring the representation body. This
866 method is often used for testing hypertext links for validity,
867 accessibility, and recent modification.
869 The response to a HEAD request is cacheable and MAY be used to
870 satisfy a subsequent HEAD request; see [Part6]. It also MAY be used
871 to update a previously cached representation from that resource; if
872 the new field values indicate that the cached representation differs
873 from the current representation (as would be indicated by a change in
874 Content-Length, ETag or Last-Modified), then the cache MUST treat the
875 cache entry as stale.
877 Bodies on HEAD requests have no defined semantics. Note that sending
878 a body on a HEAD request might cause some existing implementations to
879 reject the request.
881 6.5. POST
883 The POST method requests that the origin server accept the
884 representation enclosed in the request as data to be processed by the
885 target resource. POST is designed to allow a uniform method to cover
886 the following functions:
888 o Annotation of existing resources;
890 o Posting a message to a bulletin board, newsgroup, mailing list, or
891 similar group of articles;
893 o Providing a block of data, such as the result of submitting a
894 form, to a data-handling process;
896 o Extending a database through an append operation.
898 The actual function performed by the POST method is determined by the
899 server and is usually dependent on the effective request URI.
901 The action performed by the POST method might not result in a
902 resource that can be identified by a URI. In this case, either 200
903 (OK) or 204 (No Content) is the appropriate response status code,
904 depending on whether or not the response includes a representation
905 that describes the result.
907 If a resource has been created on the origin server, the response
908 SHOULD be 201 (Created) and contain a representation which describes
909 the status of the request and refers to the new resource, and a
910 Location header field (see Section 9.5).
912 Responses to POST requests are only cacheable when they include
913 explicit freshness information (see Section 2.3.1 of [Part6]). A
914 cached POST response with a Content-Location header field (see
915 Section 6.7 of [Part3]) whose value is the effective Request URI MAY
916 be used to satisfy subsequent GET and HEAD requests.
918 Note that POST caching is not widely implemented. However, the 303
919 (See Other) response can be used to direct the user agent to retrieve
920 a cacheable resource.
922 6.6. PUT
924 The PUT method requests that the state of the target resource be
925 created or replaced with the state defined by the representation
926 enclosed in the request message payload. A successful PUT of a given
927 representation would suggest that a subsequent GET on that same
928 target resource will result in an equivalent representation being
929 returned in a 200 (OK) response. However, there is no guarantee that
930 such a state change will be observable, since the target resource
931 might be acted upon by other user agents in parallel, or might be
932 subject to dynamic processing by the origin server, before any
933 subsequent GET is received. A successful response only implies that
934 the user agent's intent was achieved at the time of its processing by
935 the origin server.
937 If the target resource does not have a current representation and the
938 PUT successfully creates one, then the origin server MUST inform the
939 user agent by sending a 201 (Created) response. If the target
940 resource does have a current representation and that representation
941 is successfully modified in accordance with the state of the enclosed
942 representation, then either a 200 (OK) or 204 (No Content) response
943 SHOULD be sent to indicate successful completion of the request.
945 Unrecognized header fields SHOULD be ignored (i.e., not saved as part
946 of the resource state).
948 An origin server SHOULD verify that the PUT representation is
949 consistent with any constraints which the server has for the target
950 resource that cannot or will not be changed by the PUT. This is
951 particularly important when the origin server uses internal
952 configuration information related to the URI in order to set the
953 values for representation metadata on GET responses. When a PUT
954 representation is inconsistent with the target resource, the origin
955 server SHOULD either make them consistent, by transforming the
956 representation or changing the resource configuration, or respond
957 with an appropriate error message containing sufficient information
958 to explain why the representation is unsuitable. The 409 (Conflict)
959 or 415 (Unsupported Media Type) status codes are suggested, with the
960 latter being specific to constraints on Content-Type values.
962 For example, if the target resource is configured to always have a
963 Content-Type of "text/html" and the representation being PUT has a
964 Content-Type of "image/jpeg", then the origin server SHOULD do one
965 of: (a) reconfigure the target resource to reflect the new media
966 type; (b) transform the PUT representation to a format consistent
967 with that of the resource before saving it as the new resource state;
968 or, (c) reject the request with a 415 response indicating that the
969 target resource is limited to "text/html", perhaps including a link
970 to a different resource that would be a suitable target for the new
971 representation.
973 HTTP does not define exactly how a PUT method affects the state of an
974 origin server beyond what can be expressed by the intent of the user
975 agent request and the semantics of the origin server response. It
976 does not define what a resource might be, in any sense of that word,
977 beyond the interface provided via HTTP. It does not define how
978 resource state is "stored", nor how such storage might change as a
979 result of a change in resource state, nor how the origin server
980 translates resource state into representations. Generally speaking,
981 all implementation details behind the resource interface are
982 intentionally hidden by the server.
984 The fundamental difference between the POST and PUT methods is
985 highlighted by the different intent for the target resource. The
986 target resource in a POST request is intended to handle the enclosed
987 representation as a data-accepting process, such as for a gateway to
988 some other protocol or a document that accepts annotations. In
989 contrast, the target resource in a PUT request is intended to take
990 the enclosed representation as a new or replacement value. Hence,
991 the intent of PUT is idempotent and visible to intermediaries, even
992 though the exact effect is only known by the origin server.
994 Proper interpretation of a PUT request presumes that the user agent
995 knows what target resource is desired. A service that is intended to
996 select a proper URI on behalf of the client, after receiving a state-
997 changing request, SHOULD be implemented using the POST method rather
998 than PUT. If the origin server will not make the requested PUT state
999 change to the target resource and instead wishes to have it applied
1000 to a different resource, such as when the resource has been moved to
1001 a different URI, then the origin server MUST send a 301 (Moved
1002 Permanently) response; the user agent MAY then make its own decision
1003 regarding whether or not to redirect the request.
1005 A PUT request applied to the target resource MAY have side-effects on
1006 other resources. For example, an article might have a URI for
1007 identifying "the current version" (a resource) which is separate from
1008 the URIs identifying each particular version (different resources
1009 that at one point shared the same state as the current version
1010 resource). A successful PUT request on "the current version" URI
1011 might therefore create a new version resource in addition to changing
1012 the state of the target resource, and might also cause links to be
1013 added between the related resources.
1015 An origin server SHOULD reject any PUT request that contains a
1016 Content-Range header field, since it might be misinterpreted as
1017 partial content (or might be partial content that is being mistakenly
1018 PUT as a full representation). Partial content updates are possible
1019 by targeting a separately identified resource with state that
1020 overlaps a portion of the larger resource, or by using a different
1021 method that has been specifically defined for partial updates (for
1022 example, the PATCH method defined in [RFC5789]).
1024 Responses to the PUT method are not cacheable. If a PUT request
1025 passes through a cache that has one or more stored responses for the
1026 effective request URI, those stored responses will be invalidated
1027 (see Section 2.5 of [Part6]).
1029 6.7. DELETE
1031 The DELETE method requests that the origin server delete the target
1032 resource. This method MAY be overridden by human intervention (or
1033 other means) on the origin server. The client cannot be guaranteed
1034 that the operation has been carried out, even if the status code
1035 returned from the origin server indicates that the action has been
1036 completed successfully. However, the server SHOULD NOT indicate
1037 success unless, at the time the response is given, it intends to
1038 delete the resource or move it to an inaccessible location.
1040 A successful response SHOULD be 200 (OK) if the response includes an
1041 representation describing the status, 202 (Accepted) if the action
1042 has not yet been enacted, or 204 (No Content) if the action has been
1043 enacted but the response does not include a representation.
1045 Bodies on DELETE requests have no defined semantics. Note that
1046 sending a body on a DELETE request might cause some existing
1047 implementations to reject the request.
1049 Responses to the DELETE method are not cacheable. If a DELETE
1050 request passes through a cache that has one or more stored responses
1051 for the effective request URI, those stored responses will be
1052 invalidated (see Section 2.5 of [Part6]).
1054 6.8. TRACE
1056 The TRACE method requests a remote, application-layer loop-back of
1057 the request message. The final recipient of the request SHOULD
1058 reflect the message received back to the client as the message-body
1059 of a 200 (OK) response. The final recipient is either the origin
1060 server or the first proxy to receive a Max-Forwards value of zero (0)
1061 in the request (see Section 9.6). A TRACE request MUST NOT include a
1062 message-body.
1064 TRACE allows the client to see what is being received at the other
1065 end of the request chain and use that data for testing or diagnostic
1066 information. The value of the Via header field (Section 8.8 of
1067 [Part1]) is of particular interest, since it acts as a trace of the
1068 request chain. Use of the Max-Forwards header field allows the
1069 client to limit the length of the request chain, which is useful for
1070 testing a chain of proxies forwarding messages in an infinite loop.
1072 If the request is valid, the response SHOULD have a Content-Type of
1073 "message/http" (see Section 9.3.1 of [Part1]) and contain a message-
1074 body that encloses a copy of the entire request message. Responses
1075 to the TRACE method are not cacheable.
1077 6.9. CONNECT
1079 The CONNECT method requests that the proxy establish a tunnel to the
1080 request-target and then restrict its behavior to blind forwarding of
1081 packets until the connection is closed.
1083 When using CONNECT, the request-target MUST use the authority form
1084 (Section 3.1.1.2 of [Part1]); i.e., the request-target consists of
1085 only the host name and port number of the tunnel destination,
1086 separated by a colon. For example,
1088 CONNECT server.example.com:80 HTTP/1.1
1089 Host: server.example.com:80
1091 Other HTTP mechanisms can be used normally with the CONNECT method --
1092 except end-to-end protocol Upgrade requests, since the tunnel must be
1093 established first.
1095 For example, proxy authentication might be used to establish the
1096 authority to create a tunnel:
1098 CONNECT server.example.com:80 HTTP/1.1
1099 Host: server.example.com:80
1100 Proxy-Authorization: basic aGVsbG86d29ybGQ=
1102 Bodies on CONNECT requests have no defined semantics. Note that
1103 sending a body on a CONNECT request might cause some existing
1104 implementations to reject the request.
1106 Like any other pipelined HTTP/1.1 request, data to be tunnel may be
1107 sent immediately after the blank line. The usual caveats also apply:
1108 data may be discarded if the eventual response is negative, and the
1109 connection may be reset with no response if more than one TCP segment
1110 is outstanding.
1112 6.9.1. Establishing a Tunnel with CONNECT
1114 Any successful (2xx) response to a CONNECT request indicates that the
1115 proxy has established a connection to the requested host and port,
1116 and has switched to tunneling the current connection to that server
1117 connection.
1119 It may be the case that the proxy itself can only reach the requested
1120 origin server through another proxy. In this case, the first proxy
1121 SHOULD make a CONNECT request of that next proxy, requesting a tunnel
1122 to the authority. A proxy MUST NOT respond with any 2xx status code
1123 unless it has either a direct or tunnel connection established to the
1124 authority.
1126 An origin server which receives a CONNECT request for itself MAY
1127 respond with a 2xx status code to indicate that a connection is
1128 established.
1130 If at any point either one of the peers gets disconnected, any
1131 outstanding data that came from that peer will be passed to the other
1132 one, and after that also the other connection will be terminated by
1133 the proxy. If there is outstanding data to that peer undelivered,
1134 that data will be discarded.
1136 7. Status Code Definitions
1138 The first digit of the Status-Code defines the class of response.
1139 The last two digits do not have any categorization role. There are 5
1140 values for the first digit:
1142 o 1xx: Informational - Request received, continuing process
1144 o 2xx: Success - The action was successfully received, understood,
1145 and accepted
1147 o 3xx: Redirection - Further action must be taken in order to
1148 complete the request
1150 o 4xx: Client Error - The request contains bad syntax or cannot be
1151 fulfilled
1153 o 5xx: Server Error - The server failed to fulfill an apparently
1154 valid request
1156 Each Status-Code is described below, including any metadata required
1157 in the response.
1159 7.1. Informational 1xx
1161 This class of status code indicates a provisional response,
1162 consisting only of the Status-Line and optional header fields, and is
1163 terminated by an empty line. There are no required header fields for
1164 this class of status code. Since HTTP/1.0 did not define any 1xx
1165 status codes, servers MUST NOT send a 1xx response to an HTTP/1.0
1166 client except under experimental conditions.
1168 A client MUST be prepared to accept one or more 1xx status responses
1169 prior to a regular response, even if the client does not expect a 100
1170 (Continue) status message. Unexpected 1xx status responses MAY be
1171 ignored by a user agent.
1173 Proxies MUST forward 1xx responses, unless the connection between the
1174 proxy and its client has been closed, or unless the proxy itself
1175 requested the generation of the 1xx response. (For example, if a
1176 proxy adds a "Expect: 100-continue" field when it forwards a request,
1177 then it need not forward the corresponding 100 (Continue)
1178 response(s).)
1180 7.1.1. 100 Continue
1182 The client SHOULD continue with its request. This interim response
1183 is used to inform the client that the initial part of the request has
1184 been received and has not yet been rejected by the server. The
1185 client SHOULD continue by sending the remainder of the request or, if
1186 the request has already been completed, ignore this response. The
1187 server MUST send a final response after the request has been
1188 completed. See Section 6.2.3 of [Part1] for detailed discussion of
1189 the use and handling of this status code.
1191 7.1.2. 101 Switching Protocols
1193 The server understands and is willing to comply with the client's
1194 request, via the Upgrade message header field (Section 8.7 of
1195 [Part1]), for a change in the application protocol being used on this
1196 connection. The server will switch protocols to those defined by the
1197 response's Upgrade header field immediately after the empty line
1198 which terminates the 101 response.
1200 The protocol SHOULD be switched only when it is advantageous to do
1201 so. For example, switching to a newer version of HTTP is
1202 advantageous over older versions, and switching to a real-time,
1203 synchronous protocol might be advantageous when delivering resources
1204 that use such features.
1206 7.2. Successful 2xx
1208 This class of status code indicates that the client's request was
1209 successfully received, understood, and accepted.
1211 7.2.1. 200 OK
1213 The request has succeeded. The payload returned with the response is
1214 dependent on the method used in the request, for example:
1216 GET a representation of the target resource is sent in the response;
1218 HEAD the same representation as GET, except without the message-
1219 body;
1221 POST a representation describing or containing the result of the
1222 action;
1224 TRACE a representation containing the request message as received by
1225 the end server.
1227 Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to
1228 determine freshness for 200 responses.
1230 7.2.2. 201 Created
1232 The request has been fulfilled and has resulted in a new resource
1233 being created. The newly created resource can be referenced by the
1234 URI(s) returned in the payload of the response, with the most
1235 specific URI for the resource given by a Location header field. The
1236 response SHOULD include a payload containing a list of resource
1237 characteristics and location(s) from which the user or user agent can
1238 choose the one most appropriate. The payload format is specified by
1239 the media type given in the Content-Type header field. The origin
1240 server MUST create the resource before returning the 201 status code.
1241 If the action cannot be carried out immediately, the server SHOULD
1242 respond with 202 (Accepted) response instead.
1244 A 201 response MAY contain an ETag response header field indicating
1245 the current value of the entity-tag for the representation of the
1246 resource just created (see Section 2.3 of [Part4]).
1248 7.2.3. 202 Accepted
1250 The request has been accepted for processing, but the processing has
1251 not been completed. The request might or might not eventually be
1252 acted upon, as it might be disallowed when processing actually takes
1253 place. There is no facility for re-sending a status code from an
1254 asynchronous operation such as this.
1256 The 202 response is intentionally non-committal. Its purpose is to
1257 allow a server to accept a request for some other process (perhaps a
1258 batch-oriented process that is only run once per day) without
1259 requiring that the user agent's connection to the server persist
1260 until the process is completed. The representation returned with
1261 this response SHOULD include an indication of the request's current
1262 status and either a pointer to a status monitor or some estimate of
1263 when the user can expect the request to be fulfilled.
1265 7.2.4. 203 Non-Authoritative Information
1267 The representation in the response has been transformed or otherwise
1268 modified by a transforming proxy (Section 2.4 of [Part1]). Note that
1269 the behaviour of transforming intermediaries is controlled by the no-
1270 transform Cache-Control directive (Section 3.2 of [Part6]).
1272 This status code is only appropriate when the response status code
1273 would have been 200 (OK) otherwise. When the status code before
1274 transformation would have been different, the 214 Transformation
1275 Applied warn-code (Section 3.6 of [Part6]) is appropriate.
1277 Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to
1278 determine freshness for 203 responses.
1280 7.2.5. 204 No Content
1282 The 204 (No Content) status code indicates that the server has
1283 successfully fulfilled the request and that there is no additional
1284 content to return in the response payload body. Metadata in the
1285 response header fields refer to the target resource and its current
1286 representation after the requested action.
1288 For example, if a 204 status code is received in response to a PUT
1289 request and the response contains an ETag header field, then the PUT
1290 was successful and the ETag field-value contains the entity-tag for
1291 the new representation of that target resource.
1293 The 204 response allows a server to indicate that the action has been
1294 successfully applied to the target resource while implying that the
1295 user agent SHOULD NOT traverse away from its current "document view"
1296 (if any). The server assumes that the user agent will provide some
1297 indication of the success to its user, in accord with its own
1298 interface, and apply any new or updated metadata in the response to
1299 the active representation.
1301 For example, a 204 status code is commonly used with document editing
1302 interfaces corresponding to a "save" action, such that the document
1303 being saved remains available to the user for editing. It is also
1304 frequently used with interfaces that expect automated data transfers
1305 to be prevalent, such as within distributed version control systems.
1307 The 204 response MUST NOT include a message-body, and thus is always
1308 terminated by the first empty line after the header fields.
1310 7.2.6. 205 Reset Content
1312 The server has fulfilled the request and the user agent SHOULD reset
1313 the document view which caused the request to be sent. This response
1314 is primarily intended to allow input for actions to take place via
1315 user input, followed by a clearing of the form in which the input is
1316 given so that the user can easily initiate another input action.
1318 The message-body included with the response MUST be empty. Note that
1319 receivers still need to parse the response according to the algorithm
1320 defined in Section 3.3 of [Part1].
1322 7.2.7. 206 Partial Content
1324 The server has fulfilled the partial GET request for the resource and
1325 the enclosed payload is a partial representation as defined in
1326 Section 3.1 of [Part5].
1328 Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to
1329 determine freshness for 206 responses.
1331 7.3. Redirection 3xx
1333 This class of status code indicates that further action needs to be
1334 taken by the user agent in order to fulfill the request. If the
1335 required action involves a subsequent HTTP request, it MAY be carried
1336 out by the user agent without interaction with the user if and only
1337 if the method used in the second request is known to be "safe", as
1338 defined in Section 6.1.1.
1340 There are several types of redirects:
1342 1. Redirects of the request to another URI, either temporarily or
1343 permanently. The new URI is specified in the Location header
1344 field. In this specification, the status codes 301 (Moved
1345 Permanently), 302 (Found), and 307 (Temporary Redirect) fall
1346 under this category.
1348 2. Redirection to a new location that represents an indirect
1349 response to the request, such as the result of a POST operation
1350 to be retrieved with a subsequent GET request. This is status
1351 code 303 (See Other).
1353 3. Redirection offering a choice of matching resources for use by
1354 agent-driven content negotiation (Section 5.2 of [Part3]). This
1355 is status code 300 (Multiple Choices).
1357 4. Other kinds of redirection, such as to a cached result (status
1358 code 304 (Not Modified)).
1360 Note: In HTTP/1.0, only the status codes 301 (Moved Permanently)
1361 and 302 (Found) were defined for the first type of redirect, and
1362 the second type did not exist at all ([RFC1945], Section 9.3).
1363 However it turned out that web forms using POST expected redirects
1364 to change the operation for the subsequent request to retrieval
1365 (GET). To address this use case, HTTP/1.1 introduced the second
1366 type of redirect with the status code 303 (See Other) ([RFC2068],
1367 Section 10.3.4). As user agents did not change their behavior to
1368 maintain backwards compatibility, the first revision of HTTP/1.1
1369 added yet another status code, 307 (Temporary Redirect), for which
1370 the backwards compatibility problems did not apply ([RFC2616],
1371 Section 10.3.8). Over 10 years later, most user agents still do
1372 method rewriting for status codes 301 and 302, therefore this
1373 specification makes that behavior compliant in case the original
1374 request was POST.
1376 A Location header field on a 3xx response indicates that a client MAY
1377 automatically redirect to the URI provided; see Section 9.5.
1379 Clients SHOULD detect and intervene in cyclical redirections (i.e.,
1380 "infinite" redirection loops).
1382 Note: An earlier version of this specification recommended a
1383 maximum of five redirections ([RFC2068], Section 10.3). Content
1384 developers need to be aware that some clients might implement such
1385 a fixed limitation.
1387 7.3.1. 300 Multiple Choices
1389 The target resource has more than one representation, each with its
1390 own specific location, and agent-driven negotiation information
1391 (Section 5 of [Part3]) is being provided so that the user (or user
1392 agent) can select a preferred representation by redirecting its
1393 request to that location.
1395 Unless it was a HEAD request, the response SHOULD include a
1396 representation containing a list of representation metadata and
1397 location(s) from which the user or user agent can choose the one most
1398 appropriate. The data format is specified by the media type given in
1399 the Content-Type header field. Depending upon the format and the
1400 capabilities of the user agent, selection of the most appropriate
1401 choice MAY be performed automatically. However, this specification
1402 does not define any standard for such automatic selection.
1404 If the server has a preferred choice of representation, it SHOULD
1405 include the specific URI for that representation in the Location
1406 field; user agents MAY use the Location field value for automatic
1407 redirection.
1409 Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to
1410 determine freshness for 300 responses.
1412 7.3.2. 301 Moved Permanently
1414 The target resource has been assigned a new permanent URI and any
1415 future references to this resource SHOULD use one of the returned
1416 URIs. Clients with link editing capabilities ought to automatically
1417 re-link references to the effective request URI to one or more of the
1418 new references returned by the server, where possible.
1420 Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to
1421 determine freshness for 301 responses.
1423 The new permanent URI SHOULD be given by the Location field in the
1424 response. Unless the request method was HEAD, the representation of
1425 the response SHOULD contain a short hypertext note with a hyperlink
1426 to the new URI(s).
1428 If the 301 status code is received in response to a request method
1429 that is known to be "safe", as defined in Section 6.1.1, then the
1430 request MAY be automatically redirected by the user agent without
1431 confirmation. Otherwise, the user agent MUST NOT automatically
1432 redirect the request unless it can be confirmed by the user, since
1433 this might change the conditions under which the request was issued.
1435 Note: For historic reasons, user agents MAY change the request
1436 method from POST to GET for the subsequent request. If this
1437 behavior is undesired, status code 307 (Temporary Redirect) can be
1438 used instead.
1440 7.3.3. 302 Found
1442 The target resource resides temporarily under a different URI. Since
1443 the redirection might be altered on occasion, the client SHOULD
1444 continue to use the effective request URI for future requests.
1446 The temporary URI SHOULD be given by the Location field in the
1447 response. Unless the request method was HEAD, the representation of
1448 the response SHOULD contain a short hypertext note with a hyperlink
1449 to the new URI(s).
1451 If the 302 status code is received in response to a request method
1452 that is known to be "safe", as defined in Section 6.1.1, then the
1453 request MAY be automatically redirected by the user agent without
1454 confirmation. Otherwise, the user agent MUST NOT automatically
1455 redirect the request unless it can be confirmed by the user, since
1456 this might change the conditions under which the request was issued.
1458 Note: For historic reasons, user agents MAY change the request
1459 method from POST to GET for the subsequent request. If this
1460 behavior is undesired, status code 307 (Temporary Redirect) can be
1461 used instead. [[issue312: but see
1462 ]]
1464 7.3.4. 303 See Other
1466 The 303 status code indicates that the server is redirecting the user
1467 agent to a different resource, as indicated by a URI in the Location
1468 header field, that is intended to provide an indirect response to the
1469 original request. In order to satisfy the original request, a user
1470 agent SHOULD perform a retrieval request using the Location URI (a
1471 GET or HEAD request if using HTTP), which may itself be redirected
1472 further, and present the eventual result as an answer to the original
1473 request. Note that the new URI in the Location header field is not
1474 considered equivalent to the effective request URI.
1476 This status code is generally applicable to any HTTP method. It is
1477 primarily used to allow the output of a POST action to redirect the
1478 user agent to a selected resource, since doing so provides the
1479 information corresponding to the POST response in a form that can be
1480 separately identified, bookmarked, and cached independent of the
1481 original request.
1483 A 303 response to a GET request indicates that the requested resource
1484 does not have a representation of its own that can be transferred by
1485 the server over HTTP. The Location URI indicates a resource that is
1486 descriptive of the target resource, such that the follow-on
1487 representation might be useful to recipients without implying that it
1488 adequately represents the target resource. Note that answers to the
1489 questions of what can be represented, what representations are
1490 adequate, and what might be a useful description are outside the
1491 scope of HTTP and thus entirely determined by the URI owner(s).
1493 Except for responses to a HEAD request, the representation of a 303
1494 response SHOULD contain a short hypertext note with a hyperlink to
1495 the Location URI.
1497 7.3.5. 304 Not Modified
1499 The response to the request has not been modified since the
1500 conditions indicated by the client's conditional GET request, as
1501 defined in Section 4.1 of [Part4].
1503 7.3.6. 305 Use Proxy
1505 The 305 status code was defined in a previous version of this
1506 specification (see Appendix A), and is now deprecated.
1508 7.3.7. 306 (Unused)
1510 The 306 status code was used in a previous version of the
1511 specification, is no longer used, and the code is reserved.
1513 7.3.8. 307 Temporary Redirect
1515 The target resource resides temporarily under a different URI. Since
1516 the redirection can change over time, the client SHOULD continue to
1517 use the effective request URI for future requests.
1519 The temporary URI SHOULD be given by the Location field in the
1520 response. Unless the request method was HEAD, the representation of
1521 the response SHOULD contain a short hypertext note with a hyperlink
1522 to the new URI(s), since many pre-HTTP/1.1 user agents do not
1523 understand the 307 status code. Therefore, the note SHOULD contain
1524 the information necessary for a user to repeat the original request
1525 on the new URI.
1527 If the 307 status code is received in response to a request method
1528 that is known to be "safe", as defined in Section 6.1.1, then the
1529 request MAY be automatically redirected by the user agent without
1530 confirmation. Otherwise, the user agent MUST NOT automatically
1531 redirect the request unless it can be confirmed by the user, since
1532 this might change the conditions under which the request was issued.
1534 Note: This status code is similar to 302 Found, except that it
1535 does not allow rewriting the request method from POST to GET.
1536 This specification defines no equivalent counterpart for 301 Moved
1537 Permanently.
1539 7.4. Client Error 4xx
1541 The 4xx class of status code is intended for cases in which the
1542 client seems to have erred. Except when responding to a HEAD
1543 request, the server SHOULD include a representation containing an
1544 explanation of the error situation, and whether it is a temporary or
1545 permanent condition. These status codes are applicable to any
1546 request method. User agents SHOULD display any included
1547 representation to the user.
1549 If the client is sending data, a server implementation using TCP
1550 SHOULD be careful to ensure that the client acknowledges receipt of
1551 the packet(s) containing the response, before the server closes the
1552 input connection. If the client continues sending data to the server
1553 after the close, the server's TCP stack will send a reset packet to
1554 the client, which might erase the client's unacknowledged input
1555 buffers before they can be read and interpreted by the HTTP
1556 application.
1558 7.4.1. 400 Bad Request
1560 The server cannot or will not process the request, due to a client
1561 error (e.g., malformed syntax).
1563 7.4.2. 401 Unauthorized
1565 The request requires user authentication (see Section 3.1 of
1566 [Part7]).
1568 7.4.3. 402 Payment Required
1570 This code is reserved for future use.
1572 7.4.4. 403 Forbidden
1574 The server understood the request, but refuses to authorize it.
1575 Providing different user authentication credentials might be
1576 successful, but any credentials that were provided in the request are
1577 insufficient. The request SHOULD NOT be repeated with the same
1578 credentials.
1580 If the request method was not HEAD and the server wishes to make
1581 public why the request has not been fulfilled, it SHOULD describe the
1582 reason for the refusal in the representation. If the server does not
1583 wish to make this information available to the client, the status
1584 code 404 (Not Found) MAY be used instead.
1586 7.4.5. 404 Not Found
1588 The server has not found anything matching the effective request URI.
1589 No indication is given of whether the condition is temporary or
1590 permanent. The 410 (Gone) status code SHOULD be used if the server
1591 knows, through some internally configurable mechanism, that an old
1592 resource is permanently unavailable and has no forwarding address.
1593 This status code is commonly used when the server does not wish to
1594 reveal exactly why the request has been refused, or when no other
1595 response is applicable.
1597 7.4.6. 405 Method Not Allowed
1599 The method specified in the Request-Line is not allowed for the
1600 target resource. The response MUST include an Allow header field
1601 containing a list of valid methods for the requested resource.
1603 7.4.7. 406 Not Acceptable
1605 The resource identified by the request is only capable of generating
1606 response representations which have content characteristics not
1607 acceptable according to the Accept and Accept-* header fields sent in
1608 the request (see Section 6 of [Part3]).
1610 Unless it was a HEAD request, the response SHOULD include a
1611 representation containing a list of available representation
1612 characteristics and location(s) from which the user or user agent can
1613 choose the one most appropriate. The data format is specified by the
1614 media type given in the Content-Type header field. Depending upon
1615 the format and the capabilities of the user agent, selection of the
1616 most appropriate choice MAY be performed automatically. However,
1617 this specification does not define any standard for such automatic
1618 selection.
1620 Note: HTTP/1.1 servers are allowed to return responses which are
1621 not acceptable according to the accept header fields sent in the
1622 request. In some cases, this might even be preferable to sending
1623 a 406 response. User agents are encouraged to inspect the header
1624 fields of an incoming response to determine if it is acceptable.
1626 If the response could be unacceptable, a user agent SHOULD
1627 temporarily stop receipt of more data and query the user for a
1628 decision on further actions.
1630 7.4.8. 407 Proxy Authentication Required
1632 This code is similar to 401 (Unauthorized), but indicates that the
1633 client must first authenticate itself with the proxy (see Section 3.2
1634 of [Part7]).
1636 7.4.9. 408 Request Timeout
1638 The client did not produce a request within the time that the server
1639 was prepared to wait. The client MAY repeat the request without
1640 modifications at any later time.
1642 7.4.10. 409 Conflict
1644 The request could not be completed due to a conflict with the current
1645 state of the resource. This code is only allowed in situations where
1646 it is expected that the user might be able to resolve the conflict
1647 and resubmit the request. The response body SHOULD include enough
1648 information for the user to recognize the source of the conflict.
1649 Ideally, the response representation would include enough information
1650 for the user or user agent to fix the problem; however, that might
1651 not be possible and is not required.
1653 Conflicts are most likely to occur in response to a PUT request. For
1654 example, if versioning were being used and the representation being
1655 PUT included changes to a resource which conflict with those made by
1656 an earlier (third-party) request, the server might use the 409
1657 response to indicate that it can't complete the request. In this
1658 case, the response representation would likely contain a list of the
1659 differences between the two versions in a format defined by the
1660 response Content-Type.
1662 7.4.11. 410 Gone
1664 The target resource is no longer available at the server and no
1665 forwarding address is known. This condition is expected to be
1666 considered permanent. Clients with link editing capabilities SHOULD
1667 delete references to the effective request URI after user approval.
1668 If the server does not know, or has no facility to determine, whether
1669 or not the condition is permanent, the status code 404 (Not Found)
1670 SHOULD be used instead.
1672 The 410 response is primarily intended to assist the task of web
1673 maintenance by notifying the recipient that the resource is
1674 intentionally unavailable and that the server owners desire that
1675 remote links to that resource be removed. Such an event is common
1676 for limited-time, promotional services and for resources belonging to
1677 individuals no longer working at the server's site. It is not
1678 necessary to mark all permanently unavailable resources as "gone" or
1679 to keep the mark for any length of time -- that is left to the
1680 discretion of the server owner.
1682 Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to
1683 determine freshness for 410 responses.
1685 7.4.12. 411 Length Required
1687 The server refuses to accept the request without a defined Content-
1688 Length. The client MAY repeat the request if it adds a valid
1689 Content-Length header field containing the length of the message-body
1690 in the request message.
1692 7.4.13. 412 Precondition Failed
1694 The precondition given in one or more of the header fields evaluated
1695 to false when it was tested on the server, as defined in Section 4.2
1696 of [Part4].
1698 7.4.14. 413 Request Representation Too Large
1700 The server is refusing to process a request because the request
1701 representation is larger than the server is willing or able to
1702 process. The server MAY close the connection to prevent the client
1703 from continuing the request.
1705 If the condition is temporary, the server SHOULD include a Retry-
1706 After header field to indicate that it is temporary and after what
1707 time the client MAY try again.
1709 7.4.15. 414 URI Too Long
1711 The server is refusing to service the request because the effective
1712 request URI is longer than the server is willing to interpret. This
1713 rare condition is only likely to occur when a client has improperly
1714 converted a POST request to a GET request with long query
1715 information, when the client has descended into a URI "black hole" of
1716 redirection (e.g., a redirected URI prefix that points to a suffix of
1717 itself), or when the server is under attack by a client attempting to
1718 exploit security holes present in some servers using fixed-length
1719 buffers for reading or manipulating the effective request URI.
1721 7.4.16. 415 Unsupported Media Type
1723 The server is refusing to service the request because the request
1724 payload is in a format not supported by this request method on the
1725 target resource.
1727 7.4.17. 416 Requested Range Not Satisfiable
1729 The request included a Range header field (Section 5.4 of [Part5])
1730 and none of the range-specifier values in this field overlap the
1731 current extent of the selected resource. See Section 3.2 of [Part5].
1733 7.4.18. 417 Expectation Failed
1735 The expectation given in an Expect header field (see Section 9.3)
1736 could not be met by this server, or, if the server is a proxy, the
1737 server has unambiguous evidence that the request could not be met by
1738 the next-hop server.
1740 7.4.19. 426 Upgrade Required
1742 The request can not be completed without a prior protocol upgrade.
1743 This response MUST include an Upgrade header field (Section 8.7 of
1744 [Part1]) specifying the required protocols.
1746 Example:
1748 HTTP/1.1 426 Upgrade Required
1749 Upgrade: HTTP/2.0
1750 Connection: Upgrade
1752 The server SHOULD include a message body in the 426 response which
1753 indicates in human readable form the reason for the error and
1754 describes any alternative courses which may be available to the user.
1756 7.5. Server Error 5xx
1758 Response status codes beginning with the digit "5" indicate cases in
1759 which the server is aware that it has erred or is incapable of
1760 performing the request. Except when responding to a HEAD request,
1761 the server SHOULD include a representation containing an explanation
1762 of the error situation, and whether it is a temporary or permanent
1763 condition. User agents SHOULD display any included representation to
1764 the user. These response codes are applicable to any request method.
1766 7.5.1. 500 Internal Server Error
1768 The server encountered an unexpected condition which prevented it
1769 from fulfilling the request.
1771 7.5.2. 501 Not Implemented
1773 The server does not support the functionality required to fulfill the
1774 request. This is the appropriate response when the server does not
1775 recognize the request method and is not capable of supporting it for
1776 any resource.
1778 7.5.3. 502 Bad Gateway
1780 The server, while acting as a gateway or proxy, received an invalid
1781 response from the upstream server it accessed in attempting to
1782 fulfill the request.
1784 7.5.4. 503 Service Unavailable
1786 The server is currently unable to handle the request due to a
1787 temporary overloading or maintenance of the server.
1789 The implication is that this is a temporary condition which will be
1790 alleviated after some delay. If known, the length of the delay MAY
1791 be indicated in a Retry-After header field (Section 9.8). If no
1792 Retry-After is given, the client SHOULD handle the response as it
1793 would for a 500 response.
1795 Note: The existence of the 503 status code does not imply that a
1796 server must use it when becoming overloaded. Some servers might
1797 wish to simply refuse the connection.
1799 7.5.5. 504 Gateway Timeout
1801 The server, while acting as a gateway or proxy, did not receive a
1802 timely response from the upstream server specified by the URI (e.g.,
1803 HTTP, FTP, LDAP) or some other auxiliary server (e.g., DNS) it needed
1804 to access in attempting to complete the request.
1806 Note to implementors: some deployed proxies are known to return
1807 400 or 500 when DNS lookups time out.
1809 7.5.6. 505 HTTP Version Not Supported
1811 The server does not support, or refuses to support, the protocol
1812 version that was used in the request message. The server is
1813 indicating that it is unable or unwilling to complete the request
1814 using the same major version as the client, as described in Section
1815 2.6 of [Part1], other than with this error message. The response
1816 SHOULD contain a representation describing why that version is not
1817 supported and what other protocols are supported by that server.
1819 8. Date/Time Formats
1821 HTTP applications have historically allowed three different formats
1822 for date/time stamps. However, the preferred format is a fixed-
1823 length subset of that defined by [RFC1123]:
1825 Sun, 06 Nov 1994 08:49:37 GMT ; RFC 1123
1827 The other formats are described here only for compatibility with
1828 obsolete implementations.
1830 Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format
1831 Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format
1833 HTTP/1.1 clients and servers that parse a date value MUST accept all
1834 three formats (for compatibility with HTTP/1.0), though they MUST
1835 only generate the RFC 1123 format for representing HTTP-date values
1836 in header fields.
1838 All HTTP date/time stamps MUST be represented in Greenwich Mean Time
1839 (GMT), without exception. For the purposes of HTTP, GMT is exactly
1840 equal to UTC (Coordinated Universal Time). This is indicated in the
1841 first two formats by the inclusion of "GMT" as the three-letter
1842 abbreviation for time zone, and MUST be assumed when reading the
1843 asctime format. HTTP-date is case sensitive and MUST NOT include
1844 additional whitespace beyond that specifically included as SP in the
1845 grammar.
1847 HTTP-date = rfc1123-date / obs-date
1849 Preferred format:
1851 rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT
1852 ; fixed length subset of the format defined in
1853 ; Section 5.2.14 of [RFC1123]
1855 day-name = %x4D.6F.6E ; "Mon", case-sensitive
1856 / %x54.75.65 ; "Tue", case-sensitive
1857 / %x57.65.64 ; "Wed", case-sensitive
1858 / %x54.68.75 ; "Thu", case-sensitive
1859 / %x46.72.69 ; "Fri", case-sensitive
1860 / %x53.61.74 ; "Sat", case-sensitive
1861 / %x53.75.6E ; "Sun", case-sensitive
1863 date1 = day SP month SP year
1864 ; e.g., 02 Jun 1982
1866 day = 2DIGIT
1867 month = %x4A.61.6E ; "Jan", case-sensitive
1868 / %x46.65.62 ; "Feb", case-sensitive
1869 / %x4D.61.72 ; "Mar", case-sensitive
1870 / %x41.70.72 ; "Apr", case-sensitive
1871 / %x4D.61.79 ; "May", case-sensitive
1872 / %x4A.75.6E ; "Jun", case-sensitive
1873 / %x4A.75.6C ; "Jul", case-sensitive
1874 / %x41.75.67 ; "Aug", case-sensitive
1875 / %x53.65.70 ; "Sep", case-sensitive
1876 / %x4F.63.74 ; "Oct", case-sensitive
1877 / %x4E.6F.76 ; "Nov", case-sensitive
1878 / %x44.65.63 ; "Dec", case-sensitive
1879 year = 4DIGIT
1881 GMT = %x47.4D.54 ; "GMT", case-sensitive
1883 time-of-day = hour ":" minute ":" second
1884 ; 00:00:00 - 23:59:59
1886 hour = 2DIGIT
1887 minute = 2DIGIT
1888 second = 2DIGIT
1890 The semantics of day-name, day, month, year, and time-of-day are the
1891 same as those defined for the RFC 5322 constructs with the
1892 corresponding name ([RFC5322], Section 3.3).
1894 Obsolete formats:
1896 obs-date = rfc850-date / asctime-date
1897 rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT
1898 date2 = day "-" month "-" 2DIGIT
1899 ; day-month-year (e.g., 02-Jun-82)
1901 day-name-l = %x4D.6F.6E.64.61.79 ; "Monday", case-sensitive
1902 / %x54.75.65.73.64.61.79 ; "Tuesday", case-sensitive
1903 / %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive
1904 / %x54.68.75.72.73.64.61.79 ; "Thursday", case-sensitive
1905 / %x46.72.69.64.61.79 ; "Friday", case-sensitive
1906 / %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive
1907 / %x53.75.6E.64.61.79 ; "Sunday", case-sensitive
1909 asctime-date = day-name SP date3 SP time-of-day SP year
1910 date3 = month SP ( 2DIGIT / ( SP 1DIGIT ))
1911 ; month day (e.g., Jun 2)
1913 Note: Recipients of date values are encouraged to be robust in
1914 accepting date values that might have been sent by non-HTTP
1915 applications, as is sometimes the case when retrieving or posting
1916 messages via proxies/gateways to SMTP or NNTP.
1918 Note: HTTP requirements for the date/time stamp format apply only
1919 to their usage within the protocol stream. Clients and servers
1920 are not required to use these formats for user presentation,
1921 request logging, etc.
1923 9. Header Field Definitions
1925 This section defines the syntax and semantics of HTTP/1.1 header
1926 fields related to request and response semantics.
1928 9.1. Allow
1930 The "Allow" header field lists the set of methods advertised as
1931 supported by the target resource. The purpose of this field is
1932 strictly to inform the recipient of valid request methods associated
1933 with the resource.
1935 Allow = #Method
1937 Example of use:
1939 Allow: GET, HEAD, PUT
1941 The actual set of allowed methods is defined by the origin server at
1942 the time of each request.
1944 A proxy MUST NOT modify the Allow header field -- it does not need to
1945 understand all the methods specified in order to handle them
1946 according to the generic message handling rules.
1948 9.2. Date
1950 The "Date" header field represents the date and time at which the
1951 message was originated, having the same semantics as the Origination
1952 Date Field (orig-date) defined in Section 3.6.1 of [RFC5322]. The
1953 field value is an HTTP-date, as defined in Section 8; it MUST be sent
1954 in rfc1123-date format.
1956 Date = HTTP-date
1958 An example is
1960 Date: Tue, 15 Nov 1994 08:12:31 GMT
1962 Origin servers MUST include a Date header field in all responses,
1963 except in these cases:
1965 1. If the response status code is 100 (Continue) or 101 (Switching
1966 Protocols), the response MAY include a Date header field, at the
1967 server's option.
1969 2. If the response status code conveys a server error, e.g., 500
1970 (Internal Server Error) or 503 (Service Unavailable), and it is
1971 inconvenient or impossible to generate a valid Date.
1973 3. If the server does not have a clock that can provide a reasonable
1974 approximation of the current time, its responses MUST NOT include
1975 a Date header field.
1977 A received message that does not have a Date header field MUST be
1978 assigned one by the recipient if the message will be cached by that
1979 recipient.
1981 Clients can use the Date header field as well; in order to keep
1982 request messages small, they are advised not to include it when it
1983 doesn't convey any useful information (as it is usually the case for
1984 requests that do not contain a payload).
1986 The HTTP-date sent in a Date header field SHOULD NOT represent a date
1987 and time subsequent to the generation of the message. It SHOULD
1988 represent the best available approximation of the date and time of
1989 message generation, unless the implementation has no means of
1990 generating a reasonably accurate date and time. In theory, the date
1991 ought to represent the moment just before the payload is generated.
1993 In practice, the date can be generated at any time during the message
1994 origination without affecting its semantic value.
1996 9.3. Expect
1998 The "Expect" header field is used to indicate that particular server
1999 behaviors are required by the client.
2001 Expect = 1#expectation
2003 expectation = expect-name [ BWS "=" BWS expect-value ]
2004 *( OWS ";" [ OWS expect-param ] )
2005 expect-param = expect-name [ BWS "=" BWS expect-value ]
2007 expect-name = token
2008 expect-value = token / quoted-string
2010 If all received Expect header field(s) are syntactically valid but
2011 contain an expectation that the recipient does not understand or
2012 cannot comply with, the recipient MUST respond with a 417
2013 (Expectation Failed) status code. A recipient of a syntactically
2014 invalid Expectation header field MUST respond with a 4xx status code
2015 other than 417.
2017 The only expectation defined by this specification is:
2019 100-continue
2021 The "100-continue" expectation is defined Section 6.2.3 of
2022 [Part1]. It does not support any expect-params.
2024 Comparison is case-insensitive for names (expect-name), and case-
2025 sensitive for values (expect-value).
2027 The Expect mechanism is hop-by-hop: the above requirements apply to
2028 any server, including proxies. However, the Expect header field
2029 itself is end-to-end; it MUST be forwarded if the request is
2030 forwarded.
2032 Many older HTTP/1.0 and HTTP/1.1 applications do not understand the
2033 Expect header field.
2035 9.4. From
2037 The "From" header field, if given, SHOULD contain an Internet e-mail
2038 address for the human user who controls the requesting user agent.
2039 The address SHOULD be machine-usable, as defined by "mailbox" in
2040 Section 3.4 of [RFC5322]:
2042 From = mailbox
2044 mailbox =
2046 An example is:
2048 From: webmaster@example.org
2050 This header field MAY be used for logging purposes and as a means for
2051 identifying the source of invalid or unwanted requests. It SHOULD
2052 NOT be used as an insecure form of access protection. The
2053 interpretation of this field is that the request is being performed
2054 on behalf of the person given, who accepts responsibility for the
2055 method performed. In particular, robot agents SHOULD include this
2056 header field so that the person responsible for running the robot can
2057 be contacted if problems occur on the receiving end.
2059 The Internet e-mail address in this field MAY be separate from the
2060 Internet host which issued the request. For example, when a request
2061 is passed through a proxy the original issuer's address SHOULD be
2062 used.
2064 The client SHOULD NOT send the From header field without the user's
2065 approval, as it might conflict with the user's privacy interests or
2066 their site's security policy. It is strongly recommended that the
2067 user be able to disable, enable, and modify the value of this field
2068 at any time prior to a request.
2070 9.5. Location
2072 The "Location" header field is used to identify a newly created
2073 resource, or to redirect the recipient to a different location for
2074 completion of the request.
2076 For 201 (Created) responses, the Location is the URI of the new
2077 resource which was created by the request. For 3xx responses, the
2078 location SHOULD indicate the server's preferred URI for automatic
2079 redirection to the resource.
2081 The field value consists of a single URI-reference. When it has the
2082 form of a relative reference ([RFC3986], Section 4.2), the final
2083 value is computed by resolving it against the effective request URI
2084 ([RFC3986], Section 5).
2086 Location = URI-reference
2088 Examples are:
2090 Location: http://www.example.org/pub/WWW/People.html#tim
2092 Location: /index.html
2094 Note: Some recipients attempt to recover from Location fields that
2095 are not valid URI references. This specification does not mandate
2096 or define such processing, but does allow it (see Section 1.1).
2098 There are circumstances in which a fragment identifier in a Location
2099 URI would not be appropriate. For instance, when it appears in a 201
2100 Created response, where the Location header field specifies the URI
2101 for the entire created resource.
2103 Note: This specification does not define precedence rules for the
2104 case where the original URI, as navigated to by the user agent,
2105 and the Location header field value both contain fragment
2106 identifiers. Thus be aware that including fragment identifiers
2107 might inconvenience anyone relying on the semantics of the
2108 original URI's fragment identifier.
2110 Note: The Content-Location header field (Section 6.7 of [Part3])
2111 differs from Location in that the Content-Location identifies the
2112 most specific resource corresponding to the enclosed
2113 representation. It is therefore possible for a response to
2114 contain header fields for both Location and Content-Location.
2116 9.6. Max-Forwards
2118 The "Max-Forwards" header field provides a mechanism with the TRACE
2119 (Section 6.8) and OPTIONS (Section 6.2) methods to limit the number
2120 of times that the request is forwarded by proxies. This can be
2121 useful when the client is attempting to trace a request which appears
2122 to be failing or looping in mid-chain.
2124 Max-Forwards = 1*DIGIT
2126 The Max-Forwards value is a decimal integer indicating the remaining
2127 number of times this request message can be forwarded.
2129 Each recipient of a TRACE or OPTIONS request containing a Max-
2130 Forwards header field MUST check and update its value prior to
2131 forwarding the request. If the received value is zero (0), the
2132 recipient MUST NOT forward the request; instead, it MUST respond as
2133 the final recipient. If the received Max-Forwards value is greater
2134 than zero, then the forwarded message MUST contain an updated Max-
2135 Forwards field with a value decremented by one (1).
2137 The Max-Forwards header field MAY be ignored for all other request
2138 methods.
2140 9.7. Referer
2142 The "Referer" [sic] header field allows the client to specify the URI
2143 of the resource from which the effective request URI was obtained
2144 (the "referrer", although the header field is misspelled.).
2146 The Referer header field allows servers to generate lists of back-
2147 links to resources for interest, logging, optimized caching, etc. It
2148 also allows obsolete or mistyped links to be traced for maintenance.
2149 Some servers use Referer as a means of controlling where they allow
2150 links from (so-called "deep linking"), but legitimate requests do not
2151 always contain a Referer header field.
2153 If the effective request URI was obtained from a source that does not
2154 have its own URI (e.g., input from the user keyboard), the Referer
2155 field MUST either be sent with the value "about:blank", or not be
2156 sent at all. Note that this requirement does not apply to sources
2157 with non-HTTP URIs (e.g., FTP).
2159 Referer = absolute-URI / partial-URI
2161 Example:
2163 Referer: http://www.example.org/hypertext/Overview.html
2165 If the field value is a relative URI, it SHOULD be interpreted
2166 relative to the effective request URI. The URI MUST NOT include a
2167 fragment. See Section 11.2 for security considerations.
2169 9.8. Retry-After
2171 The header "Retry-After" field can be used with a 503 (Service
2172 Unavailable) response to indicate how long the service is expected to
2173 be unavailable to the requesting client. This field MAY also be used
2174 with any 3xx (Redirection) response to indicate the minimum time the
2175 user-agent is asked wait before issuing the redirected request.
2177 The value of this field can be either an HTTP-date or an integer
2178 number of seconds (in decimal) after the time of the response.
2180 Retry-After = HTTP-date / delta-seconds
2182 Time spans are non-negative decimal integers, representing time in
2183 seconds.
2185 delta-seconds = 1*DIGIT
2187 Two examples of its use are
2189 Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
2190 Retry-After: 120
2192 In the latter example, the delay is 2 minutes.
2194 9.9. Server
2196 The "Server" header field contains information about the software
2197 used by the origin server to handle the request.
2199 The field can contain multiple product tokens (Section 5.2 of
2200 [Part1]) and comments (Section 3.2 of [Part1]) identifying the server
2201 and any significant subproducts. The product tokens are listed in
2202 order of their significance for identifying the application.
2204 Server = product *( RWS ( product / comment ) )
2206 Example:
2208 Server: CERN/3.0 libwww/2.17
2210 If the response is being forwarded through a proxy, the proxy
2211 application MUST NOT modify the Server header field. Instead, it
2212 MUST include a Via field (as described in Section 8.8 of [Part1]).
2214 Note: Revealing the specific software version of the server might
2215 allow the server machine to become more vulnerable to attacks
2216 against software that is known to contain security holes. Server
2217 implementors are encouraged to make this field a configurable
2218 option.
2220 9.10. User-Agent
2222 The "User-Agent" header field contains information about the user
2223 agent originating the request. User agents SHOULD include this field
2224 with requests.
2226 Typically, it is used for statistical purposes, the tracing of
2227 protocol violations, and tailoring responses to avoid particular user
2228 agent limitations.
2230 The field can contain multiple product tokens (Section 5.2 of
2231 [Part1]) and comments (Section 3.2 of [Part1]) identifying the agent
2232 and its significant subproducts. By convention, the product tokens
2233 are listed in order of their significance for identifying the
2234 application.
2236 Because this field is usually sent on every request a user agent
2237 makes, implementations are encouraged not to include needlessly fine-
2238 grained detail, and to limit (or even prohibit) the addition of
2239 subproducts by third parties. Overly long and detailed User-Agent
2240 field values make requests larger and can also be used to identify
2241 ("fingerprint") the user against their wishes.
2243 Likewise, implementations are encouraged not to use the product
2244 tokens of other implementations in order to declare compatibility
2245 with them, as this circumvents the purpose of the field. Finally,
2246 they are encouraged not to use comments to identify products; doing
2247 so makes the field value more difficult to parse.
2249 User-Agent = product *( RWS ( product / comment ) )
2251 Example:
2253 User-Agent: CERN-LineMode/2.15 libwww/2.17b3
2255 10. IANA Considerations
2257 10.1. Method Registry
2259 The registration procedure for HTTP request methods is defined by
2260 Section 2.2 of this document.
2262 The HTTP Method Registry shall be created at
2263 and be populated with
2264 the registrations below:
2266 +---------+------+-------------+
2267 | Method | Safe | Reference |
2268 +---------+------+-------------+
2269 | CONNECT | no | Section 6.9 |
2270 | DELETE | no | Section 6.7 |
2271 | GET | yes | Section 6.3 |
2272 | HEAD | yes | Section 6.4 |
2273 | OPTIONS | yes | Section 6.2 |
2274 | POST | no | Section 6.5 |
2275 | PUT | no | Section 6.6 |
2276 | TRACE | yes | Section 6.8 |
2277 +---------+------+-------------+
2279 10.2. Status Code Registry
2281 The registration procedure for HTTP Status Codes -- previously
2282 defined in Section 7.1 of [RFC2817] -- is now defined by Section 4.2
2283 of this document.
2285 The HTTP Status Code Registry located at
2286 shall be updated
2287 with the registrations below:
2289 +-------+----------------------------------+----------------+
2290 | Value | Description | Reference |
2291 +-------+----------------------------------+----------------+
2292 | 100 | Continue | Section 7.1.1 |
2293 | 101 | Switching Protocols | Section 7.1.2 |
2294 | 200 | OK | Section 7.2.1 |
2295 | 201 | Created | Section 7.2.2 |
2296 | 202 | Accepted | Section 7.2.3 |
2297 | 203 | Non-Authoritative Information | Section 7.2.4 |
2298 | 204 | No Content | Section 7.2.5 |
2299 | 205 | Reset Content | Section 7.2.6 |
2300 | 300 | Multiple Choices | Section 7.3.1 |
2301 | 301 | Moved Permanently | Section 7.3.2 |
2302 | 302 | Found | Section 7.3.3 |
2303 | 303 | See Other | Section 7.3.4 |
2304 | 305 | Use Proxy | Section 7.3.6 |
2305 | 306 | (Unused) | Section 7.3.7 |
2306 | 307 | Temporary Redirect | Section 7.3.8 |
2307 | 400 | Bad Request | Section 7.4.1 |
2308 | 402 | Payment Required | Section 7.4.3 |
2309 | 403 | Forbidden | Section 7.4.4 |
2310 | 404 | Not Found | Section 7.4.5 |
2311 | 405 | Method Not Allowed | Section 7.4.6 |
2312 | 406 | Not Acceptable | Section 7.4.7 |
2313 | 407 | Proxy Authentication Required | Section 7.4.8 |
2314 | 408 | Request Timeout | Section 7.4.9 |
2315 | 409 | Conflict | Section 7.4.10 |
2316 | 410 | Gone | Section 7.4.11 |
2317 | 411 | Length Required | Section 7.4.12 |
2318 | 413 | Request Representation Too Large | Section 7.4.14 |
2319 | 414 | URI Too Long | Section 7.4.15 |
2320 | 415 | Unsupported Media Type | Section 7.4.16 |
2321 | 417 | Expectation Failed | Section 7.4.18 |
2322 | 426 | Upgrade Required | Section 7.4.19 |
2323 | 500 | Internal Server Error | Section 7.5.1 |
2324 | 501 | Not Implemented | Section 7.5.2 |
2325 | 502 | Bad Gateway | Section 7.5.3 |
2326 | 503 | Service Unavailable | Section 7.5.4 |
2327 | 504 | Gateway Timeout | Section 7.5.5 |
2328 | 505 | HTTP Version Not Supported | Section 7.5.6 |
2329 +-------+----------------------------------+----------------+
2331 10.3. Header Field Registration
2333 The Message Header Field Registry located at shall be
2335 updated with the permanent registrations below (see [RFC3864]):
2337 +-------------------+----------+----------+--------------+
2338 | Header Field Name | Protocol | Status | Reference |
2339 +-------------------+----------+----------+--------------+
2340 | Allow | http | standard | Section 9.1 |
2341 | Date | http | standard | Section 9.2 |
2342 | Expect | http | standard | Section 9.3 |
2343 | From | http | standard | Section 9.4 |
2344 | Location | http | standard | Section 9.5 |
2345 | Max-Forwards | http | standard | Section 9.6 |
2346 | Referer | http | standard | Section 9.7 |
2347 | Retry-After | http | standard | Section 9.8 |
2348 | Server | http | standard | Section 9.9 |
2349 | User-Agent | http | standard | Section 9.10 |
2350 +-------------------+----------+----------+--------------+
2352 The change controller is: "IETF (iesg@ietf.org) - Internet
2353 Engineering Task Force".
2355 11. Security Considerations
2357 This section is meant to inform application developers, information
2358 providers, and users of the security limitations in HTTP/1.1 as
2359 described by this document. The discussion does not include
2360 definitive solutions to the problems revealed, though it does make
2361 some suggestions for reducing security risks.
2363 11.1. Transfer of Sensitive Information
2365 Like any generic data transfer protocol, HTTP cannot regulate the
2366 content of the data that is transferred, nor is there any a priori
2367 method of determining the sensitivity of any particular piece of
2368 information within the context of any given request. Therefore,
2369 applications SHOULD supply as much control over this information as
2370 possible to the provider of that information. Four header fields are
2371 worth special mention in this context: Server, Via, Referer and From.
2373 Revealing the specific software version of the server might allow the
2374 server machine to become more vulnerable to attacks against software
2375 that is known to contain security holes. Implementors SHOULD make
2376 the Server header field a configurable option.
2378 Proxies which serve as a portal through a network firewall SHOULD
2379 take special precautions regarding the transfer of header information
2380 that identifies the hosts behind the firewall. In particular, they
2381 SHOULD remove, or replace with sanitized versions, any Via fields
2382 generated behind the firewall.
2384 The Referer header field allows reading patterns to be studied and
2385 reverse links drawn. Although it can be very useful, its power can
2386 be abused if user details are not separated from the information
2387 contained in the Referer. Even when the personal information has
2388 been removed, the Referer header field might indicate a private
2389 document's URI whose publication would be inappropriate.
2391 The information sent in the From field might conflict with the user's
2392 privacy interests or their site's security policy, and hence it
2393 SHOULD NOT be transmitted without the user being able to disable,
2394 enable, and modify the contents of the field. The user MUST be able
2395 to set the contents of this field within a user preference or
2396 application defaults configuration.
2398 We suggest, though do not require, that a convenient toggle interface
2399 be provided for the user to enable or disable the sending of From and
2400 Referer information.
2402 The User-Agent (Section 9.10) or Server (Section 9.9) header fields
2403 can sometimes be used to determine that a specific client or server
2404 have a particular security hole which might be exploited.
2405 Unfortunately, this same information is often used for other valuable
2406 purposes for which HTTP currently has no better mechanism.
2408 Furthermore, the User-Agent header field may contain enough entropy
2409 to be used, possibly in conjunction with other material, to uniquely
2410 identify the user.
2412 Some request methods, like TRACE (Section 6.8), expose information
2413 that was sent in request header fields within the body of their
2414 response. Clients SHOULD be careful with sensitive information, like
2415 Cookies, Authorization credentials, and other header fields that
2416 might be used to collect data from the client.
2418 11.2. Encoding Sensitive Information in URIs
2420 Because the source of a link might be private information or might
2421 reveal an otherwise private information source, it is strongly
2422 recommended that the user be able to select whether or not the
2423 Referer field is sent. For example, a browser client could have a
2424 toggle switch for browsing openly/anonymously, which would
2425 respectively enable/disable the sending of Referer and From
2426 information.
2428 Clients SHOULD NOT include a Referer header field in a (non-secure)
2429 HTTP request if the referring page was transferred with a secure
2430 protocol.
2432 Authors of services SHOULD NOT use GET-based forms for the submission
2433 of sensitive data because that data will be placed in the request-
2434 target. Many existing servers, proxies, and user agents log or
2435 display the request-target in places where it might be visible to
2436 third parties. Such services can use POST-based form submission
2437 instead.
2439 11.3. Location Headers and Spoofing
2441 If a single server supports multiple organizations that do not trust
2442 one another, then it MUST check the values of Location and Content-
2443 Location header fields in responses that are generated under control
2444 of said organizations to make sure that they do not attempt to
2445 invalidate resources over which they have no authority.
2447 11.4. Security Considerations for CONNECT
2449 Since tunneled data is opaque to the proxy, there are additional
2450 risks to tunneling to other well-known or reserved ports. A HTTP
2451 client CONNECTing to port 25 could relay spam via SMTP, for example.
2452 As such, proxies SHOULD restrict CONNECT access to a small number of
2453 known ports.
2455 12. Acknowledgments
2457 See Section 11 of [Part1].
2459 13. References
2461 13.1. Normative References
2463 [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
2464 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
2465 and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,
2466 and Message Parsing", draft-ietf-httpbis-p1-messaging-18
2467 (work in progress), January 2012.
2469 [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
2470 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
2471 and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload
2472 and Content Negotiation", draft-ietf-httpbis-p3-payload-18
2473 (work in progress), January 2012.
2475 [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
2476 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
2477 and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional
2478 Requests", draft-ietf-httpbis-p4-conditional-18 (work in
2479 progress), January 2012.
2481 [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
2482 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
2483 and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and
2484 Partial Responses", draft-ietf-httpbis-p5-range-18 (work
2485 in progress), January 2012.
2487 [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
2488 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
2489 Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part
2490 6: Caching", draft-ietf-httpbis-p6-cache-18 (work in
2491 progress), January 2012.
2493 [Part7] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
2494 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
2495 and J. Reschke, Ed., "HTTP/1.1, part 7: Authentication",
2496 draft-ietf-httpbis-p7-auth-18 (work in progress),
2497 January 2012.
2499 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
2500 Requirement Levels", BCP 14, RFC 2119, March 1997.
2502 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
2503 Resource Identifier (URI): Generic Syntax", STD 66,
2504 RFC 3986, January 2005.
2506 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
2507 Specifications: ABNF", STD 68, RFC 5234, January 2008.
2509 13.2. Informative References
2511 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application
2512 and Support", STD 3, RFC 1123, October 1989.
2514 [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext
2515 Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
2517 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.
2518 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
2519 RFC 2068, January 1997.
2521 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
2522 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
2523 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
2525 [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within
2526 HTTP/1.1", RFC 2817, May 2000.
2528 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
2529 Procedures for Message Header Fields", BCP 90, RFC 3864,
2530 September 2004.
2532 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
2533 IANA Considerations Section in RFCs", BCP 26, RFC 5226,
2534 May 2008.
2536 [RFC5322] Resnick, P., "Internet Message Format", RFC 5322,
2537 October 2008.
2539 [RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP",
2540 RFC 5789, March 2010.
2542 [RFC5987] Reschke, J., "Character Set and Language Encoding for
2543 Hypertext Transfer Protocol (HTTP) Header Field
2544 Parameters", RFC 5987, August 2010.
2546 Appendix A. Changes from RFC 2616
2548 This document takes over the Status Code Registry, previously defined
2549 in Section 7.1 of [RFC2817]. (Section 4.2)
2551 Clarify definition of POST. (Section 6.5)
2553 Remove requirement to handle all Content-* header fields; ban use of
2554 Content-Range with PUT. (Section 6.6)
2556 Take over definition of CONNECT method from [RFC2817]. (Section 6.9)
2558 Broadened the definition of 203 (Non-Authoritative Information) to
2559 include cases of payload transformations as well. (Section 7.2.4)
2561 Failed to consider that there are many other request methods that are
2562 safe to automatically redirect, and further that the user agent is
2563 able to make that determination based on the request method
2564 semantics. Furthermore, allow user agents to rewrite the method from
2565 POST to GET for status codes 301 and 302. (Sections 7.3.2, 7.3.3 and
2566 7.3.8)
2568 Deprecate 305 Use Proxy status code, because user agents did not
2569 implement it. It used to indicate that the target resource must be
2570 accessed through the proxy given by the Location field. The Location
2571 field gave the URI of the proxy. The recipient was expected to
2572 repeat this single request via the proxy. (Section 7.3.6)
2574 Define status 426 (Upgrade Required) (this was incorporated from
2575 [RFC2817]). (Section 7.4.19)
2576 Change ABNF productions for header fields to only define the field
2577 value. (Section 9)
2579 Reclassify "Allow" as response header field, removing the option to
2580 specify it in a PUT request. Relax the server requirement on the
2581 contents of the Allow header field and remove requirement on clients
2582 to always trust the header field value. (Section 9.1)
2584 The ABNF for the Expect header field has been both fixed (allowing
2585 parameters for value-less expectations as well) and simplified
2586 (allowing trailing semicolons after "100-continue" when they were
2587 invalid before). (Section 9.3)
2589 Correct syntax of Location header field to allow URI references
2590 (including relative references and fragments), as referred symbol
2591 "absoluteURI" wasn't what was expected, and add some clarifications
2592 as to when use of fragments would not be appropriate. (Section 9.5)
2594 Restrict Max-Forwards header field to OPTIONS and TRACE (previously,
2595 extension methods could have used it as well). (Section 9.6)
2597 Allow Referer field value of "about:blank" as alternative to not
2598 specifying it. (Section 9.7)
2600 In the description of the Server header field, the Via field was
2601 described as a SHOULD. The requirement was and is stated correctly
2602 in the description of the Via header field in Section 8.8 of [Part1].
2603 (Section 9.9)
2605 Appendix B. Collected ABNF
2607 Allow = [ ( "," / Method ) *( OWS "," [ OWS Method ] ) ]
2609 BWS =
2611 Date = HTTP-date
2613 Expect = *( "," OWS ) expectation *( OWS "," [ OWS expectation ] )
2615 From = mailbox
2617 GMT = %x47.4D.54 ; GMT
2619 HTTP-date = rfc1123-date / obs-date
2621 Location = URI-reference
2623 Max-Forwards = 1*DIGIT
2624 Method = token
2626 OWS =
2628 RWS =
2629 Reason-Phrase = *( HTAB / SP / VCHAR / obs-text )
2630 Referer = absolute-URI / partial-URI
2631 Retry-After = HTTP-date / delta-seconds
2633 Server = product *( RWS ( product / comment ) )
2634 Status-Code = 3DIGIT
2636 URI-reference =
2637 User-Agent = product *( RWS ( product / comment ) )
2639 absolute-URI =
2640 asctime-date = day-name SP date3 SP time-of-day SP year
2642 comment =
2644 date1 = day SP month SP year
2645 date2 = day "-" month "-" 2DIGIT
2646 date3 = month SP ( 2DIGIT / ( SP DIGIT ) )
2647 day = 2DIGIT
2648 day-name = %x4D.6F.6E ; Mon
2649 / %x54.75.65 ; Tue
2650 / %x57.65.64 ; Wed
2651 / %x54.68.75 ; Thu
2652 / %x46.72.69 ; Fri
2653 / %x53.61.74 ; Sat
2654 / %x53.75.6E ; Sun
2655 day-name-l = %x4D.6F.6E.64.61.79 ; Monday
2656 / %x54.75.65.73.64.61.79 ; Tuesday
2657 / %x57.65.64.6E.65.73.64.61.79 ; Wednesday
2658 / %x54.68.75.72.73.64.61.79 ; Thursday
2659 / %x46.72.69.64.61.79 ; Friday
2660 / %x53.61.74.75.72.64.61.79 ; Saturday
2661 / %x53.75.6E.64.61.79 ; Sunday
2662 delta-seconds = 1*DIGIT
2664 expect-name = token
2665 expect-param = expect-name [ BWS "=" BWS expect-value ]
2666 expect-value = token / quoted-string
2667 expectation = expect-name [ BWS "=" BWS expect-value ] *( OWS ";" [
2668 OWS expect-param ] )
2670 hour = 2DIGIT
2671 mailbox =
2672 minute = 2DIGIT
2673 month = %x4A.61.6E ; Jan
2674 / %x46.65.62 ; Feb
2675 / %x4D.61.72 ; Mar
2676 / %x41.70.72 ; Apr
2677 / %x4D.61.79 ; May
2678 / %x4A.75.6E ; Jun
2679 / %x4A.75.6C ; Jul
2680 / %x41.75.67 ; Aug
2681 / %x53.65.70 ; Sep
2682 / %x4F.63.74 ; Oct
2683 / %x4E.6F.76 ; Nov
2684 / %x44.65.63 ; Dec
2686 obs-date = rfc850-date / asctime-date
2687 obs-text =
2689 partial-URI =
2690 product =
2692 quoted-string =
2694 rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT
2695 rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT
2697 second = 2DIGIT
2699 time-of-day = hour ":" minute ":" second
2700 token =
2702 year = 4DIGIT
2704 ABNF diagnostics:
2706 ; Allow defined but not used
2707 ; Date defined but not used
2708 ; Expect defined but not used
2709 ; From defined but not used
2710 ; Location defined but not used
2711 ; Max-Forwards defined but not used
2712 ; Reason-Phrase defined but not used
2713 ; Referer defined but not used
2714 ; Retry-After defined but not used
2715 ; Server defined but not used
2716 ; Status-Code defined but not used
2717 ; User-Agent defined but not used
2719 Appendix C. Change Log (to be removed by RFC Editor before publication)
2721 C.1. Since RFC 2616
2723 Extracted relevant partitions from [RFC2616].
2725 C.2. Since draft-ietf-httpbis-p2-semantics-00
2727 Closed issues:
2729 o : "Via is a MUST"
2730 ()
2732 o : "Fragments
2733 allowed in Location"
2734 ()
2736 o : "Safe Methods
2737 vs Redirection" ()
2739 o : "Revise
2740 description of the POST method"
2741 ()
2743 o : "Normative and
2744 Informative references"
2746 o : "RFC2606
2747 Compliance"
2749 o : "Informative
2750 references"
2752 o : "Redundant
2753 cross-references"
2755 Other changes:
2757 o Move definitions of 304 and 412 condition codes to [Part4]
2759 C.3. Since draft-ietf-httpbis-p2-semantics-01
2761 Closed issues:
2763 o : "PUT side
2764 effects"
2766 o : "Duplicate Host
2767 header requirements"
2769 Ongoing work on ABNF conversion
2770 ():
2772 o Move "Product Tokens" section (back) into Part 1, as "token" is
2773 used in the definition of the Upgrade header field.
2775 o Add explicit references to BNF syntax and rules imported from
2776 other parts of the specification.
2778 o Copy definition of delta-seconds from Part6 instead of referencing
2779 it.
2781 C.4. Since draft-ietf-httpbis-p2-semantics-02
2783 Closed issues:
2785 o : "Requiring
2786 Allow in 405 responses"
2788 o : "Status Code
2789 Registry"
2791 o : "Redirection
2792 vs. Location"
2794 o : "Cacheability
2795 of 303 response"
2797 o : "305 Use Proxy"
2799 o :
2800 "Classification for Allow header"
2802 o : "PUT - 'store
2803 under' vs 'store at'"
2805 Ongoing work on IANA Message Header Field Registration
2806 ():
2808 o Reference RFC 3984, and update header field registrations for
2809 headers defined in this document.
2811 Ongoing work on ABNF conversion
2812 ():
2814 o Replace string literals when the string really is case-sensitive
2815 (method).
2817 C.5. Since draft-ietf-httpbis-p2-semantics-03
2819 Closed issues:
2821 o : "OPTIONS
2822 request bodies"
2824 o : "Description
2825 of CONNECT should refer to RFC2817"
2827 o : "Location
2828 Content-Location reference request/response mixup"
2830 Ongoing work on Method Registry
2831 ():
2833 o Added initial proposal for registration process, plus initial
2834 content (non-HTTP/1.1 methods to be added by a separate
2835 specification).
2837 C.6. Since draft-ietf-httpbis-p2-semantics-04
2839 Closed issues:
2841 o : "Content-*"
2843 o : "RFC 2822 is
2844 updated by RFC 5322"
2846 Ongoing work on ABNF conversion
2847 ():
2849 o Use "/" instead of "|" for alternatives.
2851 o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
2852 whitespace ("OWS") and required whitespace ("RWS").
2854 o Rewrite ABNFs to spell out whitespace rules, factor out header
2855 field value format definitions.
2857 C.7. Since draft-ietf-httpbis-p2-semantics-05
2859 Closed issues:
2861 o : "Reason-Phrase
2862 BNF"
2864 Final work on ABNF conversion
2865 ():
2867 o Add appendix containing collected and expanded ABNF, reorganize
2868 ABNF introduction.
2870 C.8. Since draft-ietf-httpbis-p2-semantics-06
2872 Closed issues:
2874 o : "Clarify when
2875 Referer is sent"
2877 o : "status codes
2878 vs methods"
2880 o : "Do not
2881 require "updates" relation for specs that register status codes or
2882 method names"
2884 C.9. Since draft-ietf-httpbis-p2-semantics-07
2886 Closed issues:
2888 o : "Idempotency"
2890 o : "TRACE security
2891 considerations"
2893 o : "Clarify rules
2894 for determining what entities a response carries"
2896 o : "update note
2897 citing RFC 1945 and 2068"
2899 o : "update note
2900 about redirect limit"
2902 o : "Location
2903 header ABNF should use 'URI'"
2905 o : "fragments in
2906 Location vs status 303"
2908 o : "move IANA
2909 registrations for optional status codes"
2911 Partly resolved issues:
2913 o : "Are OPTIONS
2914 and TRACE safe?"
2916 C.10. Since draft-ietf-httpbis-p2-semantics-08
2918 Closed issues:
2920 o : "Safe Methods
2921 vs Redirection" (we missed the introduction to the 3xx status
2922 codes when fixing this previously)
2924 C.11. Since draft-ietf-httpbis-p2-semantics-09
2926 Closed issues:
2928 o : "Fragment
2929 combination / precedence during redirects"
2931 Partly resolved issues:
2933 o : "Location
2934 header payload handling"
2936 o : "Term for the
2937 requested resource's URI"
2939 C.12. Since draft-ietf-httpbis-p2-semantics-10
2941 Closed issues:
2943 o : "Clarify
2944 'Requested Variant'"
2946 o : "Clarify
2947 entity / representation / variant terminology"
2949 o : "Methods and
2950 Caching"
2952 o : "OPTIONS vs
2953 Max-Forwards"
2955 o : "Status codes
2956 and caching"
2958 o : "consider
2959 removing the 'changes from 2068' sections"
2961 C.13. Since draft-ietf-httpbis-p2-semantics-11
2963 Closed issues:
2965 o :
2966 "Considerations for new status codes"
2968 o :
2969 "Considerations for new methods"
2971 o : "User-Agent
2972 guidelines" (relating to the 'User-Agent' header field)
2974 C.14. Since draft-ietf-httpbis-p2-semantics-12
2976 Closed issues:
2978 o : "Fragment
2979 combination / precedence during redirects" (added warning about
2980 having a fragid on the redirect may cause inconvenience in some
2981 cases)
2983 o : "Content-* vs.
2984 PUT"
2986 o : "205 Bodies"
2988 o : "Understanding
2989 Content-* on non-PUT requests"
2991 o : "Content-*"
2993 o : "Header type
2994 defaulting"
2996 o : "PUT - 'store
2997 under' vs 'store at'"
2999 o : "duplicate
3000 ABNF for Reason-Phrase"
3002 o : "Note special
3003 status of Content-* prefix in header registration procedures"
3005 o : "Max-Forwards
3006 vs extension methods"
3008 o : "What is the
3009 value space of HTTP status codes?" (actually fixed in
3010 draft-ietf-httpbis-p2-semantics-11)
3012 o : "Header
3013 Classification"
3015 o : "PUT side
3016 effect: invalidation or just stale?"
3018 o : "proxies not
3019 supporting certain methods"
3021 o : "Migrate
3022 CONNECT from RFC2817 to p2"
3024 o : "Migrate
3025 Upgrade details from RFC2817"
3027 o : "clarify PUT
3028 semantics'"
3030 o : "duplicate
3031 ABNF for 'Method'"
3033 o : "untangle
3034 ABNFs for header fields"
3036 C.15. Since draft-ietf-httpbis-p2-semantics-13
3038 Closed issues:
3040 o : "untangle
3041 ABNFs for header fields"
3043 o : "message-body
3044 in CONNECT request"
3046 C.16. Since draft-ietf-httpbis-p2-semantics-14
3048 Closed issues:
3050 o : "Clarify
3051 status code for rate limiting"
3053 o : "clarify 403
3054 forbidden"
3056 o : "Clarify 203
3057 Non-Authoritative Information"
3059 o : "update
3060 default reason phrase for 413"
3062 C.17. Since draft-ietf-httpbis-p2-semantics-15
3064 Closed issues:
3066 o : "Strength of
3067 requirements on Accept re: 406"
3069 o : "400 response
3070 isn't generic"
3072 C.18. Since draft-ietf-httpbis-p2-semantics-16
3074 Closed issues:
3076 o : "Redirects and
3077 non-GET methods"
3079 o : "Document
3080 HTTP's error-handling philosophy"
3082 o :
3083 "Considerations for new headers"
3085 o : "clarify 303
3086 redirect on HEAD"
3088 C.19. Since draft-ietf-httpbis-p2-semantics-17
3090 Closed issues:
3092 o : "Location
3093 header payload handling"
3095 o : "Clarify
3096 status code for rate limiting" (change backed out because a new
3097 status code is being defined for this purpose)
3099 o : "should there
3100 be a permanent variant of 307"
3102 o : "When are
3103 Location's semantics triggered?"
3105 o : "'expect'
3106 grammar missing OWS"
3108 o : "header field
3109 considerations: quoted-string vs use of double quotes"
3111 Index
3113 1
3114 100 Continue (status code) 26
3115 100-continue (expect value) 44
3116 101 Switching Protocols (status code) 26
3118 2
3119 200 OK (status code) 27
3120 201 Created (status code) 27
3121 202 Accepted (status code) 28
3122 203 Non-Authoritative Information (status code) 28
3123 204 No Content (status code) 28
3124 205 Reset Content (status code) 29
3125 206 Partial Content (status code) 29
3127 3
3128 300 Multiple Choices (status code) 30
3129 301 Moved Permanently (status code) 31
3130 302 Found (status code) 32
3131 303 See Other (status code) 32
3132 304 Not Modified (status code) 33
3133 305 Use Proxy (status code) 33
3134 306 (Unused) (status code) 33
3135 307 Temporary Redirect (status code) 33
3137 4
3138 400 Bad Request (status code) 34
3139 401 Unauthorized (status code) 34
3140 402 Payment Required (status code) 34
3141 403 Forbidden (status code) 34
3142 404 Not Found (status code) 35
3143 405 Method Not Allowed (status code) 35
3144 406 Not Acceptable (status code) 35
3145 407 Proxy Authentication Required (status code) 36
3146 408 Request Timeout (status code) 36
3147 409 Conflict (status code) 36
3148 410 Gone (status code) 36
3149 411 Length Required (status code) 37
3150 412 Precondition Failed (status code) 37
3151 413 Request Representation Too Large (status code) 37
3152 414 URI Too Long (status code) 37
3153 415 Unsupported Media Type (status code) 37
3154 416 Requested Range Not Satisfiable (status code) 38
3155 417 Expectation Failed (status code) 38
3156 426 Upgrade Required (status code) 38
3158 5
3159 500 Internal Server Error (status code) 38
3160 501 Not Implemented (status code) 39
3161 502 Bad Gateway (status code) 39
3162 503 Service Unavailable (status code) 39
3163 504 Gateway Timeout (status code) 39
3164 505 HTTP Version Not Supported (status code) 39
3166 A
3167 Allow header field 42
3169 C
3170 CONNECT method 24
3172 D
3173 Date header field 43
3174 DELETE method 23
3176 E
3177 Expect header field 44
3178 Expect Values
3179 100-continue 44
3181 F
3182 From header field 44
3184 G
3185 GET method 19
3186 Grammar
3187 Allow 42
3188 asctime-date 42
3189 Date 43
3190 date1 41
3191 day 41
3192 day-name 41
3193 day-name-l 41
3194 delta-seconds 47
3195 Expect 44
3196 expect-name 44
3197 expect-param 44
3198 expect-value 44
3199 expectation 44
3200 extension-code 13
3201 From 45
3202 GMT 41
3203 hour 41
3204 HTTP-date 40
3205 Location 45
3206 Max-Forwards 46
3207 Method 7
3208 minute 41
3209 month 41
3210 obs-date 41
3211 Reason-Phrase 13
3212 Referer 47
3213 Retry-After 47
3214 rfc850-date 42
3215 rfc1123-date 41
3216 second 41
3217 Server 48
3218 Status-Code 13
3219 time-of-day 41
3220 User-Agent 49
3221 year 41
3223 H
3224 HEAD method 19
3225 Header Fields
3226 Allow 42
3227 Date 43
3228 Expect 44
3229 From 44
3230 Location 45
3231 Max-Forwards 46
3232 Referer 47
3233 Retry-After 47
3234 Server 48
3235 User-Agent 48
3237 I
3238 Idempotent Methods 17
3240 L
3241 Location header field 45
3243 M
3244 Max-Forwards header field 46
3245 Methods
3246 CONNECT 24
3247 DELETE 23
3248 GET 19
3249 HEAD 19
3250 OPTIONS 18
3251 POST 20
3252 PUT 21
3253 TRACE 23
3255 O
3256 OPTIONS method 18
3258 P
3259 POST method 20
3260 PUT method 21
3262 R
3263 Referer header field 47
3264 Retry-After header field 47
3266 S
3267 Safe Methods 17
3268 Server header field 48
3269 Status Codes
3270 100 Continue 26
3271 101 Switching Protocols 26
3272 200 OK 27
3273 201 Created 27
3274 202 Accepted 28
3275 203 Non-Authoritative Information 28
3276 204 No Content 28
3277 205 Reset Content 29
3278 206 Partial Content 29
3279 300 Multiple Choices 30
3280 301 Moved Permanently 31
3281 302 Found 32
3282 303 See Other 32
3283 304 Not Modified 33
3284 305 Use Proxy 33
3285 306 (Unused) 33
3286 307 Temporary Redirect 33
3287 400 Bad Request 34
3288 401 Unauthorized 34
3289 402 Payment Required 34
3290 403 Forbidden 34
3291 404 Not Found 35
3292 405 Method Not Allowed 35
3293 406 Not Acceptable 35
3294 407 Proxy Authentication Required 36
3295 408 Request Timeout 36
3296 409 Conflict 36
3297 410 Gone 36
3298 411 Length Required 37
3299 412 Precondition Failed 37
3300 413 Request Representation Too Large 37
3301 414 URI Too Long 37
3302 415 Unsupported Media Type 37
3303 416 Requested Range Not Satisfiable 38
3304 417 Expectation Failed 38
3305 426 Upgrade Required 38
3306 500 Internal Server Error 38
3307 501 Not Implemented 39
3308 502 Bad Gateway 39
3309 503 Service Unavailable 39
3310 504 Gateway Timeout 39
3311 505 HTTP Version Not Supported 39
3313 T
3314 TRACE method 23
3316 U
3317 User-Agent header field 48
3319 Authors' Addresses
3321 Roy T. Fielding (editor)
3322 Adobe Systems Incorporated
3323 345 Park Ave
3324 San Jose, CA 95110
3325 USA
3327 EMail: fielding@gbiv.com
3328 URI: http://roy.gbiv.com/
3329 Jim Gettys
3330 Alcatel-Lucent Bell Labs
3331 21 Oak Knoll Road
3332 Carlisle, MA 01741
3333 USA
3335 EMail: jg@freedesktop.org
3336 URI: http://gettys.wordpress.com/
3338 Jeffrey C. Mogul
3339 Hewlett-Packard Company
3340 HP Labs, Large Scale Systems Group
3341 1501 Page Mill Road, MS 1177
3342 Palo Alto, CA 94304
3343 USA
3345 EMail: JeffMogul@acm.org
3347 Henrik Frystyk Nielsen
3348 Microsoft Corporation
3349 1 Microsoft Way
3350 Redmond, WA 98052
3351 USA
3353 EMail: henrikn@microsoft.com
3355 Larry Masinter
3356 Adobe Systems Incorporated
3357 345 Park Ave
3358 San Jose, CA 95110
3359 USA
3361 EMail: LMM@acm.org
3362 URI: http://larry.masinter.net/
3364 Paul J. Leach
3365 Microsoft Corporation
3366 1 Microsoft Way
3367 Redmond, WA 98052
3369 EMail: paulle@microsoft.com
3370 Tim Berners-Lee
3371 World Wide Web Consortium
3372 MIT Computer Science and Artificial Intelligence Laboratory
3373 The Stata Center, Building 32
3374 32 Vassar Street
3375 Cambridge, MA 02139
3376 USA
3378 EMail: timbl@w3.org
3379 URI: http://www.w3.org/People/Berners-Lee/
3381 Yves Lafon (editor)
3382 World Wide Web Consortium
3383 W3C / ERCIM
3384 2004, rte des Lucioles
3385 Sophia-Antipolis, AM 06902
3386 France
3388 EMail: ylafon@w3.org
3389 URI: http://www.raubacapeu.net/people/yves/
3391 Julian F. Reschke (editor)
3392 greenbytes GmbH
3393 Hafenweg 16
3394 Muenster, NW 48155
3395 Germany
3397 Phone: +49 251 2807760
3398 Fax: +49 251 2807761
3399 EMail: julian.reschke@greenbytes.de
3400 URI: http://greenbytes.de/tech/webdav/