idnits 2.17.1
draft-ietf-httpbis-p2-semantics-17.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 (October 31, 2011) is 4560 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-17
== Outdated reference: A later version (-20) exists of
draft-ietf-httpbis-p3-payload-17
== Outdated reference: A later version (-26) exists of
draft-ietf-httpbis-p4-conditional-17
== Outdated reference: A later version (-26) exists of
draft-ietf-httpbis-p5-range-17
== Outdated reference: A later version (-26) exists of
draft-ietf-httpbis-p6-cache-17
== Outdated reference: A later version (-26) exists of
draft-ietf-httpbis-p7-auth-17
-- 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: May 3, 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 October 31, 2011
22 HTTP/1.1, part 2: Message Semantics
23 draft-ietf-httpbis-p2-semantics-17
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.18.
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 May 3, 2012.
68 Copyright Notice
70 Copyright (c) 2011 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 . . . . . . . . . . . . . . . . 12
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 . . . . . . . . . . 35
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 . . . . . . . . . . . . . . . . . . . 49
193 10.3. Header Field Registration . . . . . . . . . . . . . . . . 51
194 11. Security Considerations . . . . . . . . . . . . . . . . . . . 51
195 11.1. Transfer of Sensitive Information . . . . . . . . . . . . 51
196 11.2. Encoding Sensitive Information in URIs . . . . . . . . . . 52
197 11.3. Location Headers and Spoofing . . . . . . . . . . . . . . 53
198 11.4. Security Considerations for CONNECT . . . . . . . . . . . 53
199 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53
200 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53
201 13.1. Normative References . . . . . . . . . . . . . . . . . . . 53
202 13.2. Informative References . . . . . . . . . . . . . . . . . . 54
203 Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 55
204 Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 56
205 Appendix C. Change Log (to be removed by RFC Editor before
206 publication) . . . . . . . . . . . . . . . . . . . . 59
207 C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 59
208 C.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 59
209 C.3. Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . . 59
210 C.4. Since draft-ietf-httpbis-p2-semantics-02 . . . . . . . . . 60
211 C.5. Since draft-ietf-httpbis-p2-semantics-03 . . . . . . . . . 61
212 C.6. Since draft-ietf-httpbis-p2-semantics-04 . . . . . . . . . 61
213 C.7. Since draft-ietf-httpbis-p2-semantics-05 . . . . . . . . . 61
214 C.8. Since draft-ietf-httpbis-p2-semantics-06 . . . . . . . . . 62
215 C.9. Since draft-ietf-httpbis-p2-semantics-07 . . . . . . . . . 62
216 C.10. Since draft-ietf-httpbis-p2-semantics-08 . . . . . . . . . 63
217 C.11. Since draft-ietf-httpbis-p2-semantics-09 . . . . . . . . . 63
218 C.12. Since draft-ietf-httpbis-p2-semantics-10 . . . . . . . . . 63
219 C.13. Since draft-ietf-httpbis-p2-semantics-11 . . . . . . . . . 64
220 C.14. Since draft-ietf-httpbis-p2-semantics-12 . . . . . . . . . 64
221 C.15. Since draft-ietf-httpbis-p2-semantics-13 . . . . . . . . . 65
222 C.16. Since draft-ietf-httpbis-p2-semantics-14 . . . . . . . . . 66
223 C.17. Since draft-ietf-httpbis-p2-semantics-15 . . . . . . . . . 66
224 C.18. Since draft-ietf-httpbis-p2-semantics-16 . . . . . . . . . 66
225 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
227 1. Introduction
229 This document defines HTTP/1.1 request and response semantics. Each
230 HTTP message, as defined in [Part1], is in the form of either a
231 request or a response. An HTTP server listens on a connection for
232 HTTP requests and responds to each request, in the order received on
233 that connection, with one or more HTTP response messages. This
234 document defines the commonly agreed upon semantics of the HTTP
235 uniform interface, the intentions defined by each request method, and
236 the various response messages that might be expected as a result of
237 applying that method to the target resource.
239 This document is currently disorganized in order to minimize the
240 changes between drafts and enable reviewers to see the smaller errata
241 changes. A future draft will reorganize the sections to better
242 reflect the content. In particular, the sections will be ordered
243 according to the typical processing of an HTTP request message (after
244 message parsing): resource mapping, methods, request modifying header
245 fields, response status, status modifying header fields, and resource
246 metadata. The current mess reflects how widely dispersed these
247 topics and associated requirements had become in [RFC2616].
249 1.1. Conformance and Error Handling
251 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
252 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
253 document are to be interpreted as described in [RFC2119].
255 This document defines conformance criteria for several roles in HTTP
256 communication, including Senders, Recipients, Clients, Servers, User-
257 Agents, Origin Servers, Intermediaries, Proxies and Gateways. See
258 Section 2 of [Part1] for definitions of these terms.
260 An implementation is considered conformant if it complies with all of
261 the requirements associated with its role(s). Note that SHOULD-level
262 requirements are relevant here, unless one of the documented
263 exceptions is applicable.
265 This document also uses ABNF to define valid protocol elements
266 (Section 1.2). In addition to the prose requirements placed upon
267 them, Senders MUST NOT generate protocol elements that are invalid.
269 Unless noted otherwise, Recipients MAY take steps to recover a usable
270 protocol element from an invalid construct. However, HTTP does not
271 define specific error handling mechanisms, except in cases where it
272 has direct impact on security. This is because different uses of the
273 protocol require different error handling strategies; for example, a
274 Web browser may wish to transparently recover from a response where
275 the Location header field doesn't parse according to the ABNF,
276 whereby in a systems control protocol using HTTP, this type of error
277 recovery could lead to dangerous consequences.
279 1.2. Syntax Notation
281 This specification uses the ABNF syntax defined in Section 1.2 of
282 [Part1] (which extends the syntax defined in [RFC5234] with a list
283 rule). Appendix B shows the collected ABNF, with the list rule
284 expanded.
286 The following core rules are included by reference, as defined in
287 [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
288 (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
289 HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line
290 feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any
291 visible US-ASCII character).
293 1.2.1. Core Rules
295 The core rules below are defined in [Part1]:
297 OWS =
298 RWS =
299 obs-text =
300 quoted-string =
301 token =
303 1.2.2. ABNF Rules defined in other Parts of the Specification
305 The ABNF rules below are defined in other parts:
307 absolute-URI =
308 comment =
309 partial-URI =
310 product =
311 URI-reference =
313 2. Method
315 The Method token indicates the request method to be performed on the
316 target resource (Section 4.3 of [Part1]). The method is case-
317 sensitive.
319 Method = token
321 The list of methods allowed by a resource can be specified in an
322 Allow header field (Section 9.1). The status code of the response
323 always notifies the client whether a method is currently allowed on a
324 resource, since the set of allowed methods can change dynamically.
325 An origin server SHOULD respond with the status code 405 (Method Not
326 Allowed) if the method is known by the origin server but not allowed
327 for the resource, and 501 (Not Implemented) if the method is
328 unrecognized or not implemented by the origin server. The methods
329 GET and HEAD MUST be supported by all general-purpose servers. All
330 other methods are OPTIONAL; however, if the above methods are
331 implemented, they MUST be implemented with the same semantics as
332 those specified in Section 6.
334 2.1. Overview of Methods
336 The methods listed below are defined in Section 6.
338 +-------------+---------------+
339 | Method Name | Defined in... |
340 +-------------+---------------+
341 | OPTIONS | Section 6.2 |
342 | GET | Section 6.3 |
343 | HEAD | Section 6.4 |
344 | POST | Section 6.5 |
345 | PUT | Section 6.6 |
346 | DELETE | Section 6.7 |
347 | TRACE | Section 6.8 |
348 | CONNECT | Section 6.9 |
349 +-------------+---------------+
351 Note that this list is not exhaustive -- it does not include request
352 methods defined in other specifications.
354 2.2. Method Registry
356 The HTTP Method Registry defines the name space for the Method token
357 in the Request line of an HTTP request.
359 Registrations MUST include the following fields:
361 o Method Name (see Section 2)
363 o Safe ("yes" or "no", see Section 6.1.1)
365 o Pointer to specification text
367 Values to be added to this name space are subject to IETF review
368 ([RFC5226], Section 4.1).
370 The registry itself is maintained at
371 .
373 2.2.1. Considerations for New Methods
375 When it is necessary to express new semantics for a HTTP request that
376 aren't specific to a single application or media type, and currently
377 defined methods are inadequate, it may be appropriate to register a
378 new method.
380 HTTP methods are generic; that is, they are potentially applicable to
381 any resource, not just one particular media type, "type" of resource,
382 or application. As such, it is preferred that new HTTP methods be
383 registered in a document that isn't specific to a single application,
384 so that this is clear.
386 Due to the parsing rules defined in Section 3.3 of [Part1],
387 definitions of HTTP methods cannot prohibit the presence of a
388 message-body on either the request or the response message (with
389 responses to HEAD requests being the single exception). Definitions
390 of new methods cannot change this rule, but they can specify that
391 only zero-length bodies (as opposed to absent bodies) are allowed.
393 New method definitions need to indicate whether they are safe
394 (Section 6.1.1), what semantics (if any) the request body has, and
395 whether they are idempotent (Section 6.1.2). They also need to state
396 whether they can be cached ([Part6]); in particular what conditions a
397 cache may store the response, and under what conditions such a stored
398 response may be used to satisfy a subsequent request.
400 3. Header Fields
402 Header fields are key value pairs that can be used to communicate
403 data about the message, its payload, the target resource, or about
404 the connection itself (i.e., control data). See Section 3.2 of
405 [Part1] for a general definition of their syntax.
407 3.1. Considerations for Creating Header Fields
409 New header fields are registered using the procedures described in
410 [RFC3864].
412 The requirements for header field names are defined in Section 4.1 of
413 [RFC3864]. Authors of specifications defining new fields are advised
414 to keep the name as short as practical, and not to prefix them with
415 "X-" if they are to be registered (either immediately or in the
416 future).
418 New header field values typically have their syntax defined using
419 ABNF ([RFC5234]), using the extensions defined in Section 1.2.1 of
420 [Part1] as necessary, and are usually constrained to the range of
421 ASCII characters. Header fields needing a greater range of
422 characters can use an encoding such as the one defined in [RFC5987].
424 Because commas (",") are used as a generic delimiter between field-
425 values, they need to be treated with care if they are allowed in the
426 field-value's payload. Typically, components that might contain a
427 comma are protected with double-quotes using the quoted-string ABNF
428 production (Section 3.2.3 of [Part1]).
430 For example, a textual date and a URI (either of which might contain
431 a comma) could be safely carried in field-values like these:
433 Example-URI-Field: "http://example.com/a.html,foo",
434 "http://without-a-comma.example.com/"
435 Example-Date-Field: "Sat, 04 May 1996", "Wed, 14 Sep 2005"
437 Many header fields use a format including (case-insensitively) named
438 parameters (for instance, Content-Type, defined in Section 6.8 of
439 [Part3]). Allowing both unquoted (token) and quoted (quoted-string)
440 syntax for the parameter value enables recipients to use existing
441 parser components. When allowing both forms, the meaning of a
442 parameter value ought to be independent of the syntax used for it
443 (for an example, see the notes on parameter handling for media types
444 in Section 2.3 of [Part3]).
446 Authors of specifications defining new header fields are advised to
447 consider documenting:
449 o Whether the field is a single value, or whether it can be a list
450 (delimited by commas; see Section 3.2 of [Part1]).
452 If it does not use the list syntax, document how to treat messages
453 where the header field occurs multiple times (a sensible default
454 would be to ignore the header field, but this might not always be
455 the right choice).
457 Note that intermediaries and software libraries might combine
458 multiple header field instances into a single one, despite the
459 header field not allowing this. A robust format enables
460 recipients to discover these situations (good example: "Content-
461 Type", as the comma can only appear inside quoted strings; bad
462 example: "Location", as a comma can occur inside a URI).
464 o Under what conditions the header field can be used; e.g., only in
465 responses or requests, in all messages, only on responses to a
466 particular request method.
468 o Whether it is appropriate to list the field-name in the Connection
469 header (i.e., if the header is to be hop-by-hop, see Section 8.1
470 of [Part1]).
472 o Under what conditions intermediaries are allowed to modify the
473 header field's value, insert or delete it.
475 o How the header might interact with caching (see [Part6]).
477 o Whether the header field is useful or allowable in trailers (see
478 Section 5.1.1 of [Part1]).
480 o Whether the header field should be preserved across redirects.
482 3.2. Request Header Fields
484 The request header fields allow the client to pass additional
485 information about the request, and about the client itself, to the
486 server. These fields act as request modifiers, with semantics
487 equivalent to the parameters on a programming language method
488 invocation.
490 +---------------------+------------------------+
491 | Header Field Name | Defined in... |
492 +---------------------+------------------------+
493 | Accept | Section 6.1 of [Part3] |
494 | Accept-Charset | Section 6.2 of [Part3] |
495 | Accept-Encoding | Section 6.3 of [Part3] |
496 | Accept-Language | Section 6.4 of [Part3] |
497 | Authorization | Section 4.1 of [Part7] |
498 | Expect | Section 9.3 |
499 | From | Section 9.4 |
500 | Host | Section 8.3 of [Part1] |
501 | If-Match | Section 3.1 of [Part4] |
502 | If-Modified-Since | Section 3.3 of [Part4] |
503 | If-None-Match | Section 3.2 of [Part4] |
504 | If-Range | Section 5.3 of [Part5] |
505 | If-Unmodified-Since | Section 3.4 of [Part4] |
506 | Max-Forwards | Section 9.6 |
507 | Proxy-Authorization | Section 4.3 of [Part7] |
508 | Range | Section 5.4 of [Part5] |
509 | Referer | Section 9.7 |
510 | TE | Section 8.4 of [Part1] |
511 | User-Agent | Section 9.10 |
512 +---------------------+------------------------+
514 3.3. Response Header Fields
516 The response header fields allow the server to pass additional
517 information about the response which cannot be placed in the Status-
518 Line. These header fields give information about the server and
519 about further access to the target resource (Section 4.3 of [Part1]).
521 +--------------------+------------------------+
522 | Header Field Name | Defined in... |
523 +--------------------+------------------------+
524 | Accept-Ranges | Section 5.1 of [Part5] |
525 | Age | Section 3.1 of [Part6] |
526 | Allow | Section 9.1 |
527 | Date | Section 9.2 |
528 | ETag | Section 2.3 of [Part4] |
529 | Location | Section 9.5 |
530 | Proxy-Authenticate | Section 4.2 of [Part7] |
531 | Retry-After | Section 9.8 |
532 | Server | Section 9.9 |
533 | Vary | Section 3.5 of [Part6] |
534 | WWW-Authenticate | Section 4.4 of [Part7] |
535 +--------------------+------------------------+
537 4. Status Code and Reason Phrase
539 The Status-Code element is a 3-digit integer result code of the
540 attempt to understand and satisfy the request.
542 The Reason-Phrase is intended to give a short textual description of
543 the Status-Code and is intended for a human user. The client does
544 not need to examine or display the Reason-Phrase.
546 Status-Code = 3DIGIT
547 Reason-Phrase = *( HTAB / SP / VCHAR / obs-text )
549 HTTP status codes are extensible. HTTP applications are not required
550 to understand the meaning of all registered status codes, though such
551 understanding is obviously desirable. However, applications MUST
552 understand the class of any status code, as indicated by the first
553 digit, and treat any unrecognized response as being equivalent to the
554 x00 status code of that class, with the exception that an
555 unrecognized response MUST NOT be cached. For example, if an
556 unrecognized status code of 431 is received by the client, it can
557 safely assume that there was something wrong with its request and
558 treat the response as if it had received a 400 status code. In such
559 cases, user agents SHOULD present to the user the representation
560 enclosed with the response, since that representation is likely to
561 include human-readable information which will explain the unusual
562 status.
564 4.1. Overview of Status Codes
566 The status codes listed below are defined in Section 7 of this
567 specification, Section 4 of [Part4], Section 3 of [Part5], and
568 Section 3 of [Part7]. The reason phrases listed here are only
569 recommendations -- they can be replaced by local equivalents without
570 affecting the protocol.
572 +-------------+------------------------------+----------------------+
573 | Status-Code | Reason-Phrase | Defined in... |
574 +-------------+------------------------------+----------------------+
575 | 100 | Continue | Section 7.1.1 |
576 | 101 | Switching Protocols | Section 7.1.2 |
577 | 200 | OK | Section 7.2.1 |
578 | 201 | Created | Section 7.2.2 |
579 | 202 | Accepted | Section 7.2.3 |
580 | 203 | Non-Authoritative | Section 7.2.4 |
581 | | Information | |
582 | 204 | No Content | Section 7.2.5 |
583 | 205 | Reset Content | Section 7.2.6 |
584 | 206 | Partial Content | Section 3.1 of |
585 | | | [Part5] |
586 | 300 | Multiple Choices | Section 7.3.1 |
587 | 301 | Moved Permanently | Section 7.3.2 |
588 | 302 | Found | Section 7.3.3 |
589 | 303 | See Other | Section 7.3.4 |
590 | 304 | Not Modified | Section 4.1 of |
591 | | | [Part4] |
592 | 305 | Use Proxy | Section 7.3.6 |
593 | 307 | Temporary Redirect | Section 7.3.8 |
594 | 400 | Bad Request | Section 7.4.1 |
595 | 401 | Unauthorized | Section 3.1 of |
596 | | | [Part7] |
597 | 402 | Payment Required | Section 7.4.3 |
598 | 403 | Forbidden | Section 7.4.4 |
599 | 404 | Not Found | Section 7.4.5 |
600 | 405 | Method Not Allowed | Section 7.4.6 |
601 | 406 | Not Acceptable | Section 7.4.7 |
602 | 407 | Proxy Authentication | Section 3.2 of |
603 | | Required | [Part7] |
604 | 408 | Request Time-out | Section 7.4.9 |
605 | 409 | Conflict | Section 7.4.10 |
606 | 410 | Gone | Section 7.4.11 |
607 | 411 | Length Required | Section 7.4.12 |
608 | 412 | Precondition Failed | Section 4.2 of |
609 | | | [Part4] |
610 | 413 | Request Representation Too | Section 7.4.14 |
611 | | Large | |
612 | 414 | URI Too Long | Section 7.4.15 |
613 | 415 | Unsupported Media Type | Section 7.4.16 |
614 | 416 | Requested range not | Section 3.2 of |
615 | | satisfiable | [Part5] |
616 | 417 | Expectation Failed | Section 7.4.18 |
617 | 426 | Upgrade Required | Section 7.4.19 |
618 | 500 | Internal Server Error | Section 7.5.1 |
619 | 501 | Not Implemented | Section 7.5.2 |
620 | 502 | Bad Gateway | Section 7.5.3 |
621 | 503 | Service Unavailable | Section 7.5.4 |
622 | 504 | Gateway Time-out | Section 7.5.5 |
623 | 505 | HTTP Version not supported | Section 7.5.6 |
624 +-------------+------------------------------+----------------------+
626 Note that this list is not exhaustive -- it does not include
627 extension status codes defined in other specifications.
629 4.2. Status Code Registry
631 The HTTP Status Code Registry defines the name space for the Status-
632 Code token in the Status-Line of an HTTP response.
634 Values to be added to this name space are subject to IETF review
635 ([RFC5226], Section 4.1).
637 The registry itself is maintained at
638 .
640 4.2.1. Considerations for New Status Codes
642 When it is necessary to express new semantics for a HTTP response
643 that aren't specific to a single application or media type, and
644 currently defined status codes are inadequate, a new status code can
645 be registered.
647 HTTP status codes are generic; that is, they are potentially
648 applicable to any resource, not just one particular media type,
649 "type" of resource, or application. As such, it is preferred that
650 new HTTP status codes be registered in a document that isn't specific
651 to a single application, so that this is clear.
653 Definitions of new HTTP status codes typically explain the request
654 conditions that produce a response containing the status code (e.g.,
655 combinations of request headers and/or method(s)), along with any
656 interactions with response headers (e.g., those that are required,
657 those that modify the semantics of the response).
659 New HTTP status codes are required to fall under one of the
660 categories defined in Section 7. To allow existing parsers to
661 properly handle them, new status codes cannot disallow a response
662 body, although they can mandate a zero-length response body. They
663 can require the presence of one or more particular HTTP response
664 header(s).
666 Likewise, their definitions can specify that caches are allowed to
667 use heuristics to determine their freshness (see [Part6]; by default,
668 it is not allowed), and can define how to determine the resource
669 which they carry a representation for (see Section 5.1; by default,
670 it is anonymous).
672 5. Representation
674 Request and Response messages MAY transfer a representation if not
675 otherwise restricted by the request method or response status code.
676 A representation consists of metadata (representation header fields)
677 and data (representation body). When a complete or partial
678 representation is enclosed in an HTTP message, it is referred to as
679 the payload of the message. HTTP representations are defined in
680 [Part3].
682 A representation body is only present in a message when a message-
683 body is present, as described in Section 3.3 of [Part1]. The
684 representation body is obtained from the message-body by decoding any
685 Transfer-Encoding that might have been applied to ensure safe and
686 proper transfer of the message.
688 5.1. Identifying the Resource Associated with a Representation
690 It is sometimes necessary to determine an identifier for the resource
691 associated with a representation.
693 An HTTP request representation, when present, is always associated
694 with an anonymous (i.e., unidentified) resource.
696 In the common case, an HTTP response is a representation of the
697 target resource (see Section 4.3 of [Part1]). However, this is not
698 always the case. To determine the URI of the resource a response is
699 associated with, the following rules are used (with the first
700 applicable one being selected):
702 1. If the response status code is 200 or 203 and the request method
703 was GET, the response payload is a representation of the target
704 resource.
706 2. If the response status code is 204, 206, or 304 and the request
707 method was GET or HEAD, the response payload is a partial
708 representation of the target resource.
710 3. If the response has a Content-Location header field, and that URI
711 is the same as the effective request URI, the response payload is
712 a representation of the target resource.
714 4. If the response has a Content-Location header field, and that URI
715 is not the same as the effective request URI, then the response
716 asserts that its payload is a representation of the resource
717 identified by the Content-Location URI. However, such an
718 assertion cannot be trusted unless it can be verified by other
719 means (not defined by HTTP).
721 5. Otherwise, the response is a representation of an anonymous
722 (i.e., unidentified) resource.
724 [[TODO-req-uri: The comparison function is going to have to be
725 defined somewhere, because we already need to compare URIs for things
726 like cache invalidation.]]
728 6. Method Definitions
730 The set of common request methods for HTTP/1.1 is defined below.
731 Although this set can be expanded, additional methods cannot be
732 assumed to share the same semantics for separately extended clients
733 and servers.
735 6.1. Safe and Idempotent Methods
737 6.1.1. Safe Methods
739 Implementors need to be aware that the software represents the user
740 in their interactions over the Internet, and need to allow the user
741 to be aware of any actions they take which might have an unexpected
742 significance to themselves or others.
744 In particular, the convention has been established that the GET,
745 HEAD, OPTIONS, and TRACE request methods SHOULD NOT have the
746 significance of taking an action other than retrieval. These request
747 methods ought to be considered "safe". This allows user agents to
748 represent other methods, such as POST, PUT and DELETE, in a special
749 way, so that the user is made aware of the fact that a possibly
750 unsafe action is being requested.
752 Naturally, it is not possible to ensure that the server does not
753 generate side-effects as a result of performing a GET request; in
754 fact, some dynamic resources consider that a feature. The important
755 distinction here is that the user did not request the side-effects,
756 so therefore cannot be held accountable for them.
758 6.1.2. Idempotent Methods
760 Request methods can also have the property of "idempotence" in that,
761 aside from error or expiration issues, the intended effect of
762 multiple identical requests is the same as for a single request.
763 PUT, DELETE, and all safe request methods are idempotent. It is
764 important to note that idempotence refers only to changes requested
765 by the client: a server is free to change its state due to multiple
766 requests for the purpose of tracking those requests, versioning of
767 results, etc.
769 6.2. OPTIONS
771 The OPTIONS method requests information about the communication
772 options available on the request/response chain identified by the
773 effective request URI. This method allows a client to determine the
774 options and/or requirements associated with a resource, or the
775 capabilities of a server, without implying a resource action or
776 initiating a resource retrieval.
778 Responses to the OPTIONS method are not cacheable.
780 If the OPTIONS request includes a message-body (as indicated by the
781 presence of Content-Length or Transfer-Encoding), then the media type
782 MUST be indicated by a Content-Type field. Although this
783 specification does not define any use for such a body, future
784 extensions to HTTP might use the OPTIONS body to make more detailed
785 queries on the server.
787 If the request-target is an asterisk ("*"), the OPTIONS request is
788 intended to apply to the server in general rather than to a specific
789 resource. Since a server's communication options typically depend on
790 the resource, the "*" request is only useful as a "ping" or "no-op"
791 type of method; it does nothing beyond allowing the client to test
792 the capabilities of the server. For example, this can be used to
793 test a proxy for HTTP/1.1 compliance (or lack thereof).
795 If the request-target is not an asterisk, the OPTIONS request applies
796 only to the options that are available when communicating with that
797 resource.
799 A 200 response SHOULD include any header fields that indicate
800 optional features implemented by the server and applicable to that
801 resource (e.g., Allow), possibly including extensions not defined by
802 this specification. The response body, if any, SHOULD also include
803 information about the communication options. The format for such a
804 body is not defined by this specification, but might be defined by
805 future extensions to HTTP. Content negotiation MAY be used to select
806 the appropriate response format. If no response body is included,
807 the response MUST include a Content-Length field with a field-value
808 of "0".
810 The Max-Forwards header field MAY be used to target a specific proxy
811 in the request chain (see Section 9.6). If no Max-Forwards field is
812 present in the request, then the forwarded request MUST NOT include a
813 Max-Forwards field.
815 6.3. GET
817 The GET method requests transfer of a current representation of the
818 target resource.
820 If the target resource is a data-producing process, it is the
821 produced data which shall be returned as the representation in the
822 response and not the source text of the process, unless that text
823 happens to be the output of the process.
825 The semantics of the GET method change to a "conditional GET" if the
826 request message includes an If-Modified-Since, If-Unmodified-Since,
827 If-Match, If-None-Match, or If-Range header field. A conditional GET
828 requests that the representation be transferred only under the
829 circumstances described by the conditional header field(s). The
830 conditional GET request is intended to reduce unnecessary network
831 usage by allowing cached representations to be refreshed without
832 requiring multiple requests or transferring data already held by the
833 client.
835 The semantics of the GET method change to a "partial GET" if the
836 request message includes a Range header field. A partial GET
837 requests that only part of the representation be transferred, as
838 described in Section 5.4 of [Part5]. The partial GET request is
839 intended to reduce unnecessary network usage by allowing partially-
840 retrieved representations to be completed without transferring data
841 already held by the client.
843 Bodies on GET requests have no defined semantics. Note that sending
844 a body on a GET request might cause some existing implementations to
845 reject the request.
847 The response to a GET request is cacheable and MAY be used to satisfy
848 subsequent GET and HEAD requests (see [Part6]).
850 See Section 11.2 for security considerations when used for forms.
852 6.4. HEAD
854 The HEAD method is identical to GET except that the server MUST NOT
855 return a message-body in the response. The metadata contained in the
856 HTTP header fields in response to a HEAD request SHOULD be identical
857 to the information sent in response to a GET request. This method
858 can be used for obtaining metadata about the representation implied
859 by the request without transferring the representation body. This
860 method is often used for testing hypertext links for validity,
861 accessibility, and recent modification.
863 The response to a HEAD request is cacheable and MAY be used to
864 satisfy a subsequent HEAD request; see [Part6]. It also MAY be used
865 to update a previously cached representation from that resource; if
866 the new field values indicate that the cached representation differs
867 from the current representation (as would be indicated by a change in
868 Content-Length, ETag or Last-Modified), then the cache MUST treat the
869 cache entry as stale.
871 Bodies on HEAD requests have no defined semantics. Note that sending
872 a body on a HEAD request might cause some existing implementations to
873 reject the request.
875 6.5. POST
877 The POST method requests that the origin server accept the
878 representation enclosed in the request as data to be processed by the
879 target resource. POST is designed to allow a uniform method to cover
880 the following functions:
882 o Annotation of existing resources;
884 o Posting a message to a bulletin board, newsgroup, mailing list, or
885 similar group of articles;
887 o Providing a block of data, such as the result of submitting a
888 form, to a data-handling process;
890 o Extending a database through an append operation.
892 The actual function performed by the POST method is determined by the
893 server and is usually dependent on the effective request URI.
895 The action performed by the POST method might not result in a
896 resource that can be identified by a URI. In this case, either 200
897 (OK) or 204 (No Content) is the appropriate response status code,
898 depending on whether or not the response includes a representation
899 that describes the result.
901 If a resource has been created on the origin server, the response
902 SHOULD be 201 (Created) and contain a representation which describes
903 the status of the request and refers to the new resource, and a
904 Location header field (see Section 9.5).
906 Responses to POST requests are only cacheable when they include
907 explicit freshness information (see Section 2.3.1 of [Part6]). A
908 cached POST response with a Content-Location header field (see
909 Section 6.7 of [Part3]) whose value is the effective Request URI MAY
910 be used to satisfy subsequent GET and HEAD requests.
912 Note that POST caching is not widely implemented. However, the 303
913 (See Other) response can be used to direct the user agent to retrieve
914 a cacheable resource.
916 6.6. PUT
918 The PUT method requests that the state of the target resource be
919 created or replaced with the state defined by the representation
920 enclosed in the request message payload. A successful PUT of a given
921 representation would suggest that a subsequent GET on that same
922 target resource will result in an equivalent representation being
923 returned in a 200 (OK) response. However, there is no guarantee that
924 such a state change will be observable, since the target resource
925 might be acted upon by other user agents in parallel, or might be
926 subject to dynamic processing by the origin server, before any
927 subsequent GET is received. A successful response only implies that
928 the user agent's intent was achieved at the time of its processing by
929 the origin server.
931 If the target resource does not have a current representation and the
932 PUT successfully creates one, then the origin server MUST inform the
933 user agent by sending a 201 (Created) response. If the target
934 resource does have a current representation and that representation
935 is successfully modified in accordance with the state of the enclosed
936 representation, then either a 200 (OK) or 204 (No Content) response
937 SHOULD be sent to indicate successful completion of the request.
939 Unrecognized header fields SHOULD be ignored (i.e., not saved as part
940 of the resource state).
942 An origin server SHOULD verify that the PUT representation is
943 consistent with any constraints which the server has for the target
944 resource that cannot or will not be changed by the PUT. This is
945 particularly important when the origin server uses internal
946 configuration information related to the URI in order to set the
947 values for representation metadata on GET responses. When a PUT
948 representation is inconsistent with the target resource, the origin
949 server SHOULD either make them consistent, by transforming the
950 representation or changing the resource configuration, or respond
951 with an appropriate error message containing sufficient information
952 to explain why the representation is unsuitable. The 409 (Conflict)
953 or 415 (Unsupported Media Type) status codes are suggested, with the
954 latter being specific to constraints on Content-Type values.
956 For example, if the target resource is configured to always have a
957 Content-Type of "text/html" and the representation being PUT has a
958 Content-Type of "image/jpeg", then the origin server SHOULD do one
959 of: (a) reconfigure the target resource to reflect the new media
960 type; (b) transform the PUT representation to a format consistent
961 with that of the resource before saving it as the new resource state;
962 or, (c) reject the request with a 415 response indicating that the
963 target resource is limited to "text/html", perhaps including a link
964 to a different resource that would be a suitable target for the new
965 representation.
967 HTTP does not define exactly how a PUT method affects the state of an
968 origin server beyond what can be expressed by the intent of the user
969 agent request and the semantics of the origin server response. It
970 does not define what a resource might be, in any sense of that word,
971 beyond the interface provided via HTTP. It does not define how
972 resource state is "stored", nor how such storage might change as a
973 result of a change in resource state, nor how the origin server
974 translates resource state into representations. Generally speaking,
975 all implementation details behind the resource interface are
976 intentionally hidden by the server.
978 The fundamental difference between the POST and PUT methods is
979 highlighted by the different intent for the target resource. The
980 target resource in a POST request is intended to handle the enclosed
981 representation as a data-accepting process, such as for a gateway to
982 some other protocol or a document that accepts annotations. In
983 contrast, the target resource in a PUT request is intended to take
984 the enclosed representation as a new or replacement value. Hence,
985 the intent of PUT is idempotent and visible to intermediaries, even
986 though the exact effect is only known by the origin server.
988 Proper interpretation of a PUT request presumes that the user agent
989 knows what target resource is desired. A service that is intended to
990 select a proper URI on behalf of the client, after receiving a state-
991 changing request, SHOULD be implemented using the POST method rather
992 than PUT. If the origin server will not make the requested PUT state
993 change to the target resource and instead wishes to have it applied
994 to a different resource, such as when the resource has been moved to
995 a different URI, then the origin server MUST send a 301 (Moved
996 Permanently) response; the user agent MAY then make its own decision
997 regarding whether or not to redirect the request.
999 A PUT request applied to the target resource MAY have side-effects on
1000 other resources. For example, an article might have a URI for
1001 identifying "the current version" (a resource) which is separate from
1002 the URIs identifying each particular version (different resources
1003 that at one point shared the same state as the current version
1004 resource). A successful PUT request on "the current version" URI
1005 might therefore create a new version resource in addition to changing
1006 the state of the target resource, and might also cause links to be
1007 added between the related resources.
1009 An origin server SHOULD reject any PUT request that contains a
1010 Content-Range header field, since it might be misinterpreted as
1011 partial content (or might be partial content that is being mistakenly
1012 PUT as a full representation). Partial content updates are possible
1013 by targeting a separately identified resource with state that
1014 overlaps a portion of the larger resource, or by using a different
1015 method that has been specifically defined for partial updates (for
1016 example, the PATCH method defined in [RFC5789]).
1018 Responses to the PUT method are not cacheable. If a PUT request
1019 passes through a cache that has one or more stored responses for the
1020 effective request URI, those stored responses will be invalidated
1021 (see Section 2.5 of [Part6]).
1023 6.7. DELETE
1025 The DELETE method requests that the origin server delete the target
1026 resource. This method MAY be overridden by human intervention (or
1027 other means) on the origin server. The client cannot be guaranteed
1028 that the operation has been carried out, even if the status code
1029 returned from the origin server indicates that the action has been
1030 completed successfully. However, the server SHOULD NOT indicate
1031 success unless, at the time the response is given, it intends to
1032 delete the resource or move it to an inaccessible location.
1034 A successful response SHOULD be 200 (OK) if the response includes an
1035 representation describing the status, 202 (Accepted) if the action
1036 has not yet been enacted, or 204 (No Content) if the action has been
1037 enacted but the response does not include a representation.
1039 Bodies on DELETE requests have no defined semantics. Note that
1040 sending a body on a DELETE request might cause some existing
1041 implementations to reject the request.
1043 Responses to the DELETE method are not cacheable. If a DELETE
1044 request passes through a cache that has one or more stored responses
1045 for the effective request URI, those stored responses will be
1046 invalidated (see Section 2.5 of [Part6]).
1048 6.8. TRACE
1050 The TRACE method requests a remote, application-layer loop-back of
1051 the request message. The final recipient of the request SHOULD
1052 reflect the message received back to the client as the message-body
1053 of a 200 (OK) response. The final recipient is either the origin
1054 server or the first proxy to receive a Max-Forwards value of zero (0)
1055 in the request (see Section 9.6). A TRACE request MUST NOT include a
1056 message-body.
1058 TRACE allows the client to see what is being received at the other
1059 end of the request chain and use that data for testing or diagnostic
1060 information. The value of the Via header field (Section 8.8 of
1061 [Part1]) is of particular interest, since it acts as a trace of the
1062 request chain. Use of the Max-Forwards header field allows the
1063 client to limit the length of the request chain, which is useful for
1064 testing a chain of proxies forwarding messages in an infinite loop.
1066 If the request is valid, the response SHOULD have a Content-Type of
1067 "message/http" (see Section 9.3.1 of [Part1]) and contain a message-
1068 body that encloses a copy of the entire request message. Responses
1069 to the TRACE method are not cacheable.
1071 6.9. CONNECT
1073 The CONNECT method requests that the proxy establish a tunnel to the
1074 request-target and then restrict its behavior to blind forwarding of
1075 packets until the connection is closed.
1077 When using CONNECT, the request-target MUST use the authority form
1078 (Section 3.1.1.2 of [Part1]); i.e., the request-target consists of
1079 only the host name and port number of the tunnel destination,
1080 separated by a colon. For example,
1082 CONNECT server.example.com:80 HTTP/1.1
1083 Host: server.example.com:80
1085 Other HTTP mechanisms can be used normally with the CONNECT method --
1086 except end-to-end protocol Upgrade requests, since the tunnel must be
1087 established first.
1089 For example, proxy authentication might be used to establish the
1090 authority to create a tunnel:
1092 CONNECT server.example.com:80 HTTP/1.1
1093 Host: server.example.com:80
1094 Proxy-Authorization: basic aGVsbG86d29ybGQ=
1096 Bodies on CONNECT requests have no defined semantics. Note that
1097 sending a body on a CONNECT request might cause some existing
1098 implementations to reject the request.
1100 Like any other pipelined HTTP/1.1 request, data to be tunnel may be
1101 sent immediately after the blank line. The usual caveats also apply:
1102 data may be discarded if the eventual response is negative, and the
1103 connection may be reset with no response if more than one TCP segment
1104 is outstanding.
1106 6.9.1. Establishing a Tunnel with CONNECT
1108 Any successful (2xx) response to a CONNECT request indicates that the
1109 proxy has established a connection to the requested host and port,
1110 and has switched to tunneling the current connection to that server
1111 connection.
1113 It may be the case that the proxy itself can only reach the requested
1114 origin server through another proxy. In this case, the first proxy
1115 SHOULD make a CONNECT request of that next proxy, requesting a tunnel
1116 to the authority. A proxy MUST NOT respond with any 2xx status code
1117 unless it has either a direct or tunnel connection established to the
1118 authority.
1120 An origin server which receives a CONNECT request for itself MAY
1121 respond with a 2xx status code to indicate that a connection is
1122 established.
1124 If at any point either one of the peers gets disconnected, any
1125 outstanding data that came from that peer will be passed to the other
1126 one, and after that also the other connection will be terminated by
1127 the proxy. If there is outstanding data to that peer undelivered,
1128 that data will be discarded.
1130 7. Status Code Definitions
1132 The first digit of the Status-Code defines the class of response.
1133 The last two digits do not have any categorization role. There are 5
1134 values for the first digit:
1136 o 1xx: Informational - Request received, continuing process
1138 o 2xx: Success - The action was successfully received, understood,
1139 and accepted
1141 o 3xx: Redirection - Further action must be taken in order to
1142 complete the request
1144 o 4xx: Client Error - The request contains bad syntax or cannot be
1145 fulfilled
1147 o 5xx: Server Error - The server failed to fulfill an apparently
1148 valid request
1150 Each Status-Code is described below, including any metadata required
1151 in the response.
1153 7.1. Informational 1xx
1155 This class of status code indicates a provisional response,
1156 consisting only of the Status-Line and optional header fields, and is
1157 terminated by an empty line. There are no required header fields for
1158 this class of status code. Since HTTP/1.0 did not define any 1xx
1159 status codes, servers MUST NOT send a 1xx response to an HTTP/1.0
1160 client except under experimental conditions.
1162 A client MUST be prepared to accept one or more 1xx status responses
1163 prior to a regular response, even if the client does not expect a 100
1164 (Continue) status message. Unexpected 1xx status responses MAY be
1165 ignored by a user agent.
1167 Proxies MUST forward 1xx responses, unless the connection between the
1168 proxy and its client has been closed, or unless the proxy itself
1169 requested the generation of the 1xx response. (For example, if a
1170 proxy adds a "Expect: 100-continue" field when it forwards a request,
1171 then it need not forward the corresponding 100 (Continue)
1172 response(s).)
1174 7.1.1. 100 Continue
1176 The client SHOULD continue with its request. This interim response
1177 is used to inform the client that the initial part of the request has
1178 been received and has not yet been rejected by the server. The
1179 client SHOULD continue by sending the remainder of the request or, if
1180 the request has already been completed, ignore this response. The
1181 server MUST send a final response after the request has been
1182 completed. See Section 6.2.3 of [Part1] for detailed discussion of
1183 the use and handling of this status code.
1185 7.1.2. 101 Switching Protocols
1187 The server understands and is willing to comply with the client's
1188 request, via the Upgrade message header field (Section 8.7 of
1189 [Part1]), for a change in the application protocol being used on this
1190 connection. The server will switch protocols to those defined by the
1191 response's Upgrade header field immediately after the empty line
1192 which terminates the 101 response.
1194 The protocol SHOULD be switched only when it is advantageous to do
1195 so. For example, switching to a newer version of HTTP is
1196 advantageous over older versions, and switching to a real-time,
1197 synchronous protocol might be advantageous when delivering resources
1198 that use such features.
1200 7.2. Successful 2xx
1202 This class of status code indicates that the client's request was
1203 successfully received, understood, and accepted.
1205 7.2.1. 200 OK
1207 The request has succeeded. The payload returned with the response is
1208 dependent on the method used in the request, for example:
1210 GET a representation of the target resource is sent in the response;
1212 HEAD the same representation as GET, except without the message-
1213 body;
1215 POST a representation describing or containing the result of the
1216 action;
1218 TRACE a representation containing the request message as received by
1219 the end server.
1221 Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to
1222 determine freshness for 200 responses.
1224 7.2.2. 201 Created
1226 The request has been fulfilled and has resulted in a new resource
1227 being created. The newly created resource can be referenced by the
1228 URI(s) returned in the payload of the response, with the most
1229 specific URI for the resource given by a Location header field. The
1230 response SHOULD include a payload containing a list of resource
1231 characteristics and location(s) from which the user or user agent can
1232 choose the one most appropriate. The payload format is specified by
1233 the media type given in the Content-Type header field. The origin
1234 server MUST create the resource before returning the 201 status code.
1235 If the action cannot be carried out immediately, the server SHOULD
1236 respond with 202 (Accepted) response instead.
1238 A 201 response MAY contain an ETag response header field indicating
1239 the current value of the entity-tag for the representation of the
1240 resource just created (see Section 2.3 of [Part4]).
1242 7.2.3. 202 Accepted
1244 The request has been accepted for processing, but the processing has
1245 not been completed. The request might or might not eventually be
1246 acted upon, as it might be disallowed when processing actually takes
1247 place. There is no facility for re-sending a status code from an
1248 asynchronous operation such as this.
1250 The 202 response is intentionally non-committal. Its purpose is to
1251 allow a server to accept a request for some other process (perhaps a
1252 batch-oriented process that is only run once per day) without
1253 requiring that the user agent's connection to the server persist
1254 until the process is completed. The representation returned with
1255 this response SHOULD include an indication of the request's current
1256 status and either a pointer to a status monitor or some estimate of
1257 when the user can expect the request to be fulfilled.
1259 7.2.4. 203 Non-Authoritative Information
1261 The representation in the response has been transformed or otherwise
1262 modified by a transforming proxy (Section 2.4 of [Part1]). Note that
1263 the behaviour of transforming intermediaries is controlled by the no-
1264 transform Cache-Control directive (Section 3.2 of [Part6]).
1266 This status code is only appropriate when the response status code
1267 would have been 200 (OK) otherwise. When the status code before
1268 transformation would have been different, the 214 Transformation
1269 Applied warn-code (Section 3.6 of [Part6]) is appropriate.
1271 Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to
1272 determine freshness for 203 responses.
1274 7.2.5. 204 No Content
1276 The 204 (No Content) status code indicates that the server has
1277 successfully fulfilled the request and that there is no additional
1278 content to return in the response payload body. Metadata in the
1279 response header fields refer to the target resource and its current
1280 representation after the requested action.
1282 For example, if a 204 status code is received in response to a PUT
1283 request and the response contains an ETag header field, then the PUT
1284 was successful and the ETag field-value contains the entity-tag for
1285 the new representation of that target resource.
1287 The 204 response allows a server to indicate that the action has been
1288 successfully applied to the target resource while implying that the
1289 user agent SHOULD NOT traverse away from its current "document view"
1290 (if any). The server assumes that the user agent will provide some
1291 indication of the success to its user, in accord with its own
1292 interface, and apply any new or updated metadata in the response to
1293 the active representation.
1295 For example, a 204 status code is commonly used with document editing
1296 interfaces corresponding to a "save" action, such that the document
1297 being saved remains available to the user for editing. It is also
1298 frequently used with interfaces that expect automated data transfers
1299 to be prevalent, such as within distributed version control systems.
1301 The 204 response MUST NOT include a message-body, and thus is always
1302 terminated by the first empty line after the header fields.
1304 7.2.6. 205 Reset Content
1306 The server has fulfilled the request and the user agent SHOULD reset
1307 the document view which caused the request to be sent. This response
1308 is primarily intended to allow input for actions to take place via
1309 user input, followed by a clearing of the form in which the input is
1310 given so that the user can easily initiate another input action.
1312 The message-body included with the response MUST be empty. Note that
1313 receivers still need to parse the response according to the algorithm
1314 defined in Section 3.3 of [Part1].
1316 7.2.7. 206 Partial Content
1318 The server has fulfilled the partial GET request for the resource and
1319 the enclosed payload is a partial representation as defined in
1320 Section 3.1 of [Part5].
1322 Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to
1323 determine freshness for 206 responses.
1325 7.3. Redirection 3xx
1327 This class of status code indicates that further action needs to be
1328 taken by the user agent in order to fulfill the request. If the
1329 required action involves a subsequent HTTP request, it MAY be carried
1330 out by the user agent without interaction with the user if and only
1331 if the method used in the second request is known to be "safe", as
1332 defined in Section 6.1.1.
1334 There are several types of redirects:
1336 1. Redirects of the request to another URI, either temporarily or
1337 permanently. The new URI is specified in the Location header
1338 field. In this specification, the status codes 301 (Moved
1339 Permanently), 302 (Found), and 307 (Temporary Redirect) fall
1340 under this category.
1342 2. Redirection to a new location that represents an indirect
1343 response to the request, such as the result of a POST operation
1344 to be retrieved with a subsequent GET request. This is status
1345 code 303 (See Other).
1347 3. Redirection offering a choice of matching resources for use by
1348 agent-driven content negotiation (Section 5.2 of [Part3]). This
1349 is status code 300 (Multiple Choices).
1351 4. Other kinds of redirection, such as to a cached result (status
1352 code 304 (Not Modified)).
1354 Note: In HTTP/1.0, only the status codes 301 (Moved Permanently)
1355 and 302 (Found) were defined for the first type of redirect, and
1356 the second type did not exist at all ([RFC1945], Section 9.3).
1357 However it turned out that web forms using POST expected redirects
1358 to change the operation for the subsequent request to retrieval
1359 (GET). To address this use case, HTTP/1.1 introduced the second
1360 type of redirect with the status code 303 (See Other) ([RFC2068],
1361 Section 10.3.4). As user agents did not change their behavior to
1362 maintain backwards compatibility, the first revision of HTTP/1.1
1363 added yet another status code, 307 (Temporary Redirect), for which
1364 the backwards compatibility problems did not apply ([RFC2616],
1365 Section 10.3.8). Over 10 years later, most user agents still do
1366 method rewriting for status codes 301 and 302, therefore this
1367 specification makes that behavior compliant in case the original
1368 request was POST.
1370 Clients SHOULD detect and intervene in cyclical redirections (i.e.,
1371 "infinite" redirection loops).
1373 Note: An earlier version of this specification recommended a
1374 maximum of five redirections ([RFC2068], Section 10.3). Content
1375 developers need to be aware that some clients might implement such
1376 a fixed limitation.
1378 7.3.1. 300 Multiple Choices
1380 The target resource has more than one representation, each with its
1381 own specific location, and agent-driven negotiation information
1382 (Section 5 of [Part3]) is being provided so that the user (or user
1383 agent) can select a preferred representation by redirecting its
1384 request to that location.
1386 Unless it was a HEAD request, the response SHOULD include a
1387 representation containing a list of representation metadata and
1388 location(s) from which the user or user agent can choose the one most
1389 appropriate. The data format is specified by the media type given in
1390 the Content-Type header field. Depending upon the format and the
1391 capabilities of the user agent, selection of the most appropriate
1392 choice MAY be performed automatically. However, this specification
1393 does not define any standard for such automatic selection.
1395 If the server has a preferred choice of representation, it SHOULD
1396 include the specific URI for that representation in the Location
1397 field; user agents MAY use the Location field value for automatic
1398 redirection.
1400 Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to
1401 determine freshness for 300 responses.
1403 7.3.2. 301 Moved Permanently
1405 The target resource has been assigned a new permanent URI and any
1406 future references to this resource SHOULD use one of the returned
1407 URIs. Clients with link editing capabilities ought to automatically
1408 re-link references to the effective request URI to one or more of the
1409 new references returned by the server, where possible.
1411 Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to
1412 determine freshness for 301 responses.
1414 The new permanent URI SHOULD be given by the Location field in the
1415 response. Unless the request method was HEAD, the representation of
1416 the response SHOULD contain a short hypertext note with a hyperlink
1417 to the new URI(s).
1419 If the 301 status code is received in response to a request method
1420 that is known to be "safe", as defined in Section 6.1.1, then the
1421 request MAY be automatically redirected by the user agent without
1422 confirmation. Otherwise, the user agent MUST NOT automatically
1423 redirect the request unless it can be confirmed by the user, since
1424 this might change the conditions under which the request was issued.
1426 Note: For historic reasons, user agents MAY change the request
1427 method from POST to GET for the subsequent request. If this
1428 behavior is undesired, status code 307 (Temporary Redirect) can be
1429 used instead.
1431 7.3.3. 302 Found
1433 The target resource resides temporarily under a different URI. Since
1434 the redirection might be altered on occasion, the client SHOULD
1435 continue to use the effective request URI for future requests.
1437 The temporary URI SHOULD be given by the Location field in the
1438 response. Unless the request method was HEAD, the representation of
1439 the response SHOULD contain a short hypertext note with a hyperlink
1440 to the new URI(s).
1442 If the 302 status code is received in response to a request method
1443 that is known to be "safe", as defined in Section 6.1.1, then the
1444 request MAY be automatically redirected by the user agent without
1445 confirmation. Otherwise, the user agent MUST NOT automatically
1446 redirect the request unless it can be confirmed by the user, since
1447 this might change the conditions under which the request was issued.
1449 Note: For historic reasons, user agents MAY change the request
1450 method from POST to GET for the subsequent request. If this
1451 behavior is undesired, status code 307 (Temporary Redirect) can be
1452 used instead. [[issue312: but see
1453 ]]
1455 7.3.4. 303 See Other
1457 The 303 status code indicates that the server is redirecting the user
1458 agent to a different resource, as indicated by a URI in the Location
1459 header field, that is intended to provide an indirect response to the
1460 original request. In order to satisfy the original request, a user
1461 agent SHOULD perform a retrieval request using the Location URI (a
1462 GET or HEAD request if using HTTP), which may itself be redirected
1463 further, and present the eventual result as an answer to the original
1464 request. Note that the new URI in the Location header field is not
1465 considered equivalent to the effective request URI.
1467 This status code is generally applicable to any HTTP method. It is
1468 primarily used to allow the output of a POST action to redirect the
1469 user agent to a selected resource, since doing so provides the
1470 information corresponding to the POST response in a form that can be
1471 separately identified, bookmarked, and cached independent of the
1472 original request.
1474 A 303 response to a GET request indicates that the requested resource
1475 does not have a representation of its own that can be transferred by
1476 the server over HTTP. The Location URI indicates a resource that is
1477 descriptive of the target resource, such that the follow-on
1478 representation might be useful to recipients without implying that it
1479 adequately represents the target resource. Note that answers to the
1480 questions of what can be represented, what representations are
1481 adequate, and what might be a useful description are outside the
1482 scope of HTTP and thus entirely determined by the URI owner(s).
1484 Except for responses to a HEAD request, the representation of a 303
1485 response SHOULD contain a short hypertext note with a hyperlink to
1486 the Location URI.
1488 7.3.5. 304 Not Modified
1490 The response to the request has not been modified since the
1491 conditions indicated by the client's conditional GET request, as
1492 defined in Section 4.1 of [Part4].
1494 7.3.6. 305 Use Proxy
1496 The 305 status code was defined in a previous version of this
1497 specification (see Appendix A), and is now deprecated.
1499 7.3.7. 306 (Unused)
1501 The 306 status code was used in a previous version of the
1502 specification, is no longer used, and the code is reserved.
1504 7.3.8. 307 Temporary Redirect
1506 The target resource resides temporarily under a different URI. Since
1507 the redirection can change over time, the client SHOULD continue to
1508 use the effective request URI for future requests.
1510 The temporary URI SHOULD be given by the Location field in the
1511 response. Unless the request method was HEAD, the representation of
1512 the response SHOULD contain a short hypertext note with a hyperlink
1513 to the new URI(s), since many pre-HTTP/1.1 user agents do not
1514 understand the 307 status code. Therefore, the note SHOULD contain
1515 the information necessary for a user to repeat the original request
1516 on the new URI.
1518 If the 307 status code is received in response to a request method
1519 that is known to be "safe", as defined in Section 6.1.1, then the
1520 request MAY be automatically redirected by the user agent without
1521 confirmation. Otherwise, the user agent MUST NOT automatically
1522 redirect the request unless it can be confirmed by the user, since
1523 this might change the conditions under which the request was issued.
1525 7.4. Client Error 4xx
1527 The 4xx class of status code is intended for cases in which the
1528 client seems to have erred. Except when responding to a HEAD
1529 request, the server SHOULD include a representation containing an
1530 explanation of the error situation, and whether it is a temporary or
1531 permanent condition. These status codes are applicable to any
1532 request method. User agents SHOULD display any included
1533 representation to the user.
1535 If the client is sending data, a server implementation using TCP
1536 SHOULD be careful to ensure that the client acknowledges receipt of
1537 the packet(s) containing the response, before the server closes the
1538 input connection. If the client continues sending data to the server
1539 after the close, the server's TCP stack will send a reset packet to
1540 the client, which might erase the client's unacknowledged input
1541 buffers before they can be read and interpreted by the HTTP
1542 application.
1544 7.4.1. 400 Bad Request
1546 The server cannot or will not process the request, due to a client
1547 error (e.g., malformed syntax).
1549 7.4.2. 401 Unauthorized
1551 The request requires user authentication (see Section 3.1 of
1552 [Part7]).
1554 7.4.3. 402 Payment Required
1556 This code is reserved for future use.
1558 7.4.4. 403 Forbidden
1560 The server understood the request, but refuses to authorize it.
1561 Providing different user authentication credentials might be
1562 successful, but any credentials that were provided in the request are
1563 insufficient. The request SHOULD NOT be repeated with the same
1564 credentials.
1566 If the request method was not HEAD and the server wishes to make
1567 public why the request has not been fulfilled, it SHOULD describe the
1568 reason for the refusal in the representation. If the server does not
1569 wish to make this information available to the client, the status
1570 code 404 (Not Found) MAY be used instead.
1572 7.4.5. 404 Not Found
1574 The server has not found anything matching the effective request URI.
1575 No indication is given of whether the condition is temporary or
1576 permanent. The 410 (Gone) status code SHOULD be used if the server
1577 knows, through some internally configurable mechanism, that an old
1578 resource is permanently unavailable and has no forwarding address.
1579 This status code is commonly used when the server does not wish to
1580 reveal exactly why the request has been refused, or when no other
1581 response is applicable.
1583 7.4.6. 405 Method Not Allowed
1585 The method specified in the Request-Line is not allowed for the
1586 target resource. The response MUST include an Allow header field
1587 containing a list of valid methods for the requested resource.
1589 7.4.7. 406 Not Acceptable
1591 The resource identified by the request is only capable of generating
1592 response representations which have content characteristics not
1593 acceptable according to the Accept and Accept-* header fields sent in
1594 the request (see Section 6 of [Part3]).
1596 Unless it was a HEAD request, the response SHOULD include a
1597 representation containing a list of available representation
1598 characteristics and location(s) from which the user or user agent can
1599 choose the one most appropriate. The data format is specified by the
1600 media type given in the Content-Type header field. Depending upon
1601 the format and the capabilities of the user agent, selection of the
1602 most appropriate choice MAY be performed automatically. However,
1603 this specification does not define any standard for such automatic
1604 selection.
1606 Note: HTTP/1.1 servers are allowed to return responses which are
1607 not acceptable according to the accept header fields sent in the
1608 request. In some cases, this might even be preferable to sending
1609 a 406 response. User agents are encouraged to inspect the header
1610 fields of an incoming response to determine if it is acceptable.
1612 If the response could be unacceptable, a user agent SHOULD
1613 temporarily stop receipt of more data and query the user for a
1614 decision on further actions.
1616 7.4.8. 407 Proxy Authentication Required
1618 This code is similar to 401 (Unauthorized), but indicates that the
1619 client must first authenticate itself with the proxy (see Section 3.2
1620 of [Part7]).
1622 7.4.9. 408 Request Timeout
1624 The client did not produce a request within the time that the server
1625 was prepared to wait. The client MAY repeat the request without
1626 modifications at any later time.
1628 7.4.10. 409 Conflict
1630 The request could not be completed due to a conflict with the current
1631 state of the resource. This code is only allowed in situations where
1632 it is expected that the user might be able to resolve the conflict
1633 and resubmit the request. The response body SHOULD include enough
1634 information for the user to recognize the source of the conflict.
1635 Ideally, the response representation would include enough information
1636 for the user or user agent to fix the problem; however, that might
1637 not be possible and is not required.
1639 Conflicts are most likely to occur in response to a PUT request. For
1640 example, if versioning were being used and the representation being
1641 PUT included changes to a resource which conflict with those made by
1642 an earlier (third-party) request, the server might use the 409
1643 response to indicate that it can't complete the request. In this
1644 case, the response representation would likely contain a list of the
1645 differences between the two versions in a format defined by the
1646 response Content-Type.
1648 7.4.11. 410 Gone
1650 The target resource is no longer available at the server and no
1651 forwarding address is known. This condition is expected to be
1652 considered permanent. Clients with link editing capabilities SHOULD
1653 delete references to the effective request URI after user approval.
1654 If the server does not know, or has no facility to determine, whether
1655 or not the condition is permanent, the status code 404 (Not Found)
1656 SHOULD be used instead.
1658 The 410 response is primarily intended to assist the task of web
1659 maintenance by notifying the recipient that the resource is
1660 intentionally unavailable and that the server owners desire that
1661 remote links to that resource be removed. Such an event is common
1662 for limited-time, promotional services and for resources belonging to
1663 individuals no longer working at the server's site. It is not
1664 necessary to mark all permanently unavailable resources as "gone" or
1665 to keep the mark for any length of time -- that is left to the
1666 discretion of the server owner.
1668 Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to
1669 determine freshness for 410 responses.
1671 7.4.12. 411 Length Required
1673 The server refuses to accept the request without a defined Content-
1674 Length. The client MAY repeat the request if it adds a valid
1675 Content-Length header field containing the length of the message-body
1676 in the request message.
1678 7.4.13. 412 Precondition Failed
1680 The precondition given in one or more of the header fields evaluated
1681 to false when it was tested on the server, as defined in Section 4.2
1682 of [Part4].
1684 7.4.14. 413 Request Representation Too Large
1686 The server is refusing to process a request because the request
1687 representation is larger than the server is willing or able to
1688 process. The server MAY close the connection to prevent the client
1689 from continuing the request.
1691 If the condition is temporary, the server SHOULD include a Retry-
1692 After header field to indicate that it is temporary and after what
1693 time the client MAY try again.
1695 7.4.15. 414 URI Too Long
1697 The server is refusing to service the request because the effective
1698 request URI is longer than the server is willing to interpret. This
1699 rare condition is only likely to occur when a client has improperly
1700 converted a POST request to a GET request with long query
1701 information, when the client has descended into a URI "black hole" of
1702 redirection (e.g., a redirected URI prefix that points to a suffix of
1703 itself), or when the server is under attack by a client attempting to
1704 exploit security holes present in some servers using fixed-length
1705 buffers for reading or manipulating the effective request URI.
1707 7.4.16. 415 Unsupported Media Type
1709 The server is refusing to service the request because the request
1710 payload is in a format not supported by this request method on the
1711 target resource.
1713 7.4.17. 416 Requested Range Not Satisfiable
1715 The request included a Range header field (Section 5.4 of [Part5])
1716 and none of the range-specifier values in this field overlap the
1717 current extent of the selected resource. See Section 3.2 of [Part5].
1719 7.4.18. 417 Expectation Failed
1721 The expectation given in an Expect header field (see Section 9.3)
1722 could not be met by this server, or, if the server is a proxy, the
1723 server has unambiguous evidence that the request could not be met by
1724 the next-hop server.
1726 7.4.19. 426 Upgrade Required
1728 The request can not be completed without a prior protocol upgrade.
1729 This response MUST include an Upgrade header field (Section 8.7 of
1730 [Part1]) specifying the required protocols.
1732 Example:
1734 HTTP/1.1 426 Upgrade Required
1735 Upgrade: HTTP/2.0
1736 Connection: Upgrade
1738 The server SHOULD include a message body in the 426 response which
1739 indicates in human readable form the reason for the error and
1740 describes any alternative courses which may be available to the user.
1742 7.5. Server Error 5xx
1744 Response status codes beginning with the digit "5" indicate cases in
1745 which the server is aware that it has erred or is incapable of
1746 performing the request. Except when responding to a HEAD request,
1747 the server SHOULD include a representation containing an explanation
1748 of the error situation, and whether it is a temporary or permanent
1749 condition. User agents SHOULD display any included representation to
1750 the user. These response codes are applicable to any request method.
1752 7.5.1. 500 Internal Server Error
1754 The server encountered an unexpected condition which prevented it
1755 from fulfilling the request.
1757 7.5.2. 501 Not Implemented
1759 The server does not support the functionality required to fulfill the
1760 request. This is the appropriate response when the server does not
1761 recognize the request method and is not capable of supporting it for
1762 any resource.
1764 7.5.3. 502 Bad Gateway
1766 The server, while acting as a gateway or proxy, received an invalid
1767 response from the upstream server it accessed in attempting to
1768 fulfill the request.
1770 7.5.4. 503 Service Unavailable
1772 The server is currently unable or unwilling to handle the request due
1773 to reasons such as temporary overloading, maintenance of the server,
1774 or rate limiting of the client.
1776 The implication is that this is a temporary condition which will be
1777 alleviated after some delay. If known, the length of the delay MAY
1778 be indicated in a Retry-After header field (Section 9.8). If no
1779 Retry-After is given, the client SHOULD handle the response as it
1780 would for a 500 response.
1782 Note: The existence of the 503 status code does not imply that a
1783 server must use it when becoming overloaded. Some servers might
1784 wish to simply refuse the connection.
1786 7.5.5. 504 Gateway Timeout
1788 The server, while acting as a gateway or proxy, did not receive a
1789 timely response from the upstream server specified by the URI (e.g.,
1790 HTTP, FTP, LDAP) or some other auxiliary server (e.g., DNS) it needed
1791 to access in attempting to complete the request.
1793 Note to implementors: some deployed proxies are known to return
1794 400 or 500 when DNS lookups time out.
1796 7.5.6. 505 HTTP Version Not Supported
1798 The server does not support, or refuses to support, the protocol
1799 version that was used in the request message. The server is
1800 indicating that it is unable or unwilling to complete the request
1801 using the same major version as the client, as described in Section
1802 2.6 of [Part1], other than with this error message. The response
1803 SHOULD contain a representation describing why that version is not
1804 supported and what other protocols are supported by that server.
1806 8. Date/Time Formats
1808 HTTP applications have historically allowed three different formats
1809 for date/time stamps. However, the preferred format is a fixed-
1810 length subset of that defined by [RFC1123]:
1812 Sun, 06 Nov 1994 08:49:37 GMT ; RFC 1123
1814 The other formats are described here only for compatibility with
1815 obsolete implementations.
1817 Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format
1818 Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format
1820 HTTP/1.1 clients and servers that parse a date value MUST accept all
1821 three formats (for compatibility with HTTP/1.0), though they MUST
1822 only generate the RFC 1123 format for representing HTTP-date values
1823 in header fields.
1825 All HTTP date/time stamps MUST be represented in Greenwich Mean Time
1826 (GMT), without exception. For the purposes of HTTP, GMT is exactly
1827 equal to UTC (Coordinated Universal Time). This is indicated in the
1828 first two formats by the inclusion of "GMT" as the three-letter
1829 abbreviation for time zone, and MUST be assumed when reading the
1830 asctime format. HTTP-date is case sensitive and MUST NOT include
1831 additional whitespace beyond that specifically included as SP in the
1832 grammar.
1834 HTTP-date = rfc1123-date / obs-date
1836 Preferred format:
1838 rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT
1839 ; fixed length subset of the format defined in
1840 ; Section 5.2.14 of [RFC1123]
1842 day-name = %x4D.6F.6E ; "Mon", case-sensitive
1843 / %x54.75.65 ; "Tue", case-sensitive
1844 / %x57.65.64 ; "Wed", case-sensitive
1845 / %x54.68.75 ; "Thu", case-sensitive
1846 / %x46.72.69 ; "Fri", case-sensitive
1847 / %x53.61.74 ; "Sat", case-sensitive
1848 / %x53.75.6E ; "Sun", case-sensitive
1850 date1 = day SP month SP year
1851 ; e.g., 02 Jun 1982
1853 day = 2DIGIT
1854 month = %x4A.61.6E ; "Jan", case-sensitive
1855 / %x46.65.62 ; "Feb", case-sensitive
1856 / %x4D.61.72 ; "Mar", case-sensitive
1857 / %x41.70.72 ; "Apr", case-sensitive
1858 / %x4D.61.79 ; "May", case-sensitive
1859 / %x4A.75.6E ; "Jun", case-sensitive
1860 / %x4A.75.6C ; "Jul", case-sensitive
1861 / %x41.75.67 ; "Aug", case-sensitive
1862 / %x53.65.70 ; "Sep", case-sensitive
1863 / %x4F.63.74 ; "Oct", case-sensitive
1864 / %x4E.6F.76 ; "Nov", case-sensitive
1865 / %x44.65.63 ; "Dec", case-sensitive
1866 year = 4DIGIT
1868 GMT = %x47.4D.54 ; "GMT", case-sensitive
1870 time-of-day = hour ":" minute ":" second
1871 ; 00:00:00 - 23:59:59
1873 hour = 2DIGIT
1874 minute = 2DIGIT
1875 second = 2DIGIT
1877 The semantics of day-name, day, month, year, and time-of-day are the
1878 same as those defined for the RFC 5322 constructs with the
1879 corresponding name ([RFC5322], Section 3.3).
1881 Obsolete formats:
1883 obs-date = rfc850-date / asctime-date
1884 rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT
1885 date2 = day "-" month "-" 2DIGIT
1886 ; day-month-year (e.g., 02-Jun-82)
1888 day-name-l = %x4D.6F.6E.64.61.79 ; "Monday", case-sensitive
1889 / %x54.75.65.73.64.61.79 ; "Tuesday", case-sensitive
1890 / %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive
1891 / %x54.68.75.72.73.64.61.79 ; "Thursday", case-sensitive
1892 / %x46.72.69.64.61.79 ; "Friday", case-sensitive
1893 / %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive
1894 / %x53.75.6E.64.61.79 ; "Sunday", case-sensitive
1896 asctime-date = day-name SP date3 SP time-of-day SP year
1897 date3 = month SP ( 2DIGIT / ( SP 1DIGIT ))
1898 ; month day (e.g., Jun 2)
1900 Note: Recipients of date values are encouraged to be robust in
1901 accepting date values that might have been sent by non-HTTP
1902 applications, as is sometimes the case when retrieving or posting
1903 messages via proxies/gateways to SMTP or NNTP.
1905 Note: HTTP requirements for the date/time stamp format apply only
1906 to their usage within the protocol stream. Clients and servers
1907 are not required to use these formats for user presentation,
1908 request logging, etc.
1910 9. Header Field Definitions
1912 This section defines the syntax and semantics of HTTP/1.1 header
1913 fields related to request and response semantics.
1915 9.1. Allow
1917 The "Allow" header field lists the set of methods advertised as
1918 supported by the target resource. The purpose of this field is
1919 strictly to inform the recipient of valid request methods associated
1920 with the resource.
1922 Allow = #Method
1924 Example of use:
1926 Allow: GET, HEAD, PUT
1928 The actual set of allowed methods is defined by the origin server at
1929 the time of each request.
1931 A proxy MUST NOT modify the Allow header field -- it does not need to
1932 understand all the methods specified in order to handle them
1933 according to the generic message handling rules.
1935 9.2. Date
1937 The "Date" header field represents the date and time at which the
1938 message was originated, having the same semantics as the Origination
1939 Date Field (orig-date) defined in Section 3.6.1 of [RFC5322]. The
1940 field value is an HTTP-date, as defined in Section 8; it MUST be sent
1941 in rfc1123-date format.
1943 Date = HTTP-date
1945 An example is
1947 Date: Tue, 15 Nov 1994 08:12:31 GMT
1949 Origin servers MUST include a Date header field in all responses,
1950 except in these cases:
1952 1. If the response status code is 100 (Continue) or 101 (Switching
1953 Protocols), the response MAY include a Date header field, at the
1954 server's option.
1956 2. If the response status code conveys a server error, e.g., 500
1957 (Internal Server Error) or 503 (Service Unavailable), and it is
1958 inconvenient or impossible to generate a valid Date.
1960 3. If the server does not have a clock that can provide a reasonable
1961 approximation of the current time, its responses MUST NOT include
1962 a Date header field.
1964 A received message that does not have a Date header field MUST be
1965 assigned one by the recipient if the message will be cached by that
1966 recipient.
1968 Clients can use the Date header field as well; in order to keep
1969 request messages small, they are advised not to include it when it
1970 doesn't convey any useful information (as it is usually the case for
1971 requests that do not contain a payload).
1973 The HTTP-date sent in a Date header field SHOULD NOT represent a date
1974 and time subsequent to the generation of the message. It SHOULD
1975 represent the best available approximation of the date and time of
1976 message generation, unless the implementation has no means of
1977 generating a reasonably accurate date and time. In theory, the date
1978 ought to represent the moment just before the payload is generated.
1980 In practice, the date can be generated at any time during the message
1981 origination without affecting its semantic value.
1983 9.3. Expect
1985 The "Expect" header field is used to indicate that particular server
1986 behaviors are required by the client.
1988 Expect = 1#expectation
1990 expectation = "100-continue" / expectation-extension
1991 expectation-extension = token [ "=" ( token / quoted-string )
1992 *expect-params ]
1993 expect-params = ";" token [ "=" ( token / quoted-string ) ]
1995 A server that does not understand or is unable to comply with any of
1996 the expectation values in the Expect field of a request MUST respond
1997 with appropriate error status code. The server MUST respond with a
1998 417 (Expectation Failed) status code if any of the expectations
1999 cannot be met or, if there are other problems with the request, some
2000 other 4xx status code.
2002 This header field is defined with extensible syntax to allow for
2003 future extensions. If a server receives a request containing an
2004 Expect field that includes an expectation-extension that it does not
2005 support, it MUST respond with a 417 (Expectation Failed) status code.
2007 Comparison of expectation values is case-insensitive for unquoted
2008 tokens (including the 100-continue token), and is case-sensitive for
2009 quoted-string expectation-extensions.
2011 The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy MUST
2012 return a 417 (Expectation Failed) status code if it receives a
2013 request with an expectation that it cannot meet. However, the Expect
2014 header field itself is end-to-end; it MUST be forwarded if the
2015 request is forwarded.
2017 Many older HTTP/1.0 and HTTP/1.1 applications do not understand the
2018 Expect header field.
2020 See Section 6.2.3 of [Part1] for the use of the 100 (Continue) status
2021 code.
2023 9.4. From
2025 The "From" header field, if given, SHOULD contain an Internet e-mail
2026 address for the human user who controls the requesting user agent.
2027 The address SHOULD be machine-usable, as defined by "mailbox" in
2028 Section 3.4 of [RFC5322]:
2030 From = mailbox
2032 mailbox =
2034 An example is:
2036 From: webmaster@example.org
2038 This header field MAY be used for logging purposes and as a means for
2039 identifying the source of invalid or unwanted requests. It SHOULD
2040 NOT be used as an insecure form of access protection. The
2041 interpretation of this field is that the request is being performed
2042 on behalf of the person given, who accepts responsibility for the
2043 method performed. In particular, robot agents SHOULD include this
2044 header field so that the person responsible for running the robot can
2045 be contacted if problems occur on the receiving end.
2047 The Internet e-mail address in this field MAY be separate from the
2048 Internet host which issued the request. For example, when a request
2049 is passed through a proxy the original issuer's address SHOULD be
2050 used.
2052 The client SHOULD NOT send the From header field without the user's
2053 approval, as it might conflict with the user's privacy interests or
2054 their site's security policy. It is strongly recommended that the
2055 user be able to disable, enable, and modify the value of this field
2056 at any time prior to a request.
2058 9.5. Location
2060 The "Location" header field is used to identify a newly created
2061 resource, or to redirect the recipient to a different location for
2062 completion of the request.
2064 For 201 (Created) responses, the Location is the URI of the new
2065 resource which was created by the request. For 3xx responses, the
2066 location SHOULD indicate the server's preferred URI for automatic
2067 redirection to the resource.
2069 The field value consists of a single URI-reference. When it has the
2070 form of a relative reference ([RFC3986], Section 4.2), the final
2071 value is computed by resolving it against the effective request URI
2072 ([RFC3986], Section 5).
2074 Location = URI-reference
2076 Examples are:
2078 Location: http://www.example.org/pub/WWW/People.html#tim
2080 Location: /index.html
2082 There are circumstances in which a fragment identifier in a Location
2083 URI would not be appropriate. For instance, when it appears in a 201
2084 Created response, where the Location header field specifies the URI
2085 for the entire created resource.
2087 Note: This specification does not define precedence rules for the
2088 case where the original URI, as navigated to by the user agent,
2089 and the Location header field value both contain fragment
2090 identifiers. Thus be aware that including fragment identifiers
2091 might inconvenience anyone relying on the semantics of the
2092 original URI's fragment identifier.
2094 Note: The Content-Location header field (Section 6.7 of [Part3])
2095 differs from Location in that the Content-Location identifies the
2096 most specific resource corresponding to the enclosed
2097 representation. It is therefore possible for a response to
2098 contain header fields for both Location and Content-Location.
2100 9.6. Max-Forwards
2102 The "Max-Forwards" header field provides a mechanism with the TRACE
2103 (Section 6.8) and OPTIONS (Section 6.2) methods to limit the number
2104 of times that the request is forwarded by proxies. This can be
2105 useful when the client is attempting to trace a request which appears
2106 to be failing or looping in mid-chain.
2108 Max-Forwards = 1*DIGIT
2110 The Max-Forwards value is a decimal integer indicating the remaining
2111 number of times this request message can be forwarded.
2113 Each recipient of a TRACE or OPTIONS request containing a Max-
2114 Forwards header field MUST check and update its value prior to
2115 forwarding the request. If the received value is zero (0), the
2116 recipient MUST NOT forward the request; instead, it MUST respond as
2117 the final recipient. If the received Max-Forwards value is greater
2118 than zero, then the forwarded message MUST contain an updated Max-
2119 Forwards field with a value decremented by one (1).
2121 The Max-Forwards header field MAY be ignored for all other request
2122 methods.
2124 9.7. Referer
2126 The "Referer" [sic] header field allows the client to specify the URI
2127 of the resource from which the effective request URI was obtained
2128 (the "referrer", although the header field is misspelled.).
2130 The Referer header field allows servers to generate lists of back-
2131 links to resources for interest, logging, optimized caching, etc. It
2132 also allows obsolete or mistyped links to be traced for maintenance.
2133 Some servers use Referer as a means of controlling where they allow
2134 links from (so-called "deep linking"), but legitimate requests do not
2135 always contain a Referer header field.
2137 If the effective request URI was obtained from a source that does not
2138 have its own URI (e.g., input from the user keyboard), the Referer
2139 field MUST either be sent with the value "about:blank", or not be
2140 sent at all. Note that this requirement does not apply to sources
2141 with non-HTTP URIs (e.g., FTP).
2143 Referer = absolute-URI / partial-URI
2145 Example:
2147 Referer: http://www.example.org/hypertext/Overview.html
2149 If the field value is a relative URI, it SHOULD be interpreted
2150 relative to the effective request URI. The URI MUST NOT include a
2151 fragment. See Section 11.2 for security considerations.
2153 9.8. Retry-After
2155 The header "Retry-After" field can be used with a 503 (Service
2156 Unavailable) response to indicate how long the service is expected to
2157 be unavailable to the requesting client. This field MAY also be used
2158 with any 3xx (Redirection) response to indicate the minimum time the
2159 user-agent is asked wait before issuing the redirected request.
2161 The value of this field can be either an HTTP-date or an integer
2162 number of seconds (in decimal) after the time of the response.
2164 Retry-After = HTTP-date / delta-seconds
2166 Time spans are non-negative decimal integers, representing time in
2167 seconds.
2169 delta-seconds = 1*DIGIT
2171 Two examples of its use are
2172 Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
2173 Retry-After: 120
2175 In the latter example, the delay is 2 minutes.
2177 9.9. Server
2179 The "Server" header field contains information about the software
2180 used by the origin server to handle the request.
2182 The field can contain multiple product tokens (Section 5.2 of
2183 [Part1]) and comments (Section 3.2 of [Part1]) identifying the server
2184 and any significant subproducts. The product tokens are listed in
2185 order of their significance for identifying the application.
2187 Server = product *( RWS ( product / comment ) )
2189 Example:
2191 Server: CERN/3.0 libwww/2.17
2193 If the response is being forwarded through a proxy, the proxy
2194 application MUST NOT modify the Server header field. Instead, it
2195 MUST include a Via field (as described in Section 8.8 of [Part1]).
2197 Note: Revealing the specific software version of the server might
2198 allow the server machine to become more vulnerable to attacks
2199 against software that is known to contain security holes. Server
2200 implementors are encouraged to make this field a configurable
2201 option.
2203 9.10. User-Agent
2205 The "User-Agent" header field contains information about the user
2206 agent originating the request. User agents SHOULD include this field
2207 with requests.
2209 Typically, it is used for statistical purposes, the tracing of
2210 protocol violations, and tailoring responses to avoid particular user
2211 agent limitations.
2213 The field can contain multiple product tokens (Section 5.2 of
2214 [Part1]) and comments (Section 3.2 of [Part1]) identifying the agent
2215 and its significant subproducts. By convention, the product tokens
2216 are listed in order of their significance for identifying the
2217 application.
2219 Because this field is usually sent on every request a user agent
2220 makes, implementations are encouraged not to include needlessly fine-
2221 grained detail, and to limit (or even prohibit) the addition of
2222 subproducts by third parties. Overly long and detailed User-Agent
2223 field values make requests larger and can also be used to identify
2224 ("fingerprint") the user against their wishes.
2226 Likewise, implementations are encouraged not to use the product
2227 tokens of other implementations in order to declare compatibility
2228 with them, as this circumvents the purpose of the field. Finally,
2229 they are encouraged not to use comments to identify products; doing
2230 so makes the field value more difficult to parse.
2232 User-Agent = product *( RWS ( product / comment ) )
2234 Example:
2236 User-Agent: CERN-LineMode/2.15 libwww/2.17b3
2238 10. IANA Considerations
2240 10.1. Method Registry
2242 The registration procedure for HTTP request methods is defined by
2243 Section 2.2 of this document.
2245 The HTTP Method Registry shall be created at
2246 and be populated with
2247 the registrations below:
2249 +---------+------+-------------+
2250 | Method | Safe | Reference |
2251 +---------+------+-------------+
2252 | CONNECT | no | Section 6.9 |
2253 | DELETE | no | Section 6.7 |
2254 | GET | yes | Section 6.3 |
2255 | HEAD | yes | Section 6.4 |
2256 | OPTIONS | yes | Section 6.2 |
2257 | POST | no | Section 6.5 |
2258 | PUT | no | Section 6.6 |
2259 | TRACE | yes | Section 6.8 |
2260 +---------+------+-------------+
2262 10.2. Status Code Registry
2264 The registration procedure for HTTP Status Codes -- previously
2265 defined in Section 7.1 of [RFC2817] -- is now defined by Section 4.2
2266 of this document.
2268 The HTTP Status Code Registry located at
2269 shall be updated
2270 with the registrations below:
2272 +-------+----------------------------------+----------------+
2273 | Value | Description | Reference |
2274 +-------+----------------------------------+----------------+
2275 | 100 | Continue | Section 7.1.1 |
2276 | 101 | Switching Protocols | Section 7.1.2 |
2277 | 200 | OK | Section 7.2.1 |
2278 | 201 | Created | Section 7.2.2 |
2279 | 202 | Accepted | Section 7.2.3 |
2280 | 203 | Non-Authoritative Information | Section 7.2.4 |
2281 | 204 | No Content | Section 7.2.5 |
2282 | 205 | Reset Content | Section 7.2.6 |
2283 | 300 | Multiple Choices | Section 7.3.1 |
2284 | 301 | Moved Permanently | Section 7.3.2 |
2285 | 302 | Found | Section 7.3.3 |
2286 | 303 | See Other | Section 7.3.4 |
2287 | 305 | Use Proxy | Section 7.3.6 |
2288 | 306 | (Unused) | Section 7.3.7 |
2289 | 307 | Temporary Redirect | Section 7.3.8 |
2290 | 400 | Bad Request | Section 7.4.1 |
2291 | 402 | Payment Required | Section 7.4.3 |
2292 | 403 | Forbidden | Section 7.4.4 |
2293 | 404 | Not Found | Section 7.4.5 |
2294 | 405 | Method Not Allowed | Section 7.4.6 |
2295 | 406 | Not Acceptable | Section 7.4.7 |
2296 | 407 | Proxy Authentication Required | Section 7.4.8 |
2297 | 408 | Request Timeout | Section 7.4.9 |
2298 | 409 | Conflict | Section 7.4.10 |
2299 | 410 | Gone | Section 7.4.11 |
2300 | 411 | Length Required | Section 7.4.12 |
2301 | 413 | Request Representation Too Large | Section 7.4.14 |
2302 | 414 | URI Too Long | Section 7.4.15 |
2303 | 415 | Unsupported Media Type | Section 7.4.16 |
2304 | 417 | Expectation Failed | Section 7.4.18 |
2305 | 426 | Upgrade Required | Section 7.4.19 |
2306 | 500 | Internal Server Error | Section 7.5.1 |
2307 | 501 | Not Implemented | Section 7.5.2 |
2308 | 502 | Bad Gateway | Section 7.5.3 |
2309 | 503 | Service Unavailable | Section 7.5.4 |
2310 | 504 | Gateway Timeout | Section 7.5.5 |
2311 | 505 | HTTP Version Not Supported | Section 7.5.6 |
2312 +-------+----------------------------------+----------------+
2314 10.3. Header Field Registration
2316 The Message Header Field Registry located at shall be
2318 updated with the permanent registrations below (see [RFC3864]):
2320 +-------------------+----------+----------+--------------+
2321 | Header Field Name | Protocol | Status | Reference |
2322 +-------------------+----------+----------+--------------+
2323 | Allow | http | standard | Section 9.1 |
2324 | Date | http | standard | Section 9.2 |
2325 | Expect | http | standard | Section 9.3 |
2326 | From | http | standard | Section 9.4 |
2327 | Location | http | standard | Section 9.5 |
2328 | Max-Forwards | http | standard | Section 9.6 |
2329 | Referer | http | standard | Section 9.7 |
2330 | Retry-After | http | standard | Section 9.8 |
2331 | Server | http | standard | Section 9.9 |
2332 | User-Agent | http | standard | Section 9.10 |
2333 +-------------------+----------+----------+--------------+
2335 The change controller is: "IETF (iesg@ietf.org) - Internet
2336 Engineering Task Force".
2338 11. Security Considerations
2340 This section is meant to inform application developers, information
2341 providers, and users of the security limitations in HTTP/1.1 as
2342 described by this document. The discussion does not include
2343 definitive solutions to the problems revealed, though it does make
2344 some suggestions for reducing security risks.
2346 11.1. Transfer of Sensitive Information
2348 Like any generic data transfer protocol, HTTP cannot regulate the
2349 content of the data that is transferred, nor is there any a priori
2350 method of determining the sensitivity of any particular piece of
2351 information within the context of any given request. Therefore,
2352 applications SHOULD supply as much control over this information as
2353 possible to the provider of that information. Four header fields are
2354 worth special mention in this context: Server, Via, Referer and From.
2356 Revealing the specific software version of the server might allow the
2357 server machine to become more vulnerable to attacks against software
2358 that is known to contain security holes. Implementors SHOULD make
2359 the Server header field a configurable option.
2361 Proxies which serve as a portal through a network firewall SHOULD
2362 take special precautions regarding the transfer of header information
2363 that identifies the hosts behind the firewall. In particular, they
2364 SHOULD remove, or replace with sanitized versions, any Via fields
2365 generated behind the firewall.
2367 The Referer header field allows reading patterns to be studied and
2368 reverse links drawn. Although it can be very useful, its power can
2369 be abused if user details are not separated from the information
2370 contained in the Referer. Even when the personal information has
2371 been removed, the Referer header field might indicate a private
2372 document's URI whose publication would be inappropriate.
2374 The information sent in the From field might conflict with the user's
2375 privacy interests or their site's security policy, and hence it
2376 SHOULD NOT be transmitted without the user being able to disable,
2377 enable, and modify the contents of the field. The user MUST be able
2378 to set the contents of this field within a user preference or
2379 application defaults configuration.
2381 We suggest, though do not require, that a convenient toggle interface
2382 be provided for the user to enable or disable the sending of From and
2383 Referer information.
2385 The User-Agent (Section 9.10) or Server (Section 9.9) header fields
2386 can sometimes be used to determine that a specific client or server
2387 have a particular security hole which might be exploited.
2388 Unfortunately, this same information is often used for other valuable
2389 purposes for which HTTP currently has no better mechanism.
2391 Furthermore, the User-Agent header field may contain enough entropy
2392 to be used, possibly in conjunction with other material, to uniquely
2393 identify the user.
2395 Some request methods, like TRACE (Section 6.8), expose information
2396 that was sent in request header fields within the body of their
2397 response. Clients SHOULD be careful with sensitive information, like
2398 Cookies, Authorization credentials, and other header fields that
2399 might be used to collect data from the client.
2401 11.2. Encoding Sensitive Information in URIs
2403 Because the source of a link might be private information or might
2404 reveal an otherwise private information source, it is strongly
2405 recommended that the user be able to select whether or not the
2406 Referer field is sent. For example, a browser client could have a
2407 toggle switch for browsing openly/anonymously, which would
2408 respectively enable/disable the sending of Referer and From
2409 information.
2411 Clients SHOULD NOT include a Referer header field in a (non-secure)
2412 HTTP request if the referring page was transferred with a secure
2413 protocol.
2415 Authors of services SHOULD NOT use GET-based forms for the submission
2416 of sensitive data because that data will be placed in the request-
2417 target. Many existing servers, proxies, and user agents log or
2418 display the request-target in places where it might be visible to
2419 third parties. Such services can use POST-based form submission
2420 instead.
2422 11.3. Location Headers and Spoofing
2424 If a single server supports multiple organizations that do not trust
2425 one another, then it MUST check the values of Location and Content-
2426 Location header fields in responses that are generated under control
2427 of said organizations to make sure that they do not attempt to
2428 invalidate resources over which they have no authority.
2430 11.4. Security Considerations for CONNECT
2432 Since tunneled data is opaque to the proxy, there are additional
2433 risks to tunneling to other well-known or reserved ports. A HTTP
2434 client CONNECTing to port 25 could relay spam via SMTP, for example.
2435 As such, proxies SHOULD restrict CONNECT access to a small number of
2436 known ports.
2438 12. Acknowledgments
2440 See Section 11 of [Part1].
2442 13. References
2444 13.1. Normative References
2446 [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
2447 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
2448 and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,
2449 and Message Parsing", draft-ietf-httpbis-p1-messaging-17
2450 (work in progress), October 2011.
2452 [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
2453 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
2454 and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload
2455 and Content Negotiation", draft-ietf-httpbis-p3-payload-17
2456 (work in progress), October 2011.
2458 [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
2459 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
2460 and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional
2461 Requests", draft-ietf-httpbis-p4-conditional-17 (work in
2462 progress), October 2011.
2464 [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
2465 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
2466 and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and
2467 Partial Responses", draft-ietf-httpbis-p5-range-17 (work
2468 in progress), October 2011.
2470 [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
2471 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
2472 Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part
2473 6: Caching", draft-ietf-httpbis-p6-cache-17 (work in
2474 progress), October 2011.
2476 [Part7] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
2477 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
2478 and J. Reschke, Ed., "HTTP/1.1, part 7: Authentication",
2479 draft-ietf-httpbis-p7-auth-17 (work in progress),
2480 October 2011.
2482 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
2483 Requirement Levels", BCP 14, RFC 2119, March 1997.
2485 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
2486 Resource Identifier (URI): Generic Syntax", STD 66,
2487 RFC 3986, January 2005.
2489 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
2490 Specifications: ABNF", STD 68, RFC 5234, January 2008.
2492 13.2. Informative References
2494 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application
2495 and Support", STD 3, RFC 1123, October 1989.
2497 [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext
2498 Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
2500 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.
2501 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
2502 RFC 2068, January 1997.
2504 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
2505 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
2506 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
2508 [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within
2509 HTTP/1.1", RFC 2817, May 2000.
2511 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
2512 Procedures for Message Header Fields", BCP 90, RFC 3864,
2513 September 2004.
2515 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
2516 IANA Considerations Section in RFCs", BCP 26, RFC 5226,
2517 May 2008.
2519 [RFC5322] Resnick, P., "Internet Message Format", RFC 5322,
2520 October 2008.
2522 [RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP",
2523 RFC 5789, March 2010.
2525 [RFC5987] Reschke, J., "Character Set and Language Encoding for
2526 Hypertext Transfer Protocol (HTTP) Header Field
2527 Parameters", RFC 5987, August 2010.
2529 Appendix A. Changes from RFC 2616
2531 This document takes over the Status Code Registry, previously defined
2532 in Section 7.1 of [RFC2817]. (Section 4.2)
2534 Clarify definition of POST. (Section 6.5)
2536 Remove requirement to handle all Content-* header fields; ban use of
2537 Content-Range with PUT. (Section 6.6)
2539 Take over definition of CONNECT method from [RFC2817]. (Section 6.9)
2541 Broadened the definition of 203 (Non-Authoritative Information) to
2542 include cases of payload transformations as well. (Section 7.2.4)
2544 Failed to consider that there are many other request methods that are
2545 safe to automatically redirect, and further that the user agent is
2546 able to make that determination based on the request method
2547 semantics. Furthermore, allow user agents to rewrite the method from
2548 POST to GET for status codes 301 and 302. (Sections 7.3.2, 7.3.3 and
2549 7.3.8)
2551 Deprecate 305 Use Proxy status code, because user agents did not
2552 implement it. It used to indicate that the target resource must be
2553 accessed through the proxy given by the Location field. The Location
2554 field gave the URI of the proxy. The recipient was expected to
2555 repeat this single request via the proxy. (Section 7.3.6)
2556 Define status 426 (Upgrade Required) (this was incorporated from
2557 [RFC2817]). (Section 7.4.19)
2559 Change ABNF productions for header fields to only define the field
2560 value. (Section 9)
2562 Reclassify "Allow" as response header field, removing the option to
2563 specify it in a PUT request. Relax the server requirement on the
2564 contents of the Allow header field and remove requirement on clients
2565 to always trust the header field value. (Section 9.1)
2567 Correct syntax of Location header field to allow URI references
2568 (including relative references and fragments), as referred symbol
2569 "absoluteURI" wasn't what was expected, and add some clarifications
2570 as to when use of fragments would not be appropriate. (Section 9.5)
2572 Restrict Max-Forwards header field to OPTIONS and TRACE (previously,
2573 extension methods could have used it as well). (Section 9.6)
2575 Allow Referer field value of "about:blank" as alternative to not
2576 specifying it. (Section 9.7)
2578 In the description of the Server header field, the Via field was
2579 described as a SHOULD. The requirement was and is stated correctly
2580 in the description of the Via header field in Section 8.8 of [Part1].
2581 (Section 9.9)
2583 Appendix B. Collected ABNF
2585 Allow = [ ( "," / Method ) *( OWS "," [ OWS Method ] ) ]
2587 Date = HTTP-date
2589 Expect = *( "," OWS ) expectation *( OWS "," [ OWS expectation ] )
2591 From = mailbox
2593 GMT = %x47.4D.54 ; GMT
2595 HTTP-date = rfc1123-date / obs-date
2597 Location = URI-reference
2599 Max-Forwards = 1*DIGIT
2600 Method = token
2602 OWS =
2603 RWS =
2604 Reason-Phrase = *( HTAB / SP / VCHAR / obs-text )
2605 Referer = absolute-URI / partial-URI
2606 Retry-After = HTTP-date / delta-seconds
2608 Server = product *( RWS ( product / comment ) )
2609 Status-Code = 3DIGIT
2611 URI-reference =
2612 User-Agent = product *( RWS ( product / comment ) )
2614 absolute-URI =
2615 asctime-date = day-name SP date3 SP time-of-day SP year
2617 comment =
2619 date1 = day SP month SP year
2620 date2 = day "-" month "-" 2DIGIT
2621 date3 = month SP ( 2DIGIT / ( SP DIGIT ) )
2622 day = 2DIGIT
2623 day-name = %x4D.6F.6E ; Mon
2624 / %x54.75.65 ; Tue
2625 / %x57.65.64 ; Wed
2626 / %x54.68.75 ; Thu
2627 / %x46.72.69 ; Fri
2628 / %x53.61.74 ; Sat
2629 / %x53.75.6E ; Sun
2630 day-name-l = %x4D.6F.6E.64.61.79 ; Monday
2631 / %x54.75.65.73.64.61.79 ; Tuesday
2632 / %x57.65.64.6E.65.73.64.61.79 ; Wednesday
2633 / %x54.68.75.72.73.64.61.79 ; Thursday
2634 / %x46.72.69.64.61.79 ; Friday
2635 / %x53.61.74.75.72.64.61.79 ; Saturday
2636 / %x53.75.6E.64.61.79 ; Sunday
2637 delta-seconds = 1*DIGIT
2639 expect-params = ";" token [ "=" ( token / quoted-string ) ]
2640 expectation = "100-continue" / expectation-extension
2641 expectation-extension = token [ "=" ( token / quoted-string )
2642 *expect-params ]
2644 hour = 2DIGIT
2646 mailbox =
2647 minute = 2DIGIT
2648 month = %x4A.61.6E ; Jan
2649 / %x46.65.62 ; Feb
2650 / %x4D.61.72 ; Mar
2651 / %x41.70.72 ; Apr
2652 / %x4D.61.79 ; May
2653 / %x4A.75.6E ; Jun
2654 / %x4A.75.6C ; Jul
2655 / %x41.75.67 ; Aug
2656 / %x53.65.70 ; Sep
2657 / %x4F.63.74 ; Oct
2658 / %x4E.6F.76 ; Nov
2659 / %x44.65.63 ; Dec
2661 obs-date = rfc850-date / asctime-date
2662 obs-text =
2664 partial-URI =
2665 product =
2667 quoted-string =
2669 rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT
2670 rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT
2672 second = 2DIGIT
2674 time-of-day = hour ":" minute ":" second
2675 token =
2677 year = 4DIGIT
2679 ABNF diagnostics:
2681 ; Allow defined but not used
2682 ; Date defined but not used
2683 ; Expect defined but not used
2684 ; From defined but not used
2685 ; Location defined but not used
2686 ; Max-Forwards defined but not used
2687 ; Reason-Phrase defined but not used
2688 ; Referer defined but not used
2689 ; Retry-After defined but not used
2690 ; Server defined but not used
2691 ; Status-Code defined but not used
2692 ; User-Agent defined but not used
2694 Appendix C. Change Log (to be removed by RFC Editor before publication)
2696 C.1. Since RFC 2616
2698 Extracted relevant partitions from [RFC2616].
2700 C.2. Since draft-ietf-httpbis-p2-semantics-00
2702 Closed issues:
2704 o : "Via is a MUST"
2705 ()
2707 o : "Fragments
2708 allowed in Location"
2709 ()
2711 o : "Safe Methods
2712 vs Redirection" ()
2714 o : "Revise
2715 description of the POST method"
2716 ()
2718 o : "Normative and
2719 Informative references"
2721 o : "RFC2606
2722 Compliance"
2724 o : "Informative
2725 references"
2727 o : "Redundant
2728 cross-references"
2730 Other changes:
2732 o Move definitions of 304 and 412 condition codes to [Part4]
2734 C.3. Since draft-ietf-httpbis-p2-semantics-01
2736 Closed issues:
2738 o : "PUT side
2739 effects"
2741 o : "Duplicate Host
2742 header requirements"
2744 Ongoing work on ABNF conversion
2745 ():
2747 o Move "Product Tokens" section (back) into Part 1, as "token" is
2748 used in the definition of the Upgrade header field.
2750 o Add explicit references to BNF syntax and rules imported from
2751 other parts of the specification.
2753 o Copy definition of delta-seconds from Part6 instead of referencing
2754 it.
2756 C.4. Since draft-ietf-httpbis-p2-semantics-02
2758 Closed issues:
2760 o : "Requiring
2761 Allow in 405 responses"
2763 o : "Status Code
2764 Registry"
2766 o : "Redirection
2767 vs. Location"
2769 o : "Cacheability
2770 of 303 response"
2772 o : "305 Use Proxy"
2774 o :
2775 "Classification for Allow header"
2777 o : "PUT - 'store
2778 under' vs 'store at'"
2780 Ongoing work on IANA Message Header Field Registration
2781 ():
2783 o Reference RFC 3984, and update header field registrations for
2784 headers defined in this document.
2786 Ongoing work on ABNF conversion
2787 ():
2789 o Replace string literals when the string really is case-sensitive
2790 (method).
2792 C.5. Since draft-ietf-httpbis-p2-semantics-03
2794 Closed issues:
2796 o : "OPTIONS
2797 request bodies"
2799 o : "Description
2800 of CONNECT should refer to RFC2817"
2802 o : "Location
2803 Content-Location reference request/response mixup"
2805 Ongoing work on Method Registry
2806 ():
2808 o Added initial proposal for registration process, plus initial
2809 content (non-HTTP/1.1 methods to be added by a separate
2810 specification).
2812 C.6. Since draft-ietf-httpbis-p2-semantics-04
2814 Closed issues:
2816 o : "Content-*"
2818 o : "RFC 2822 is
2819 updated by RFC 5322"
2821 Ongoing work on ABNF conversion
2822 ():
2824 o Use "/" instead of "|" for alternatives.
2826 o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
2827 whitespace ("OWS") and required whitespace ("RWS").
2829 o Rewrite ABNFs to spell out whitespace rules, factor out header
2830 field value format definitions.
2832 C.7. Since draft-ietf-httpbis-p2-semantics-05
2834 Closed issues:
2836 o : "Reason-Phrase
2837 BNF"
2839 Final work on ABNF conversion
2840 ():
2842 o Add appendix containing collected and expanded ABNF, reorganize
2843 ABNF introduction.
2845 C.8. Since draft-ietf-httpbis-p2-semantics-06
2847 Closed issues:
2849 o : "Clarify when
2850 Referer is sent"
2852 o : "status codes
2853 vs methods"
2855 o : "Do not
2856 require "updates" relation for specs that register status codes or
2857 method names"
2859 C.9. Since draft-ietf-httpbis-p2-semantics-07
2861 Closed issues:
2863 o : "Idempotency"
2865 o : "TRACE security
2866 considerations"
2868 o : "Clarify rules
2869 for determining what entities a response carries"
2871 o : "update note
2872 citing RFC 1945 and 2068"
2874 o : "update note
2875 about redirect limit"
2877 o : "Location
2878 header ABNF should use 'URI'"
2880 o : "fragments in
2881 Location vs status 303"
2883 o : "move IANA
2884 registrations for optional status codes"
2886 Partly resolved issues:
2888 o : "Are OPTIONS
2889 and TRACE safe?"
2891 C.10. Since draft-ietf-httpbis-p2-semantics-08
2893 Closed issues:
2895 o : "Safe Methods
2896 vs Redirection" (we missed the introduction to the 3xx status
2897 codes when fixing this previously)
2899 C.11. Since draft-ietf-httpbis-p2-semantics-09
2901 Closed issues:
2903 o : "Fragment
2904 combination / precedence during redirects"
2906 Partly resolved issues:
2908 o : "Location
2909 header payload handling"
2911 o : "Term for the
2912 requested resource's URI"
2914 C.12. Since draft-ietf-httpbis-p2-semantics-10
2916 Closed issues:
2918 o : "Clarify
2919 'Requested Variant'"
2921 o : "Clarify
2922 entity / representation / variant terminology"
2924 o : "Methods and
2925 Caching"
2927 o : "OPTIONS vs
2928 Max-Forwards"
2930 o : "Status codes
2931 and caching"
2933 o : "consider
2934 removing the 'changes from 2068' sections"
2936 C.13. Since draft-ietf-httpbis-p2-semantics-11
2938 Closed issues:
2940 o :
2941 "Considerations for new status codes"
2943 o :
2944 "Considerations for new methods"
2946 o : "User-Agent
2947 guidelines" (relating to the 'User-Agent' header field)
2949 C.14. Since draft-ietf-httpbis-p2-semantics-12
2951 Closed issues:
2953 o : "Fragment
2954 combination / precedence during redirects" (added warning about
2955 having a fragid on the redirect may cause inconvenience in some
2956 cases)
2958 o : "Content-* vs.
2959 PUT"
2961 o : "205 Bodies"
2963 o : "Understanding
2964 Content-* on non-PUT requests"
2966 o : "Content-*"
2968 o : "Header type
2969 defaulting"
2971 o : "PUT - 'store
2972 under' vs 'store at'"
2974 o : "duplicate
2975 ABNF for Reason-Phrase"
2977 o : "Note special
2978 status of Content-* prefix in header registration procedures"
2980 o : "Max-Forwards
2981 vs extension methods"
2983 o : "What is the
2984 value space of HTTP status codes?" (actually fixed in
2985 draft-ietf-httpbis-p2-semantics-11)
2987 o : "Header
2988 Classification"
2990 o : "PUT side
2991 effect: invalidation or just stale?"
2993 o : "proxies not
2994 supporting certain methods"
2996 o : "Migrate
2997 CONNECT from RFC2817 to p2"
2999 o : "Migrate
3000 Upgrade details from RFC2817"
3002 o : "clarify PUT
3003 semantics'"
3005 o : "duplicate
3006 ABNF for 'Method'"
3008 o : "untangle
3009 ABNFs for header fields"
3011 C.15. Since draft-ietf-httpbis-p2-semantics-13
3013 Closed issues:
3015 o : "untangle
3016 ABNFs for header fields"
3018 o : "message-body
3019 in CONNECT request"
3021 C.16. Since draft-ietf-httpbis-p2-semantics-14
3023 Closed issues:
3025 o : "Clarify
3026 status code for rate limiting"
3028 o : "clarify 403
3029 forbidden"
3031 o : "Clarify 203
3032 Non-Authoritative Information"
3034 o : "update
3035 default reason phrase for 413"
3037 C.17. Since draft-ietf-httpbis-p2-semantics-15
3039 Closed issues:
3041 o : "Strength of
3042 requirements on Accept re: 406"
3044 o : "400 response
3045 isn't generic"
3047 C.18. Since draft-ietf-httpbis-p2-semantics-16
3049 Closed issues:
3051 o : "Redirects and
3052 non-GET methods"
3054 o : "Document
3055 HTTP's error-handling philosophy"
3057 o :
3058 "Considerations for new headers"
3060 o : "clarify 303
3061 redirect on HEAD"
3063 Index
3065 1
3066 100 Continue (status code) 26
3067 101 Switching Protocols (status code) 26
3069 2
3070 200 OK (status code) 27
3071 201 Created (status code) 27
3072 202 Accepted (status code) 28
3073 203 Non-Authoritative Information (status code) 28
3074 204 No Content (status code) 28
3075 205 Reset Content (status code) 29
3076 206 Partial Content (status code) 29
3078 3
3079 300 Multiple Choices (status code) 30
3080 301 Moved Permanently (status code) 31
3081 302 Found (status code) 32
3082 303 See Other (status code) 32
3083 304 Not Modified (status code) 33
3084 305 Use Proxy (status code) 33
3085 306 (Unused) (status code) 33
3086 307 Temporary Redirect (status code) 33
3088 4
3089 400 Bad Request (status code) 34
3090 401 Unauthorized (status code) 34
3091 402 Payment Required (status code) 34
3092 403 Forbidden (status code) 34
3093 404 Not Found (status code) 35
3094 405 Method Not Allowed (status code) 35
3095 406 Not Acceptable (status code) 35
3096 407 Proxy Authentication Required (status code) 35
3097 408 Request Timeout (status code) 36
3098 409 Conflict (status code) 36
3099 410 Gone (status code) 36
3100 411 Length Required (status code) 37
3101 412 Precondition Failed (status code) 37
3102 413 Request Representation Too Large (status code) 37
3103 414 URI Too Long (status code) 37
3104 415 Unsupported Media Type (status code) 37
3105 416 Requested Range Not Satisfiable (status code) 38
3106 417 Expectation Failed (status code) 38
3107 426 Upgrade Required (status code) 38
3109 5
3110 500 Internal Server Error (status code) 38
3111 501 Not Implemented (status code) 39
3112 502 Bad Gateway (status code) 39
3113 503 Service Unavailable (status code) 39
3114 504 Gateway Timeout (status code) 39
3115 505 HTTP Version Not Supported (status code) 39
3117 A
3118 Allow header field 42
3120 C
3121 CONNECT method 24
3123 D
3124 Date header field 43
3125 DELETE method 23
3127 E
3128 Expect header field 44
3130 F
3131 From header field 44
3133 G
3134 GET method 19
3135 Grammar
3136 Allow 42
3137 asctime-date 42
3138 Date 43
3139 date1 41
3140 day 41
3141 day-name 41
3142 day-name-l 41
3143 delta-seconds 47
3144 Expect 44
3145 expect-params 44
3146 expectation 44
3147 expectation-extension 44
3148 extension-code 12
3149 From 45
3150 GMT 41
3151 hour 41
3152 HTTP-date 40
3153 Location 45
3154 Max-Forwards 46
3155 Method 7
3156 minute 41
3157 month 41
3158 obs-date 41
3159 Reason-Phrase 12
3160 Referer 47
3161 Retry-After 47
3162 rfc850-date 42
3163 rfc1123-date 41
3164 second 41
3165 Server 48
3166 Status-Code 12
3167 time-of-day 41
3168 User-Agent 49
3169 year 41
3171 H
3172 HEAD method 19
3173 Header Fields
3174 Allow 42
3175 Date 43
3176 Expect 44
3177 From 44
3178 Location 45
3179 Max-Forwards 46
3180 Referer 47
3181 Retry-After 47
3182 Server 48
3183 User-Agent 48
3185 I
3186 Idempotent Methods 17
3188 L
3189 Location header field 45
3191 M
3192 Max-Forwards header field 46
3193 Methods
3194 CONNECT 24
3195 DELETE 23
3196 GET 19
3197 HEAD 19
3198 OPTIONS 18
3199 POST 20
3200 PUT 21
3201 TRACE 23
3203 O
3204 OPTIONS method 18
3206 P
3207 POST method 20
3208 PUT method 21
3210 R
3211 Referer header field 47
3212 Retry-After header field 47
3214 S
3215 Safe Methods 17
3216 Server header field 48
3217 Status Codes
3218 100 Continue 26
3219 101 Switching Protocols 26
3220 200 OK 27
3221 201 Created 27
3222 202 Accepted 28
3223 203 Non-Authoritative Information 28
3224 204 No Content 28
3225 205 Reset Content 29
3226 206 Partial Content 29
3227 300 Multiple Choices 30
3228 301 Moved Permanently 31
3229 302 Found 32
3230 303 See Other 32
3231 304 Not Modified 33
3232 305 Use Proxy 33
3233 306 (Unused) 33
3234 307 Temporary Redirect 33
3235 400 Bad Request 34
3236 401 Unauthorized 34
3237 402 Payment Required 34
3238 403 Forbidden 34
3239 404 Not Found 35
3240 405 Method Not Allowed 35
3241 406 Not Acceptable 35
3242 407 Proxy Authentication Required 35
3243 408 Request Timeout 36
3244 409 Conflict 36
3245 410 Gone 36
3246 411 Length Required 37
3247 412 Precondition Failed 37
3248 413 Request Representation Too Large 37
3249 414 URI Too Long 37
3250 415 Unsupported Media Type 37
3251 416 Requested Range Not Satisfiable 38
3252 417 Expectation Failed 38
3253 426 Upgrade Required 38
3254 500 Internal Server Error 38
3255 501 Not Implemented 39
3256 502 Bad Gateway 39
3257 503 Service Unavailable 39
3258 504 Gateway Timeout 39
3259 505 HTTP Version Not Supported 39
3261 T
3262 TRACE method 23
3264 U
3265 User-Agent header field 48
3267 Authors' Addresses
3269 Roy T. Fielding (editor)
3270 Adobe Systems Incorporated
3271 345 Park Ave
3272 San Jose, CA 95110
3273 USA
3275 EMail: fielding@gbiv.com
3276 URI: http://roy.gbiv.com/
3278 Jim Gettys
3279 Alcatel-Lucent Bell Labs
3280 21 Oak Knoll Road
3281 Carlisle, MA 01741
3282 USA
3284 EMail: jg@freedesktop.org
3285 URI: http://gettys.wordpress.com/
3287 Jeffrey C. Mogul
3288 Hewlett-Packard Company
3289 HP Labs, Large Scale Systems Group
3290 1501 Page Mill Road, MS 1177
3291 Palo Alto, CA 94304
3292 USA
3294 EMail: JeffMogul@acm.org
3296 Henrik Frystyk Nielsen
3297 Microsoft Corporation
3298 1 Microsoft Way
3299 Redmond, WA 98052
3300 USA
3302 EMail: henrikn@microsoft.com
3303 Larry Masinter
3304 Adobe Systems Incorporated
3305 345 Park Ave
3306 San Jose, CA 95110
3307 USA
3309 EMail: LMM@acm.org
3310 URI: http://larry.masinter.net/
3312 Paul J. Leach
3313 Microsoft Corporation
3314 1 Microsoft Way
3315 Redmond, WA 98052
3317 EMail: paulle@microsoft.com
3319 Tim Berners-Lee
3320 World Wide Web Consortium
3321 MIT Computer Science and Artificial Intelligence Laboratory
3322 The Stata Center, Building 32
3323 32 Vassar Street
3324 Cambridge, MA 02139
3325 USA
3327 EMail: timbl@w3.org
3328 URI: http://www.w3.org/People/Berners-Lee/
3330 Yves Lafon (editor)
3331 World Wide Web Consortium
3332 W3C / ERCIM
3333 2004, rte des Lucioles
3334 Sophia-Antipolis, AM 06902
3335 France
3337 EMail: ylafon@w3.org
3338 URI: http://www.raubacapeu.net/people/yves/
3339 Julian F. Reschke (editor)
3340 greenbytes GmbH
3341 Hafenweg 16
3342 Muenster, NW 48155
3343 Germany
3345 Phone: +49 251 2807760
3346 Fax: +49 251 2807761
3347 EMail: julian.reschke@greenbytes.de
3348 URI: http://greenbytes.de/tech/webdav/