idnits 2.17.1
draft-ietf-httpbis-p2-semantics-19.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 (March 12, 2012) is 4428 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-19
== Outdated reference: A later version (-20) exists of
draft-ietf-httpbis-p3-payload-19
== Outdated reference: A later version (-26) exists of
draft-ietf-httpbis-p4-conditional-19
== Outdated reference: A later version (-26) exists of
draft-ietf-httpbis-p5-range-19
== Outdated reference: A later version (-26) exists of
draft-ietf-httpbis-p6-cache-19
== Outdated reference: A later version (-26) exists of
draft-ietf-httpbis-p7-auth-19
-- 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) Y. Lafon, Ed.
5 Updates: 2817 (if approved) W3C
6 Intended status: Standards Track J. Reschke, Ed.
7 Expires: September 13, 2012 greenbytes
8 March 12, 2012
10 HTTP/1.1, part 2: Message Semantics
11 draft-ietf-httpbis-p2-semantics-19
13 Abstract
15 The Hypertext Transfer Protocol (HTTP) is an application-level
16 protocol for distributed, collaborative, hypertext information
17 systems. HTTP has been in use by the World Wide Web global
18 information initiative since 1990. This document is Part 2 of the
19 seven-part specification that defines the protocol referred to as
20 "HTTP/1.1" and, taken together, obsoletes RFC 2616.
22 Part 2 defines the semantics of HTTP messages as expressed by request
23 methods, request header fields, response status codes, and response
24 header fields.
26 Editorial Note (To be removed by RFC Editor)
28 Discussion of this draft should take place on the HTTPBIS working
29 group mailing list (ietf-http-wg@w3.org), which is archived at
30 .
32 The current issues list is at
33 and related
34 documents (including fancy diffs) can be found at
35 .
37 The changes in this draft are summarized in Appendix C.20.
39 Status of This Memo
41 This Internet-Draft is submitted in full conformance with the
42 provisions of BCP 78 and BCP 79.
44 Internet-Drafts are working documents of the Internet Engineering
45 Task Force (IETF). Note that other groups may also distribute
46 working documents as Internet-Drafts. The list of current Internet-
47 Drafts is at http://datatracker.ietf.org/drafts/current/.
49 Internet-Drafts are draft documents valid for a maximum of six months
50 and may be updated, replaced, or obsoleted by other documents at any
51 time. It is inappropriate to use Internet-Drafts as reference
52 material or to cite them other than as "work in progress."
54 This Internet-Draft will expire on September 13, 2012.
56 Copyright Notice
58 Copyright (c) 2012 IETF Trust and the persons identified as the
59 document authors. All rights reserved.
61 This document is subject to BCP 78 and the IETF Trust's Legal
62 Provisions Relating to IETF Documents
63 (http://trustee.ietf.org/license-info) in effect on the date of
64 publication of this document. Please review these documents
65 carefully, as they describe your rights and restrictions with respect
66 to this document. Code Components extracted from this document must
67 include Simplified BSD License text as described in Section 4.e of
68 the Trust Legal Provisions and are provided without warranty as
69 described in the Simplified BSD License.
71 This document may contain material from IETF Documents or IETF
72 Contributions published or made publicly available before November
73 10, 2008. The person(s) controlling the copyright in some of this
74 material may not have granted the IETF Trust the right to allow
75 modifications of such material outside the IETF Standards Process.
76 Without obtaining an adequate license from the person(s) controlling
77 the copyright in such materials, this document may not be modified
78 outside the IETF Standards Process, and derivative works of it may
79 not be created outside the IETF Standards Process, except to format
80 it for publication as an RFC or to translate it into languages other
81 than English.
83 Table of Contents
85 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
86 1.1. Conformance and Error Handling . . . . . . . . . . . . . 6
87 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7
88 1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 7
89 1.2.2. ABNF Rules defined in other Parts of the
90 Specification . . . . . . . . . . . . . . . . . . . . 7
91 2. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
92 2.1. Overview of Methods . . . . . . . . . . . . . . . . . . . 8
93 2.2. Method Registry . . . . . . . . . . . . . . . . . . . . . 8
94 2.2.1. Considerations for New Methods . . . . . . . . . . . . 9
95 3. Header Fields . . . . . . . . . . . . . . . . . . . . . . . . 9
96 3.1. Considerations for Creating Header Fields . . . . . . . . 9
97 3.2. Request Header Fields . . . . . . . . . . . . . . . . . . 11
98 3.3. Response Header Fields . . . . . . . . . . . . . . . . . 12
99 4. Status Code and Reason Phrase . . . . . . . . . . . . . . . . 12
100 4.1. Overview of Status Codes . . . . . . . . . . . . . . . . 13
101 4.2. Status Code Registry . . . . . . . . . . . . . . . . . . 15
102 4.2.1. Considerations for New Status Codes . . . . . . . . . 15
103 5. Representation . . . . . . . . . . . . . . . . . . . . . . . . 16
104 5.1. Identifying the Resource Associated with a
105 Representation . . . . . . . . . . . . . . . . . . . . . 16
106 6. Method Definitions . . . . . . . . . . . . . . . . . . . . . . 17
107 6.1. Safe and Idempotent Methods . . . . . . . . . . . . . . . 17
108 6.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . 17
109 6.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . . 17
110 6.2. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 18
111 6.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
112 6.4. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . 19
113 6.5. POST . . . . . . . . . . . . . . . . . . . . . . . . . . 20
114 6.6. PUT . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
115 6.7. DELETE . . . . . . . . . . . . . . . . . . . . . . . . . 23
116 6.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . . . 23
117 6.9. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . . 24
118 7. Status Code Definitions . . . . . . . . . . . . . . . . . . . 25
119 7.1. Informational 1xx . . . . . . . . . . . . . . . . . . . . 26
120 7.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 26
121 7.1.2. 101 Switching Protocols . . . . . . . . . . . . . . . 27
122 7.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . 27
123 7.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 27
124 7.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 27
125 7.2.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 28
126 7.2.4. 203 Non-Authoritative Information . . . . . . . . . . 28
127 7.2.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 28
128 7.2.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 29
129 7.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 29
130 7.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 31
131 7.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 31
132 7.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 32
133 7.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 32
134 7.3.5. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 33
135 7.3.6. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 33
136 7.3.7. 307 Temporary Redirect . . . . . . . . . . . . . . . . 33
137 7.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 33
138 7.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 33
139 7.4.2. 402 Payment Required . . . . . . . . . . . . . . . . . 33
140 7.4.3. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 33
141 7.4.4. 404 Not Found . . . . . . . . . . . . . . . . . . . . 34
142 7.4.5. 405 Method Not Allowed . . . . . . . . . . . . . . . . 34
143 7.4.6. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 34
144 7.4.7. 408 Request Timeout . . . . . . . . . . . . . . . . . 35
145 7.4.8. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 35
146 7.4.9. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 35
147 7.4.10. 411 Length Required . . . . . . . . . . . . . . . . . 36
148 7.4.11. 413 Request Representation Too Large . . . . . . . . . 36
149 7.4.12. 414 URI Too Long . . . . . . . . . . . . . . . . . . . 36
150 7.4.13. 415 Unsupported Media Type . . . . . . . . . . . . . . 36
151 7.4.14. 417 Expectation Failed . . . . . . . . . . . . . . . . 36
152 7.4.15. 426 Upgrade Required . . . . . . . . . . . . . . . . . 37
153 7.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 37
154 7.5.1. 500 Internal Server Error . . . . . . . . . . . . . . 37
155 7.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 37
156 7.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 37
157 7.5.4. 503 Service Unavailable . . . . . . . . . . . . . . . 38
158 7.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 38
159 7.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 38
160 8. Date/Time Formats . . . . . . . . . . . . . . . . . . . . . . 38
161 9. Product Tokens . . . . . . . . . . . . . . . . . . . . . . . . 41
162 10. Header Field Definitions . . . . . . . . . . . . . . . . . . . 42
163 10.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . . . 42
164 10.2. Date . . . . . . . . . . . . . . . . . . . . . . . . . . 42
165 10.3. Expect . . . . . . . . . . . . . . . . . . . . . . . . . 43
166 10.4. From . . . . . . . . . . . . . . . . . . . . . . . . . . 44
167 10.5. Location . . . . . . . . . . . . . . . . . . . . . . . . 45
168 10.6. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . 46
169 10.7. Referer . . . . . . . . . . . . . . . . . . . . . . . . . 46
170 10.8. Retry-After . . . . . . . . . . . . . . . . . . . . . . . 47
171 10.9. Server . . . . . . . . . . . . . . . . . . . . . . . . . 47
172 10.10. User-Agent . . . . . . . . . . . . . . . . . . . . . . . 48
173 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49
174 11.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 49
175 11.2. Status Code Registry . . . . . . . . . . . . . . . . . . 49
176 11.3. Header Field Registration . . . . . . . . . . . . . . . . 50
177 12. Security Considerations . . . . . . . . . . . . . . . . . . . 51
178 12.1. Transfer of Sensitive Information . . . . . . . . . . . . 51
179 12.2. Encoding Sensitive Information in URIs . . . . . . . . . 52
180 12.3. Location Header Fields: Spoofing and Information
181 Leakage . . . . . . . . . . . . . . . . . . . . . . . . . 53
182 12.4. Security Considerations for CONNECT . . . . . . . . . . . 53
183 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53
184 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53
185 14.1. Normative References . . . . . . . . . . . . . . . . . . 53
186 14.2. Informative References . . . . . . . . . . . . . . . . . 54
187 Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 55
188 Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 56
189 Appendix C. Change Log (to be removed by RFC Editor before
190 publication) . . . . . . . . . . . . . . . . . . . . 59
191 C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . 59
192 C.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . 59
193 C.3. Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . 60
194 C.4. Since draft-ietf-httpbis-p2-semantics-02 . . . . . . . . 60
195 C.5. Since draft-ietf-httpbis-p2-semantics-03 . . . . . . . . 61
196 C.6. Since draft-ietf-httpbis-p2-semantics-04 . . . . . . . . 61
197 C.7. Since draft-ietf-httpbis-p2-semantics-05 . . . . . . . . 62
198 C.8. Since draft-ietf-httpbis-p2-semantics-06 . . . . . . . . 62
199 C.9. Since draft-ietf-httpbis-p2-semantics-07 . . . . . . . . 62
200 C.10. Since draft-ietf-httpbis-p2-semantics-08 . . . . . . . . 63
201 C.11. Since draft-ietf-httpbis-p2-semantics-09 . . . . . . . . 63
202 C.12. Since draft-ietf-httpbis-p2-semantics-10 . . . . . . . . 63
203 C.13. Since draft-ietf-httpbis-p2-semantics-11 . . . . . . . . 64
204 C.14. Since draft-ietf-httpbis-p2-semantics-12 . . . . . . . . 64
205 C.15. Since draft-ietf-httpbis-p2-semantics-13 . . . . . . . . 66
206 C.16. Since draft-ietf-httpbis-p2-semantics-14 . . . . . . . . 66
207 C.17. Since draft-ietf-httpbis-p2-semantics-15 . . . . . . . . 66
208 C.18. Since draft-ietf-httpbis-p2-semantics-16 . . . . . . . . 66
209 C.19. Since draft-ietf-httpbis-p2-semantics-17 . . . . . . . . 67
210 C.20. Since draft-ietf-httpbis-p2-semantics-18 . . . . . . . . 67
211 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
213 1. Introduction
215 This document defines HTTP/1.1 request and response semantics. Each
216 HTTP message, as defined in [Part1], is in the form of either a
217 request or a response. An HTTP server listens on a connection for
218 HTTP requests and responds to each request, in the order received on
219 that connection, with one or more HTTP response messages. This
220 document defines the commonly agreed upon semantics of the HTTP
221 uniform interface, the intentions defined by each request method, and
222 the various response messages that might be expected as a result of
223 applying that method to the target resource.
225 This document is currently disorganized in order to minimize the
226 changes between drafts and enable reviewers to see the smaller errata
227 changes. A future draft will reorganize the sections to better
228 reflect the content. In particular, the sections will be ordered
229 according to the typical processing of an HTTP request message (after
230 message parsing): resource mapping, methods, request modifying header
231 fields, response status, status modifying header fields, and resource
232 metadata. The current mess reflects how widely dispersed these
233 topics and associated requirements had become in [RFC2616].
235 1.1. Conformance and Error Handling
237 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
238 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
239 document are to be interpreted as described in [RFC2119].
241 This document defines conformance criteria for several roles in HTTP
242 communication, including Senders, Recipients, Clients, Servers, User-
243 Agents, Origin Servers, Intermediaries, Proxies and Gateways. See
244 Section 2 of [Part1] for definitions of these terms.
246 An implementation is considered conformant if it complies with all of
247 the requirements associated with its role(s). Note that SHOULD-level
248 requirements are relevant here, unless one of the documented
249 exceptions is applicable.
251 This document also uses ABNF to define valid protocol elements
252 (Section 1.2). In addition to the prose requirements placed upon
253 them, Senders MUST NOT generate protocol elements that are invalid.
255 Unless noted otherwise, Recipients MAY take steps to recover a usable
256 protocol element from an invalid construct. However, HTTP does not
257 define specific error handling mechanisms, except in cases where it
258 has direct impact on security. This is because different uses of the
259 protocol require different error handling strategies; for example, a
260 Web browser may wish to transparently recover from a response where
261 the Location header field doesn't parse according to the ABNF,
262 whereby in a systems control protocol using HTTP, this type of error
263 recovery could lead to dangerous consequences.
265 1.2. Syntax Notation
267 This specification uses the Augmented Backus-Naur Form (ABNF)
268 notation of [RFC5234] with the list rule extension defined in Section
269 1.2 of [Part1]. Appendix B shows the collected ABNF with the list
270 rule expanded.
272 The following core rules are included by reference, as defined in
273 [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
274 (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
275 HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line
276 feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any
277 visible US-ASCII character).
279 1.2.1. Core Rules
281 The core rules below are defined in [Part1]:
283 BWS =
284 OWS =
285 RWS =
286 obs-text =
287 quoted-string =
288 token =
290 1.2.2. ABNF Rules defined in other Parts of the Specification
292 The ABNF rules below are defined in other parts:
294 absolute-URI =
295 comment =
296 partial-URI =
297 URI-reference =
299 2. Method
301 The method token indicates the request method to be performed on the
302 target resource (Section 5.5 of [Part1]). The method is case-
303 sensitive.
305 method = token
307 The list of methods allowed by a resource can be specified in an
308 Allow header field (Section 10.1). The status code of the response
309 always notifies the client whether a method is currently allowed on a
310 resource, since the set of allowed methods can change dynamically.
311 An origin server SHOULD respond with the status code 405 (Method Not
312 Allowed) if the method is known by the origin server but not allowed
313 for the resource, and 501 (Not Implemented) if the method is
314 unrecognized or not implemented by the origin server. The methods
315 GET and HEAD MUST be supported by all general-purpose servers. All
316 other methods are OPTIONAL; however, if the above methods are
317 implemented, they MUST be implemented with the same semantics as
318 those specified in Section 6.
320 2.1. Overview of Methods
322 The methods listed below are defined in Section 6.
324 +-------------+---------------+
325 | Method Name | Defined in... |
326 +-------------+---------------+
327 | OPTIONS | Section 6.2 |
328 | GET | Section 6.3 |
329 | HEAD | Section 6.4 |
330 | POST | Section 6.5 |
331 | PUT | Section 6.6 |
332 | DELETE | Section 6.7 |
333 | TRACE | Section 6.8 |
334 | CONNECT | Section 6.9 |
335 +-------------+---------------+
337 Note that this list is not exhaustive -- it does not include request
338 methods defined in other specifications.
340 2.2. Method Registry
342 The HTTP Method Registry defines the name space for the method token
343 in the Request line of an HTTP request.
345 Registrations MUST include the following fields:
347 o Method Name (see Section 2)
349 o Safe ("yes" or "no", see Section 6.1.1)
351 o Pointer to specification text
353 Values to be added to this name space require IETF Review (see
354 [RFC5226], Section 4.1).
356 The registry itself is maintained at
357 .
359 2.2.1. Considerations for New Methods
361 When it is necessary to express new semantics for a HTTP request that
362 aren't specific to a single application or media type, and currently
363 defined methods are inadequate, it may be appropriate to register a
364 new method.
366 HTTP methods are generic; that is, they are potentially applicable to
367 any resource, not just one particular media type, "type" of resource,
368 or application. As such, it is preferred that new HTTP methods be
369 registered in a document that isn't specific to a single application,
370 so that this is clear.
372 Due to the parsing rules defined in Section 3.3 of [Part1],
373 definitions of HTTP methods cannot prohibit the presence of a message
374 body on either the request or the response message (with responses to
375 HEAD requests being the single exception). Definitions of new
376 methods cannot change this rule, but they can specify that only zero-
377 length bodies (as opposed to absent bodies) are allowed.
379 New method definitions need to indicate whether they are safe
380 (Section 6.1.1), what semantics (if any) the request body has, and
381 whether they are idempotent (Section 6.1.2). They also need to state
382 whether they can be cached ([Part6]); in particular what conditions a
383 cache may store the response, and under what conditions such a stored
384 response may be used to satisfy a subsequent request.
386 3. Header Fields
388 Header fields are key value pairs that can be used to communicate
389 data about the message, its payload, the target resource, or about
390 the connection itself (i.e., control data). See Section 3.2 of
391 [Part1] for a general definition of their syntax.
393 3.1. Considerations for Creating Header Fields
395 New header fields are registered using the procedures described in
396 [RFC3864].
398 The requirements for header field names are defined in Section 4.1 of
399 [RFC3864]. Authors of specifications defining new fields are advised
400 to keep the name as short as practical, and not to prefix them with
401 "X-" if they are to be registered (either immediately or in the
402 future).
404 New header field values typically have their syntax defined using
405 ABNF ([RFC5234]), using the extension defined in Section 3.2.5 of
406 [Part1] as necessary, and are usually constrained to the range of
407 ASCII characters. Header fields needing a greater range of
408 characters can use an encoding such as the one defined in [RFC5987].
410 Because commas (",") are used as a generic delimiter between field-
411 values, they need to be treated with care if they are allowed in the
412 field-value's payload. Typically, components that might contain a
413 comma are protected with double-quotes using the quoted-string ABNF
414 production (Section 3.2.4 of [Part1]).
416 For example, a textual date and a URI (either of which might contain
417 a comma) could be safely carried in field-values like these:
419 Example-URI-Field: "http://example.com/a.html,foo",
420 "http://without-a-comma.example.com/"
421 Example-Date-Field: "Sat, 04 May 1996", "Wed, 14 Sep 2005"
423 Note that double quote delimiters almost always are used with the
424 quoted-string production; using a different syntax inside double
425 quotes will likely cause unnecessary confusion.
427 Many header fields use a format including (case-insensitively) named
428 parameters (for instance, Content-Type, defined in Section 6.8 of
429 [Part3]). Allowing both unquoted (token) and quoted (quoted-string)
430 syntax for the parameter value enables recipients to use existing
431 parser components. When allowing both forms, the meaning of a
432 parameter value ought to be independent of the syntax used for it
433 (for an example, see the notes on parameter handling for media types
434 in Section 2.3 of [Part3]).
436 Authors of specifications defining new header fields are advised to
437 consider documenting:
439 o Whether the field is a single value, or whether it can be a list
440 (delimited by commas; see Section 3.2 of [Part1]).
442 If it does not use the list syntax, document how to treat messages
443 where the header field occurs multiple times (a sensible default
444 would be to ignore the header field, but this might not always be
445 the right choice).
447 Note that intermediaries and software libraries might combine
448 multiple header field instances into a single one, despite the
449 header field not allowing this. A robust format enables
450 recipients to discover these situations (good example: "Content-
451 Type", as the comma can only appear inside quoted strings; bad
452 example: "Location", as a comma can occur inside a URI).
454 o Under what conditions the header field can be used; e.g., only in
455 responses or requests, in all messages, only on responses to a
456 particular request method.
458 o Whether it is appropriate to list the field-name in the Connection
459 header (i.e., if the header is to be hop-by-hop, see Section 6.1
460 of [Part1]).
462 o Under what conditions intermediaries are allowed to modify the
463 header field's value, insert or delete it.
465 o How the header might interact with caching (see [Part6]).
467 o Whether the header field is useful or allowable in trailers (see
468 Section 4.1 of [Part1]).
470 o Whether the header field should be preserved across redirects.
472 3.2. Request Header Fields
474 The request header fields allow the client to pass additional
475 information about the request, and about the client itself, to the
476 server. These fields act as request modifiers, with semantics
477 equivalent to the parameters on a programming language method
478 invocation.
480 +---------------------+------------------------+
481 | Header Field Name | Defined in... |
482 +---------------------+------------------------+
483 | Accept | Section 6.1 of [Part3] |
484 | Accept-Charset | Section 6.2 of [Part3] |
485 | Accept-Encoding | Section 6.3 of [Part3] |
486 | Accept-Language | Section 6.4 of [Part3] |
487 | Authorization | Section 4.1 of [Part7] |
488 | Expect | Section 10.3 |
489 | From | Section 10.4 |
490 | Host | Section 5.4 of [Part1] |
491 | If-Match | Section 3.1 of [Part4] |
492 | If-Modified-Since | Section 3.3 of [Part4] |
493 | If-None-Match | Section 3.2 of [Part4] |
494 | If-Range | Section 5.3 of [Part5] |
495 | If-Unmodified-Since | Section 3.4 of [Part4] |
496 | Max-Forwards | Section 10.6 |
497 | Proxy-Authorization | Section 4.3 of [Part7] |
498 | Range | Section 5.4 of [Part5] |
499 | Referer | Section 10.7 |
500 | TE | Section 4.3 of [Part1] |
501 | User-Agent | Section 10.10 |
502 +---------------------+------------------------+
504 3.3. Response Header Fields
506 The response header fields allow the server to pass additional
507 information about the response which cannot be placed in the status-
508 line. These header fields give information about the server and
509 about further access to the target resource (Section 5.5 of [Part1]).
511 +--------------------+------------------------+
512 | Header Field Name | Defined in... |
513 +--------------------+------------------------+
514 | Accept-Ranges | Section 5.1 of [Part5] |
515 | Age | Section 3.1 of [Part6] |
516 | Allow | Section 10.1 |
517 | Date | Section 10.2 |
518 | ETag | Section 2.3 of [Part4] |
519 | Location | Section 10.5 |
520 | Proxy-Authenticate | Section 4.2 of [Part7] |
521 | Retry-After | Section 10.8 |
522 | Server | Section 10.9 |
523 | Vary | Section 3.5 of [Part6] |
524 | WWW-Authenticate | Section 4.4 of [Part7] |
525 +--------------------+------------------------+
527 4. Status Code and Reason Phrase
529 The status-code element is a 3-digit integer result code of the
530 attempt to understand and satisfy the request.
532 The reason-phrase is intended to give a short textual description of
533 the status-code and is intended for a human user. The client does
534 not need to examine or display the reason-phrase.
536 status-code = 3DIGIT
537 reason-phrase = *( HTAB / SP / VCHAR / obs-text )
539 HTTP status codes are extensible. HTTP applications are not required
540 to understand the meaning of all registered status codes, though such
541 understanding is obviously desirable. However, applications MUST
542 understand the class of any status code, as indicated by the first
543 digit, and treat any unrecognized response as being equivalent to the
544 x00 status code of that class, with the exception that an
545 unrecognized response MUST NOT be cached. For example, if an
546 unrecognized status code of 431 is received by the client, it can
547 safely assume that there was something wrong with its request and
548 treat the response as if it had received a 400 status code. In such
549 cases, user agents SHOULD present to the user the representation
550 enclosed with the response, since that representation is likely to
551 include human-readable information which will explain the unusual
552 status.
554 4.1. Overview of Status Codes
556 The status codes listed below are defined in Section 7 of this
557 specification, Section 4 of [Part4], Section 3 of [Part5], and
558 Section 3 of [Part7]. The reason phrases listed here are only
559 recommendations -- they can be replaced by local equivalents without
560 affecting the protocol.
562 +-------------+------------------------------+----------------------+
563 | status-code | reason-phrase | Defined in... |
564 +-------------+------------------------------+----------------------+
565 | 100 | Continue | Section 7.1.1 |
566 | 101 | Switching Protocols | Section 7.1.2 |
567 | 200 | OK | Section 7.2.1 |
568 | 201 | Created | Section 7.2.2 |
569 | 202 | Accepted | Section 7.2.3 |
570 | 203 | Non-Authoritative | Section 7.2.4 |
571 | | Information | |
572 | 204 | No Content | Section 7.2.5 |
573 | 205 | Reset Content | Section 7.2.6 |
574 | 206 | Partial Content | Section 3.1 of |
575 | | | [Part5] |
576 | 300 | Multiple Choices | Section 7.3.1 |
577 | 301 | Moved Permanently | Section 7.3.2 |
578 | 302 | Found | Section 7.3.3 |
579 | 303 | See Other | Section 7.3.4 |
580 | 304 | Not Modified | Section 4.1 of |
581 | | | [Part4] |
582 | 305 | Use Proxy | Section 7.3.5 |
583 | 307 | Temporary Redirect | Section 7.3.7 |
584 | 400 | Bad Request | Section 7.4.1 |
585 | 401 | Unauthorized | Section 3.1 of |
586 | | | [Part7] |
587 | 402 | Payment Required | Section 7.4.2 |
588 | 403 | Forbidden | Section 7.4.3 |
589 | 404 | Not Found | Section 7.4.4 |
590 | 405 | Method Not Allowed | Section 7.4.5 |
591 | 406 | Not Acceptable | Section 7.4.6 |
592 | 407 | Proxy Authentication | Section 3.2 of |
593 | | Required | [Part7] |
594 | 408 | Request Time-out | Section 7.4.7 |
595 | 409 | Conflict | Section 7.4.8 |
596 | 410 | Gone | Section 7.4.9 |
597 | 411 | Length Required | Section 7.4.10 |
598 | 412 | Precondition Failed | Section 4.2 of |
599 | | | [Part4] |
600 | 413 | Request Representation Too | Section 7.4.11 |
601 | | Large | |
602 | 414 | URI Too Long | Section 7.4.12 |
603 | 415 | Unsupported Media Type | Section 7.4.13 |
604 | 416 | Requested range not | Section 3.2 of |
605 | | satisfiable | [Part5] |
606 | 417 | Expectation Failed | Section 7.4.14 |
607 | 426 | Upgrade Required | Section 7.4.15 |
608 | 500 | Internal Server Error | Section 7.5.1 |
609 | 501 | Not Implemented | Section 7.5.2 |
610 | 502 | Bad Gateway | Section 7.5.3 |
611 | 503 | Service Unavailable | Section 7.5.4 |
612 | 504 | Gateway Time-out | Section 7.5.5 |
613 | 505 | HTTP Version not supported | Section 7.5.6 |
614 +-------------+------------------------------+----------------------+
616 Note that this list is not exhaustive -- it does not include
617 extension status codes defined in other specifications.
619 4.2. Status Code Registry
621 The HTTP Status Code Registry defines the name space for the status-
622 code token in the status-line of an HTTP response.
624 Values to be added to this name space require IETF Review (see
625 [RFC5226], Section 4.1).
627 The registry itself is maintained at
628 .
630 4.2.1. Considerations for New Status Codes
632 When it is necessary to express new semantics for a HTTP response
633 that aren't specific to a single application or media type, and
634 currently defined status codes are inadequate, a new status code can
635 be registered.
637 HTTP status codes are generic; that is, they are potentially
638 applicable to any resource, not just one particular media type,
639 "type" of resource, or application. As such, it is preferred that
640 new HTTP status codes be registered in a document that isn't specific
641 to a single application, so that this is clear.
643 Definitions of new HTTP status codes typically explain the request
644 conditions that produce a response containing the status code (e.g.,
645 combinations of request headers and/or method(s)), along with any
646 interactions with response headers (e.g., those that are required,
647 those that modify the semantics of the response).
649 New HTTP status codes are required to fall under one of the
650 categories defined in Section 7. To allow existing parsers to
651 properly handle them, new status codes cannot disallow a response
652 body, although they can mandate a zero-length response body. They
653 can require the presence of one or more particular HTTP response
654 header(s).
656 Likewise, their definitions can specify that caches are allowed to
657 use heuristics to determine their freshness (see [Part6]; by default,
658 it is not allowed), and can define how to determine the resource
659 which they carry a representation for (see Section 5.1; by default,
660 it is anonymous).
662 5. Representation
664 Request and Response messages MAY transfer a representation if not
665 otherwise restricted by the request method or response status code.
666 A representation consists of metadata (representation header fields)
667 and data (representation body). When a complete or partial
668 representation is enclosed in an HTTP message, it is referred to as
669 the payload of the message. HTTP representations are defined in
670 [Part3].
672 A representation body is only present in a message when a message
673 body is present, as described in Section 3.3 of [Part1]. The
674 representation body is obtained from the message body by decoding any
675 Transfer-Encoding that might have been applied to ensure safe and
676 proper transfer of the message.
678 5.1. Identifying the Resource Associated with a Representation
680 It is sometimes necessary to determine an identifier for the resource
681 associated with a representation.
683 An HTTP request representation, when present, is always associated
684 with an anonymous (i.e., unidentified) resource.
686 In the common case, an HTTP response is a representation of the
687 target resource (see Section 5.5 of [Part1]). However, this is not
688 always the case. To determine the URI of the resource a response is
689 associated with, the following rules are used (with the first
690 applicable one being selected):
692 1. If the response status code is 200 or 203 and the request method
693 was GET, the response payload is a representation of the target
694 resource.
696 2. If the response status code is 204, 206, or 304 and the request
697 method was GET or HEAD, the response payload is a partial
698 representation of the target resource.
700 3. If the response has a Content-Location header field, and that URI
701 is the same as the effective request URI, the response payload is
702 a representation of the target resource.
704 4. If the response has a Content-Location header field, and that URI
705 is not the same as the effective request URI, then the response
706 asserts that its payload is a representation of the resource
707 identified by the Content-Location URI. However, such an
708 assertion cannot be trusted unless it can be verified by other
709 means (not defined by HTTP).
711 5. Otherwise, the response is a representation of an anonymous
712 (i.e., unidentified) resource.
714 [[TODO-req-uri: The comparison function is going to have to be
715 defined somewhere, because we already need to compare URIs for things
716 like cache invalidation.]]
718 6. Method Definitions
720 The set of common request methods for HTTP/1.1 is defined below.
721 Although this set can be expanded, additional methods cannot be
722 assumed to share the same semantics for separately extended clients
723 and servers.
725 6.1. Safe and Idempotent Methods
727 6.1.1. Safe Methods
729 Implementors need to be aware that the software represents the user
730 in their interactions over the Internet, and need to allow the user
731 to be aware of any actions they take which might have an unexpected
732 significance to themselves or others.
734 In particular, the convention has been established that the GET,
735 HEAD, OPTIONS, and TRACE request methods SHOULD NOT have the
736 significance of taking an action other than retrieval. These request
737 methods ought to be considered "safe". This allows user agents to
738 represent other methods, such as POST, PUT and DELETE, in a special
739 way, so that the user is made aware of the fact that a possibly
740 unsafe action is being requested.
742 Naturally, it is not possible to ensure that the server does not
743 generate side-effects as a result of performing a GET request; in
744 fact, some dynamic resources consider that a feature. The important
745 distinction here is that the user did not request the side-effects,
746 so therefore cannot be held accountable for them.
748 6.1.2. Idempotent Methods
750 Request methods can also have the property of "idempotence" in that,
751 aside from error or expiration issues, the intended effect of
752 multiple identical requests is the same as for a single request.
753 PUT, DELETE, and all safe request methods are idempotent. It is
754 important to note that idempotence refers only to changes requested
755 by the client: a server is free to change its state due to multiple
756 requests for the purpose of tracking those requests, versioning of
757 results, etc.
759 6.2. OPTIONS
761 The OPTIONS method requests information about the communication
762 options available on the request/response chain identified by the
763 effective request URI. This method allows a client to determine the
764 options and/or requirements associated with a resource, or the
765 capabilities of a server, without implying a resource action or
766 initiating a resource retrieval.
768 Responses to the OPTIONS method are not cacheable.
770 If the OPTIONS request includes a message body (as indicated by the
771 presence of Content-Length or Transfer-Encoding), then the media type
772 MUST be indicated by a Content-Type field. Although this
773 specification does not define any use for such a body, future
774 extensions to HTTP might use the OPTIONS body to make more detailed
775 queries on the server.
777 If the request-target (Section 5.3 of [Part1]) is an asterisk ("*"),
778 the OPTIONS request is intended to apply to the server in general
779 rather than to a specific resource. Since a server's communication
780 options typically depend on the resource, the "*" request is only
781 useful as a "ping" or "no-op" type of method; it does nothing beyond
782 allowing the client to test the capabilities of the server. For
783 example, this can be used to test a proxy for HTTP/1.1 conformance
784 (or lack thereof).
786 If the request-target is not an asterisk, the OPTIONS request applies
787 only to the options that are available when communicating with that
788 resource.
790 A 200 response SHOULD include any header fields that indicate
791 optional features implemented by the server and applicable to that
792 resource (e.g., Allow), possibly including extensions not defined by
793 this specification. The response body, if any, SHOULD also include
794 information about the communication options. The format for such a
795 body is not defined by this specification, but might be defined by
796 future extensions to HTTP. Content negotiation MAY be used to select
797 the appropriate response format. If no response body is included,
798 the response MUST include a Content-Length field with a field-value
799 of "0".
801 The Max-Forwards header field MAY be used to target a specific proxy
802 in the request chain (see Section 10.6). If no Max-Forwards field is
803 present in the request, then the forwarded request MUST NOT include a
804 Max-Forwards field.
806 6.3. GET
808 The GET method requests transfer of a current representation of the
809 target resource.
811 If the target resource is a data-producing process, it is the
812 produced data which shall be returned as the representation in the
813 response and not the source text of the process, unless that text
814 happens to be the output of the process.
816 The semantics of the GET method change to a "conditional GET" if the
817 request message includes an If-Modified-Since, If-Unmodified-Since,
818 If-Match, If-None-Match, or If-Range header field. A conditional GET
819 requests that the representation be transferred only under the
820 circumstances described by the conditional header field(s). The
821 conditional GET request is intended to reduce unnecessary network
822 usage by allowing cached representations to be refreshed without
823 requiring multiple requests or transferring data already held by the
824 client.
826 The semantics of the GET method change to a "partial GET" if the
827 request message includes a Range header field. A partial GET
828 requests that only part of the representation be transferred, as
829 described in Section 5.4 of [Part5]. The partial GET request is
830 intended to reduce unnecessary network usage by allowing partially-
831 retrieved representations to be completed without transferring data
832 already held by the client.
834 Bodies on GET requests have no defined semantics. Note that sending
835 a body on a GET request might cause some existing implementations to
836 reject the request.
838 The response to a GET request is cacheable and MAY be used to satisfy
839 subsequent GET and HEAD requests (see [Part6]).
841 See Section 12.2 for security considerations when used for forms.
843 6.4. HEAD
845 The HEAD method is identical to GET except that the server MUST NOT
846 return a message body in the response. The metadata contained in the
847 HTTP header fields in response to a HEAD request SHOULD be identical
848 to the information sent in response to a GET request. This method
849 can be used for obtaining metadata about the representation implied
850 by the request without transferring the representation body. This
851 method is often used for testing hypertext links for validity,
852 accessibility, and recent modification.
854 The response to a HEAD request is cacheable and MAY be used to
855 satisfy a subsequent HEAD request. It also has potential side
856 effects on previously stored responses to GET; see Section 2.5 of
857 [Part6].
859 Bodies on HEAD requests have no defined semantics. Note that sending
860 a body on a HEAD request might cause some existing implementations to
861 reject the request.
863 6.5. POST
865 The POST method requests that the origin server accept the
866 representation enclosed in the request as data to be processed by the
867 target resource. POST is designed to allow a uniform method to cover
868 the following functions:
870 o Annotation of existing resources;
872 o Posting a message to a bulletin board, newsgroup, mailing list, or
873 similar group of articles;
875 o Providing a block of data, such as the result of submitting a
876 form, to a data-handling process;
878 o Extending a database through an append operation.
880 The actual function performed by the POST method is determined by the
881 server and is usually dependent on the effective request URI.
883 The action performed by the POST method might not result in a
884 resource that can be identified by a URI. In this case, either 200
885 (OK) or 204 (No Content) is the appropriate response status code,
886 depending on whether or not the response includes a representation
887 that describes the result.
889 If a resource has been created on the origin server, the response
890 SHOULD be 201 (Created) and contain a representation which describes
891 the status of the request and refers to the new resource, and a
892 Location header field (see Section 10.5).
894 Responses to POST requests are only cacheable when they include
895 explicit freshness information (see Section 2.3.1 of [Part6]). A
896 cached POST response with a Content-Location header field (see
897 Section 6.7 of [Part3]) whose value is the effective Request URI MAY
898 be used to satisfy subsequent GET and HEAD requests.
900 Note that POST caching is not widely implemented. However, the 303
901 (See Other) response can be used to direct the user agent to retrieve
902 a cacheable resource.
904 6.6. PUT
906 The PUT method requests that the state of the target resource be
907 created or replaced with the state defined by the representation
908 enclosed in the request message payload. A successful PUT of a given
909 representation would suggest that a subsequent GET on that same
910 target resource will result in an equivalent representation being
911 returned in a 200 (OK) response. However, there is no guarantee that
912 such a state change will be observable, since the target resource
913 might be acted upon by other user agents in parallel, or might be
914 subject to dynamic processing by the origin server, before any
915 subsequent GET is received. A successful response only implies that
916 the user agent's intent was achieved at the time of its processing by
917 the origin server.
919 If the target resource does not have a current representation and the
920 PUT successfully creates one, then the origin server MUST inform the
921 user agent by sending a 201 (Created) response. If the target
922 resource does have a current representation and that representation
923 is successfully modified in accordance with the state of the enclosed
924 representation, then either a 200 (OK) or 204 (No Content) response
925 SHOULD be sent to indicate successful completion of the request.
927 Unrecognized header fields SHOULD be ignored (i.e., not saved as part
928 of the resource state).
930 An origin server SHOULD verify that the PUT representation is
931 consistent with any constraints which the server has for the target
932 resource that cannot or will not be changed by the PUT. This is
933 particularly important when the origin server uses internal
934 configuration information related to the URI in order to set the
935 values for representation metadata on GET responses. When a PUT
936 representation is inconsistent with the target resource, the origin
937 server SHOULD either make them consistent, by transforming the
938 representation or changing the resource configuration, or respond
939 with an appropriate error message containing sufficient information
940 to explain why the representation is unsuitable. The 409 (Conflict)
941 or 415 (Unsupported Media Type) status codes are suggested, with the
942 latter being specific to constraints on Content-Type values.
944 For example, if the target resource is configured to always have a
945 Content-Type of "text/html" and the representation being PUT has a
946 Content-Type of "image/jpeg", then the origin server SHOULD do one
947 of: (a) reconfigure the target resource to reflect the new media
948 type; (b) transform the PUT representation to a format consistent
949 with that of the resource before saving it as the new resource state;
950 or, (c) reject the request with a 415 response indicating that the
951 target resource is limited to "text/html", perhaps including a link
952 to a different resource that would be a suitable target for the new
953 representation.
955 HTTP does not define exactly how a PUT method affects the state of an
956 origin server beyond what can be expressed by the intent of the user
957 agent request and the semantics of the origin server response. It
958 does not define what a resource might be, in any sense of that word,
959 beyond the interface provided via HTTP. It does not define how
960 resource state is "stored", nor how such storage might change as a
961 result of a change in resource state, nor how the origin server
962 translates resource state into representations. Generally speaking,
963 all implementation details behind the resource interface are
964 intentionally hidden by the server.
966 The fundamental difference between the POST and PUT methods is
967 highlighted by the different intent for the target resource. The
968 target resource in a POST request is intended to handle the enclosed
969 representation as a data-accepting process, such as for a gateway to
970 some other protocol or a document that accepts annotations. In
971 contrast, the target resource in a PUT request is intended to take
972 the enclosed representation as a new or replacement value. Hence,
973 the intent of PUT is idempotent and visible to intermediaries, even
974 though the exact effect is only known by the origin server.
976 Proper interpretation of a PUT request presumes that the user agent
977 knows what target resource is desired. A service that is intended to
978 select a proper URI on behalf of the client, after receiving a state-
979 changing request, SHOULD be implemented using the POST method rather
980 than PUT. If the origin server will not make the requested PUT state
981 change to the target resource and instead wishes to have it applied
982 to a different resource, such as when the resource has been moved to
983 a different URI, then the origin server MUST send a 301 (Moved
984 Permanently) response; the user agent MAY then make its own decision
985 regarding whether or not to redirect the request.
987 A PUT request applied to the target resource MAY have side-effects on
988 other resources. For example, an article might have a URI for
989 identifying "the current version" (a resource) which is separate from
990 the URIs identifying each particular version (different resources
991 that at one point shared the same state as the current version
992 resource). A successful PUT request on "the current version" URI
993 might therefore create a new version resource in addition to changing
994 the state of the target resource, and might also cause links to be
995 added between the related resources.
997 An origin server SHOULD reject any PUT request that contains a
998 Content-Range header field, since it might be misinterpreted as
999 partial content (or might be partial content that is being mistakenly
1000 PUT as a full representation). Partial content updates are possible
1001 by targeting a separately identified resource with state that
1002 overlaps a portion of the larger resource, or by using a different
1003 method that has been specifically defined for partial updates (for
1004 example, the PATCH method defined in [RFC5789]).
1006 Responses to the PUT method are not cacheable. If a PUT request
1007 passes through a cache that has one or more stored responses for the
1008 effective request URI, those stored responses will be invalidated
1009 (see Section 2.6 of [Part6]).
1011 6.7. DELETE
1013 The DELETE method requests that the origin server delete the target
1014 resource. This method MAY be overridden by human intervention (or
1015 other means) on the origin server. The client cannot be guaranteed
1016 that the operation has been carried out, even if the status code
1017 returned from the origin server indicates that the action has been
1018 completed successfully. However, the server SHOULD NOT indicate
1019 success unless, at the time the response is given, it intends to
1020 delete the resource or move it to an inaccessible location.
1022 A successful response SHOULD be 200 (OK) if the response includes an
1023 representation describing the status, 202 (Accepted) if the action
1024 has not yet been enacted, or 204 (No Content) if the action has been
1025 enacted but the response does not include a representation.
1027 Bodies on DELETE requests have no defined semantics. Note that
1028 sending a body on a DELETE request might cause some existing
1029 implementations to reject the request.
1031 Responses to the DELETE method are not cacheable. If a DELETE
1032 request passes through a cache that has one or more stored responses
1033 for the effective request URI, those stored responses will be
1034 invalidated (see Section 2.6 of [Part6]).
1036 6.8. TRACE
1038 The TRACE method requests a remote, application-layer loop-back of
1039 the request message. The final recipient of the request SHOULD
1040 reflect the message received back to the client as the message body
1041 of a 200 (OK) response. The final recipient is either the origin
1042 server or the first proxy to receive a Max-Forwards value of zero (0)
1043 in the request (see Section 10.6). A TRACE request MUST NOT include
1044 a message body.
1046 TRACE allows the client to see what is being received at the other
1047 end of the request chain and use that data for testing or diagnostic
1048 information. The value of the Via header field (Section 6.2 of
1049 [Part1]) is of particular interest, since it acts as a trace of the
1050 request chain. Use of the Max-Forwards header field allows the
1051 client to limit the length of the request chain, which is useful for
1052 testing a chain of proxies forwarding messages in an infinite loop.
1054 If the request is valid, the response SHOULD have a Content-Type of
1055 "message/http" (see Section 7.3.1 of [Part1]) and contain a message
1056 body that encloses a copy of the entire request message. Responses
1057 to the TRACE method are not cacheable.
1059 6.9. CONNECT
1061 The CONNECT method requests that the proxy establish a tunnel to the
1062 request-target and, if successful, thereafter restrict its behavior
1063 to blind forwarding of packets until the connection is closed.
1065 When using CONNECT, the request-target MUST use the authority form
1066 (Section 5.3 of [Part1]); i.e., the request-target consists of only
1067 the host name and port number of the tunnel destination, separated by
1068 a colon. For example,
1070 CONNECT server.example.com:80 HTTP/1.1
1071 Host: server.example.com:80
1073 Any successful (2xx) response to a CONNECT request indicates that the
1074 proxy has established a connection to the requested host and port,
1075 and has switched to tunneling the current connection to that server
1076 connection. The tunneled data from the server begins immediately
1077 after the blank line that concludes the successful response's header
1078 block. A server SHOULD NOT send any Transfer-Encoding or Content-
1079 Length header fields in a successful response. A client MUST ignore
1080 any Content-Length or Transfer-Encoding header fields received in a
1081 successful response.
1083 Any response other than a successful response indicates that the
1084 tunnel has not yet been formed and that the connection remains
1085 governed by HTTP.
1087 Proxy authentication might be used to establish the authority to
1088 create a tunnel:
1090 CONNECT server.example.com:80 HTTP/1.1
1091 Host: server.example.com:80
1092 Proxy-Authorization: basic aGVsbG86d29ybGQ=
1094 A message body on a CONNECT request has no defined semantics.
1095 Sending a body on a CONNECT request might cause existing
1096 implementations to reject the request.
1098 Similar to a pipelined HTTP/1.1 request, data to be tunneled from
1099 client to server MAY be sent immediately after the request (before a
1100 response is received). The usual caveats also apply: data may be
1101 discarded if the eventual response is negative, and the connection
1102 may be reset with no response if more than one TCP segment is
1103 outstanding.
1105 It may be the case that the proxy itself can only reach the requested
1106 origin server through another proxy. In this case, the first proxy
1107 SHOULD make a CONNECT request of that next proxy, requesting a tunnel
1108 to the authority. A proxy MUST NOT respond with any 2xx status code
1109 unless it has either a direct or tunnel connection established to the
1110 authority.
1112 If at any point either one of the peers gets disconnected, any
1113 outstanding data that came from that peer will be passed to the other
1114 one, and after that also the other connection will be terminated by
1115 the proxy. If there is outstanding data to that peer undelivered,
1116 that data will be discarded.
1118 An origin server which receives a CONNECT request for itself MAY
1119 respond with a 2xx status code to indicate that a connection is
1120 established. However, most origin servers do not implement CONNECT.
1122 7. Status Code Definitions
1124 The first digit of the status-code defines the class of response.
1125 The last two digits do not have any categorization role. There are 5
1126 values for the first digit:
1128 o 1xx: Informational - Request received, continuing process
1130 o 2xx: Success - The action was successfully received, understood,
1131 and accepted
1133 o 3xx: Redirection - Further action must be taken in order to
1134 complete the request
1136 o 4xx: Client Error - The request contains bad syntax or cannot be
1137 fulfilled
1139 o 5xx: Server Error - The server failed to fulfill an apparently
1140 valid request
1142 Each status-code is described below, including any metadata required
1143 in the response.
1145 For most status codes the response can carry a payload, in which case
1146 a Content-Type header field indicates the payload's media type
1147 (Section 6.8 of [Part3]).
1149 7.1. Informational 1xx
1151 This class of status code indicates a provisional response,
1152 consisting only of the status-line and optional header fields, and is
1153 terminated by an empty line. There are no required header fields for
1154 this class of status code. Since HTTP/1.0 did not define any 1xx
1155 status codes, servers MUST NOT send a 1xx response to an HTTP/1.0
1156 client except under experimental conditions.
1158 A client MUST be prepared to accept one or more 1xx status responses
1159 prior to a regular response, even if the client does not expect a 100
1160 (Continue) status message. Unexpected 1xx status responses MAY be
1161 ignored by a user agent.
1163 Proxies MUST forward 1xx responses, unless the connection between the
1164 proxy and its client has been closed, or unless the proxy itself
1165 requested the generation of the 1xx response. (For example, if a
1166 proxy adds a "Expect: 100-continue" field when it forwards a request,
1167 then it need not forward the corresponding 100 (Continue)
1168 response(s).)
1170 7.1.1. 100 Continue
1172 The client SHOULD continue with its request. This interim response
1173 is used to inform the client that the initial part of the request has
1174 been received and has not yet been rejected by the server. The
1175 client SHOULD continue by sending the remainder of the request or, if
1176 the request has already been completed, ignore this response. The
1177 server MUST send a final response after the request has been
1178 completed. See Section 6.4.3 of [Part1] for detailed discussion of
1179 the use and handling of this status code.
1181 7.1.2. 101 Switching Protocols
1183 The server understands and is willing to comply with the client's
1184 request, via the Upgrade message header field (Section 6.5 of
1185 [Part1]), for a change in the application protocol being used on this
1186 connection. The server will switch protocols to those defined by the
1187 response's Upgrade header field immediately after the empty line
1188 which terminates the 101 response.
1190 The protocol SHOULD be switched only when it is advantageous to do
1191 so. For example, switching to a newer version of HTTP is
1192 advantageous over older versions, and switching to a real-time,
1193 synchronous protocol might be advantageous when delivering resources
1194 that use such features.
1196 7.2. Successful 2xx
1198 This class of status code indicates that the client's request was
1199 successfully received, understood, and accepted.
1201 7.2.1. 200 OK
1203 The request has succeeded. The payload returned with the response is
1204 dependent on the method used in the request, for example:
1206 GET a representation of the target resource is sent in the response;
1208 HEAD the same representation as GET, except without the message
1209 body;
1211 POST a representation describing or containing the result of the
1212 action;
1214 TRACE a representation containing the request message as received by
1215 the end server.
1217 Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to
1218 determine freshness for 200 responses.
1220 7.2.2. 201 Created
1222 The request has been fulfilled and has resulted in a new resource
1223 being created.
1225 The newly created resource is typically linked to from the response
1226 payload, with the most relevant URI also being carried in the
1227 Location header field. If the newly created resource's URI is the
1228 same as the Effective Request URI, this information can be omitted
1229 (e.g., in the case of a response to a PUT request).
1231 The origin server MUST create the resource before returning the 201
1232 status code. If the action cannot be carried out immediately, the
1233 server SHOULD respond with 202 (Accepted) response instead.
1235 A 201 response MAY contain an ETag response header field indicating
1236 the current value of the entity-tag for the representation of the
1237 resource just created (see Section 2.3 of [Part4]).
1239 7.2.3. 202 Accepted
1241 The request has been accepted for processing, but the processing has
1242 not been completed. The request might or might not eventually be
1243 acted upon, as it might be disallowed when processing actually takes
1244 place. There is no facility for re-sending a status code from an
1245 asynchronous operation such as this.
1247 The 202 response is intentionally non-committal. Its purpose is to
1248 allow a server to accept a request for some other process (perhaps a
1249 batch-oriented process that is only run once per day) without
1250 requiring that the user agent's connection to the server persist
1251 until the process is completed. The representation returned with
1252 this response SHOULD include an indication of the request's current
1253 status and either a pointer to a status monitor or some estimate of
1254 when the user can expect the request to be fulfilled.
1256 7.2.4. 203 Non-Authoritative Information
1258 The representation in the response has been transformed or otherwise
1259 modified by a transforming proxy (Section 2.3 of [Part1]). Note that
1260 the behavior of transforming intermediaries is controlled by the no-
1261 transform Cache-Control directive (Section 3.2 of [Part6]).
1263 This status code is only appropriate when the response status code
1264 would have been 200 (OK) otherwise. When the status code before
1265 transformation would have been different, the 214 Transformation
1266 Applied warn-code (Section 3.6 of [Part6]) is appropriate.
1268 Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to
1269 determine freshness for 203 responses.
1271 7.2.5. 204 No Content
1273 The 204 (No Content) status code indicates that the server has
1274 successfully fulfilled the request and that there is no additional
1275 content to return in the response payload body. Metadata in the
1276 response header fields refer to the target resource and its current
1277 representation after the requested action.
1279 For example, if a 204 status code is received in response to a PUT
1280 request and the response contains an ETag header field, then the PUT
1281 was successful and the ETag field-value contains the entity-tag for
1282 the new representation of that target resource.
1284 The 204 response allows a server to indicate that the action has been
1285 successfully applied to the target resource while implying that the
1286 user agent SHOULD NOT traverse away from its current "document view"
1287 (if any). The server assumes that the user agent will provide some
1288 indication of the success to its user, in accord with its own
1289 interface, and apply any new or updated metadata in the response to
1290 the active representation.
1292 For example, a 204 status code is commonly used with document editing
1293 interfaces corresponding to a "save" action, such that the document
1294 being saved remains available to the user for editing. It is also
1295 frequently used with interfaces that expect automated data transfers
1296 to be prevalent, such as within distributed version control systems.
1298 The 204 response MUST NOT include a message body, and thus is always
1299 terminated by the first empty line after the header fields.
1301 7.2.6. 205 Reset Content
1303 The server has fulfilled the request and the user agent SHOULD reset
1304 the document view which caused the request to be sent. This response
1305 is primarily intended to allow input for actions to take place via
1306 user input, followed by a clearing of the form in which the input is
1307 given so that the user can easily initiate another input action.
1309 The message body included with the response MUST be empty. Note that
1310 receivers still need to parse the response according to the algorithm
1311 defined in Section 3.3 of [Part1].
1313 7.3. Redirection 3xx
1315 This class of status code indicates that further action needs to be
1316 taken by the user agent in order to fulfill the request. If the
1317 required action involves a subsequent HTTP request, it MAY be carried
1318 out by the user agent without interaction with the user if and only
1319 if the method used in the second request is known to be "safe", as
1320 defined in Section 6.1.1.
1322 There are several types of redirects:
1324 1. Redirects of the request to another URI, either temporarily or
1325 permanently. The new URI is specified in the Location header
1326 field. In this specification, the status codes 301 (Moved
1327 Permanently), 302 (Found), and 307 (Temporary Redirect) fall
1328 under this category.
1330 2. Redirection to a new location that represents an indirect
1331 response to the request, such as the result of a POST operation
1332 to be retrieved with a subsequent GET request. This is status
1333 code 303 (See Other).
1335 3. Redirection offering a choice of matching resources for use by
1336 agent-driven content negotiation (Section 5.2 of [Part3]). This
1337 is status code 300 (Multiple Choices).
1339 4. Other kinds of redirection, such as to a cached result (status
1340 code 304 (Not Modified), see Section 4.1 of [Part4]).
1342 Note: In HTTP/1.0, only the status codes 301 (Moved Permanently)
1343 and 302 (Found) were defined for the first type of redirect, and
1344 the second type did not exist at all ([RFC1945], Section 9.3).
1345 However it turned out that web forms using POST expected redirects
1346 to change the operation for the subsequent request to retrieval
1347 (GET). To address this use case, HTTP/1.1 introduced the second
1348 type of redirect with the status code 303 (See Other) ([RFC2068],
1349 Section 10.3.4). As user agents did not change their behavior to
1350 maintain backwards compatibility, the first revision of HTTP/1.1
1351 added yet another status code, 307 (Temporary Redirect), for which
1352 the backwards compatibility problems did not apply ([RFC2616],
1353 Section 10.3.8). Over 10 years later, most user agents still do
1354 method rewriting for status codes 301 and 302, therefore this
1355 specification makes that behavior conformant in case the original
1356 request was POST.
1358 A Location header field on a 3xx response indicates that a client MAY
1359 automatically redirect to the URI provided; see Section 10.5.
1361 Note that for methods not known to be "safe", as defined in
1362 Section 6.1.1, automatic redirection needs to done with care, since
1363 the redirect might change the conditions under which the request was
1364 issued.
1366 Clients SHOULD detect and intervene in cyclical redirections (i.e.,
1367 "infinite" redirection loops).
1369 Note: An earlier version of this specification recommended a
1370 maximum of five redirections ([RFC2068], Section 10.3). Content
1371 developers need to be aware that some clients might implement such
1372 a fixed limitation.
1374 7.3.1. 300 Multiple Choices
1376 The target resource has more than one representation, each with its
1377 own specific location, and agent-driven negotiation information
1378 (Section 5 of [Part3]) is being provided so that the user (or user
1379 agent) can select a preferred representation by redirecting its
1380 request to that location.
1382 Unless it was a HEAD request, the response SHOULD include a
1383 representation containing a list of representation metadata and
1384 location(s) from which the user or user agent can choose the one most
1385 appropriate. Depending upon the format and the capabilities of the
1386 user agent, selection of the most appropriate choice MAY be performed
1387 automatically. However, this specification does not define any
1388 standard for such automatic selection.
1390 If the server has a preferred choice of representation, it SHOULD
1391 include the specific URI for that representation in the Location
1392 field; user agents MAY use the Location field value for automatic
1393 redirection.
1395 Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to
1396 determine freshness for 300 responses.
1398 7.3.2. 301 Moved Permanently
1400 The target resource has been assigned a new permanent URI and any
1401 future references to this resource SHOULD use one of the returned
1402 URIs. Clients with link editing capabilities ought to automatically
1403 re-link references to the effective request URI to one or more of the
1404 new references returned by the server, where possible.
1406 Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to
1407 determine freshness for 301 responses.
1409 The new permanent URI SHOULD be given by the Location field in the
1410 response. A response payload can contain a short hypertext note with
1411 a hyperlink to the new URI(s).
1413 Note: For historic reasons, user agents MAY change the request
1414 method from POST to GET for the subsequent request. If this
1415 behavior is undesired, status code 307 (Temporary Redirect) can be
1416 used instead.
1418 7.3.3. 302 Found
1420 The target resource resides temporarily under a different URI. Since
1421 the redirection might be altered on occasion, the client SHOULD
1422 continue to use the effective request URI for future requests.
1424 The temporary URI SHOULD be given by the Location field in the
1425 response. A response payload can contain a short hypertext note with
1426 a hyperlink to the new URI(s).
1428 Note: For historic reasons, user agents MAY change the request
1429 method from POST to GET for the subsequent request. If this
1430 behavior is undesired, status code 307 (Temporary Redirect) can be
1431 used instead.
1433 7.3.4. 303 See Other
1435 The 303 status code indicates that the server is redirecting the user
1436 agent to a different resource, as indicated by a URI in the Location
1437 header field, that is intended to provide an indirect response to the
1438 original request. In order to satisfy the original request, a user
1439 agent SHOULD perform a retrieval request using the Location URI (a
1440 GET or HEAD request if using HTTP), which may itself be redirected
1441 further, and present the eventual result as an answer to the original
1442 request. Note that the new URI in the Location header field is not
1443 considered equivalent to the effective request URI.
1445 This status code is generally applicable to any HTTP method. It is
1446 primarily used to allow the output of a POST action to redirect the
1447 user agent to a selected resource, since doing so provides the
1448 information corresponding to the POST response in a form that can be
1449 separately identified, bookmarked, and cached independent of the
1450 original request.
1452 A 303 response to a GET request indicates that the requested resource
1453 does not have a representation of its own that can be transferred by
1454 the server over HTTP. The Location URI indicates a resource that is
1455 descriptive of the target resource, such that the follow-on
1456 representation might be useful to recipients without implying that it
1457 adequately represents the target resource. Note that answers to the
1458 questions of what can be represented, what representations are
1459 adequate, and what might be a useful description are outside the
1460 scope of HTTP and thus entirely determined by the URI owner(s).
1462 Except for responses to a HEAD request, the representation of a 303
1463 response SHOULD contain a short hypertext note with a hyperlink to
1464 the Location URI.
1466 7.3.5. 305 Use Proxy
1468 The 305 status code was defined in a previous version of this
1469 specification (see Appendix A), and is now deprecated.
1471 7.3.6. 306 (Unused)
1473 The 306 status code was used in a previous version of the
1474 specification, is no longer used, and the code is reserved.
1476 7.3.7. 307 Temporary Redirect
1478 The target resource resides temporarily under a different URI. Since
1479 the redirection can change over time, the client SHOULD continue to
1480 use the effective request URI for future requests.
1482 The temporary URI SHOULD be given by the Location field in the
1483 response. A response payload can contain a short hypertext note with
1484 a hyperlink to the new URI(s).
1486 Note: This status code is similar to 302 Found, except that it
1487 does not allow rewriting the request method from POST to GET.
1488 This specification defines no equivalent counterpart for 301 Moved
1489 Permanently.
1491 7.4. Client Error 4xx
1493 The 4xx class of status code is intended for cases in which the
1494 client seems to have erred. Except when responding to a HEAD
1495 request, the server SHOULD include a representation containing an
1496 explanation of the error situation, and whether it is a temporary or
1497 permanent condition. These status codes are applicable to any
1498 request method. User agents SHOULD display any included
1499 representation to the user.
1501 7.4.1. 400 Bad Request
1503 The server cannot or will not process the request, due to a client
1504 error (e.g., malformed syntax).
1506 7.4.2. 402 Payment Required
1508 This code is reserved for future use.
1510 7.4.3. 403 Forbidden
1512 The server understood the request, but refuses to authorize it.
1513 Providing different user authentication credentials might be
1514 successful, but any credentials that were provided in the request are
1515 insufficient. The request SHOULD NOT be repeated with the same
1516 credentials.
1518 If the request method was not HEAD and the server wishes to make
1519 public why the request has not been fulfilled, it SHOULD describe the
1520 reason for the refusal in the representation. If the server does not
1521 wish to make this information available to the client, the status
1522 code 404 (Not Found) MAY be used instead.
1524 7.4.4. 404 Not Found
1526 The server has not found anything matching the effective request URI.
1527 No indication is given of whether the condition is temporary or
1528 permanent. The 410 (Gone) status code SHOULD be used if the server
1529 knows, through some internally configurable mechanism, that an old
1530 resource is permanently unavailable and has no forwarding address.
1531 This status code is commonly used when the server does not wish to
1532 reveal exactly why the request has been refused, or when no other
1533 response is applicable.
1535 7.4.5. 405 Method Not Allowed
1537 The method specified in the request-line is not allowed for the
1538 target resource. The response MUST include an Allow header field
1539 containing a list of valid methods for the requested resource.
1541 7.4.6. 406 Not Acceptable
1543 The resource identified by the request is only capable of generating
1544 response representations which have content characteristics not
1545 acceptable according to the Accept and Accept-* header fields sent in
1546 the request (see Section 6 of [Part3]).
1548 Unless it was a HEAD request, the response SHOULD include a
1549 representation containing a list of available representation
1550 characteristics and location(s) from which the user or user agent can
1551 choose the one most appropriate. Depending upon the format and the
1552 capabilities of the user agent, selection of the most appropriate
1553 choice MAY be performed automatically. However, this specification
1554 does not define any standard for such automatic selection.
1556 Note: HTTP/1.1 servers are allowed to return responses which are
1557 not acceptable according to the accept header fields sent in the
1558 request. In some cases, this might even be preferable to sending
1559 a 406 response. User agents are encouraged to inspect the header
1560 fields of an incoming response to determine if it is acceptable.
1562 If the response could be unacceptable, a user agent SHOULD
1563 temporarily stop receipt of more data and query the user for a
1564 decision on further actions.
1566 7.4.7. 408 Request Timeout
1568 The client did not produce a request within the time that the server
1569 was prepared to wait. The client MAY repeat the request without
1570 modifications at any later time.
1572 7.4.8. 409 Conflict
1574 The request could not be completed due to a conflict with the current
1575 state of the resource. This code is only allowed in situations where
1576 it is expected that the user might be able to resolve the conflict
1577 and resubmit the request. The response body SHOULD include enough
1578 information for the user to recognize the source of the conflict.
1579 Ideally, the response representation would include enough information
1580 for the user or user agent to fix the problem; however, that might
1581 not be possible and is not required.
1583 Conflicts are most likely to occur in response to a PUT request. For
1584 example, if versioning were being used and the representation being
1585 PUT included changes to a resource which conflict with those made by
1586 an earlier (third-party) request, the server might use the 409
1587 response to indicate that it can't complete the request. In this
1588 case, the response representation would likely contain a list of the
1589 differences between the two versions.
1591 7.4.9. 410 Gone
1593 The target resource is no longer available at the server and no
1594 forwarding address is known. This condition is expected to be
1595 considered permanent. Clients with link editing capabilities SHOULD
1596 delete references to the effective request URI after user approval.
1597 If the server does not know, or has no facility to determine, whether
1598 or not the condition is permanent, the status code 404 (Not Found)
1599 SHOULD be used instead.
1601 The 410 response is primarily intended to assist the task of web
1602 maintenance by notifying the recipient that the resource is
1603 intentionally unavailable and that the server owners desire that
1604 remote links to that resource be removed. Such an event is common
1605 for limited-time, promotional services and for resources belonging to
1606 individuals no longer working at the server's site. It is not
1607 necessary to mark all permanently unavailable resources as "gone" or
1608 to keep the mark for any length of time -- that is left to the
1609 discretion of the server owner.
1611 Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to
1612 determine freshness for 410 responses.
1614 7.4.10. 411 Length Required
1616 The server refuses to accept the request without a defined Content-
1617 Length. The client MAY repeat the request if it adds a valid
1618 Content-Length header field containing the length of the message body
1619 in the request message.
1621 7.4.11. 413 Request Representation Too Large
1623 The server is refusing to process a request because the request
1624 representation is larger than the server is willing or able to
1625 process. The server MAY close the connection to prevent the client
1626 from continuing the request.
1628 If the condition is temporary, the server SHOULD include a Retry-
1629 After header field to indicate that it is temporary and after what
1630 time the client MAY try again.
1632 7.4.12. 414 URI Too Long
1634 The server is refusing to service the request because the effective
1635 request URI is longer than the server is willing to interpret. This
1636 rare condition is only likely to occur when a client has improperly
1637 converted a POST request to a GET request with long query
1638 information, when the client has descended into a URI "black hole" of
1639 redirection (e.g., a redirected URI prefix that points to a suffix of
1640 itself), or when the server is under attack by a client attempting to
1641 exploit security holes present in some servers using fixed-length
1642 buffers for reading or manipulating the request-target.
1644 7.4.13. 415 Unsupported Media Type
1646 The server is refusing to service the request because the request
1647 payload is in a format not supported by this request method on the
1648 target resource.
1650 7.4.14. 417 Expectation Failed
1652 The expectation given in an Expect header field (see Section 10.3)
1653 could not be met by this server, or, if the server is a proxy, the
1654 server has unambiguous evidence that the request could not be met by
1655 the next-hop server.
1657 7.4.15. 426 Upgrade Required
1659 The request can not be completed without a prior protocol upgrade.
1660 This response MUST include an Upgrade header field (Section 6.5 of
1661 [Part1]) specifying the required protocols.
1663 Example:
1665 HTTP/1.1 426 Upgrade Required
1666 Upgrade: HTTP/3.0
1667 Connection: Upgrade
1668 Content-Length: 53
1669 Content-Type: text/plain
1671 This service requires use of the HTTP/3.0 protocol.
1673 The server SHOULD include a message body in the 426 response which
1674 indicates in human readable form the reason for the error and
1675 describes any alternative courses which may be available to the user.
1677 7.5. Server Error 5xx
1679 Response status codes beginning with the digit "5" indicate cases in
1680 which the server is aware that it has erred or is incapable of
1681 performing the request. Except when responding to a HEAD request,
1682 the server SHOULD include a representation containing an explanation
1683 of the error situation, and whether it is a temporary or permanent
1684 condition. User agents SHOULD display any included representation to
1685 the user. These response codes are applicable to any request method.
1687 7.5.1. 500 Internal Server Error
1689 The server encountered an unexpected condition which prevented it
1690 from fulfilling the request.
1692 7.5.2. 501 Not Implemented
1694 The server does not support the functionality required to fulfill the
1695 request. This is the appropriate response when the server does not
1696 recognize the request method and is not capable of supporting it for
1697 any resource.
1699 7.5.3. 502 Bad Gateway
1701 The server, while acting as a gateway or proxy, received an invalid
1702 response from the upstream server it accessed in attempting to
1703 fulfill the request.
1705 7.5.4. 503 Service Unavailable
1707 The server is currently unable to handle the request due to a
1708 temporary overloading or maintenance of the server.
1710 The implication is that this is a temporary condition which will be
1711 alleviated after some delay. If known, the length of the delay MAY
1712 be indicated in a Retry-After header field (Section 10.8). If no
1713 Retry-After is given, the client SHOULD handle the response as it
1714 would for a 500 response.
1716 Note: The existence of the 503 status code does not imply that a
1717 server must use it when becoming overloaded. Some servers might
1718 wish to simply refuse the connection.
1720 7.5.5. 504 Gateway Timeout
1722 The server, while acting as a gateway or proxy, did not receive a
1723 timely response from the upstream server specified by the URI (e.g.,
1724 HTTP, FTP, LDAP) or some other auxiliary server (e.g., DNS) it needed
1725 to access in attempting to complete the request.
1727 Note to implementors: some deployed proxies are known to return
1728 400 or 500 when DNS lookups time out.
1730 7.5.6. 505 HTTP Version Not Supported
1732 The server does not support, or refuses to support, the protocol
1733 version that was used in the request message. The server is
1734 indicating that it is unable or unwilling to complete the request
1735 using the same major version as the client, as described in Section
1736 2.6 of [Part1], other than with this error message. The response
1737 SHOULD contain a representation describing why that version is not
1738 supported and what other protocols are supported by that server.
1740 8. Date/Time Formats
1742 HTTP applications have historically allowed three different formats
1743 for date/time stamps. However, the preferred format is a fixed-
1744 length subset of that defined by [RFC1123]:
1746 Sun, 06 Nov 1994 08:49:37 GMT ; RFC 1123
1748 The other formats are described here only for compatibility with
1749 obsolete implementations.
1751 Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format
1752 Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format
1754 HTTP/1.1 clients and servers that parse a date value MUST accept all
1755 three formats (for compatibility with HTTP/1.0), though they MUST
1756 only generate the RFC 1123 format for representing HTTP-date values
1757 in header fields.
1759 All HTTP date/time stamps MUST be represented in Greenwich Mean Time
1760 (GMT), without exception. For the purposes of HTTP, GMT is exactly
1761 equal to UTC (Coordinated Universal Time). This is indicated in the
1762 first two formats by the inclusion of "GMT" as the three-letter
1763 abbreviation for time zone, and MUST be assumed when reading the
1764 asctime format. HTTP-date is case sensitive and MUST NOT include
1765 additional whitespace beyond that specifically included as SP in the
1766 grammar.
1768 HTTP-date = rfc1123-date / obs-date
1770 Preferred format:
1772 rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT
1773 ; fixed length subset of the format defined in
1774 ; Section 5.2.14 of [RFC1123]
1776 day-name = %x4D.6F.6E ; "Mon", case-sensitive
1777 / %x54.75.65 ; "Tue", case-sensitive
1778 / %x57.65.64 ; "Wed", case-sensitive
1779 / %x54.68.75 ; "Thu", case-sensitive
1780 / %x46.72.69 ; "Fri", case-sensitive
1781 / %x53.61.74 ; "Sat", case-sensitive
1782 / %x53.75.6E ; "Sun", case-sensitive
1784 date1 = day SP month SP year
1785 ; e.g., 02 Jun 1982
1787 day = 2DIGIT
1788 month = %x4A.61.6E ; "Jan", case-sensitive
1789 / %x46.65.62 ; "Feb", case-sensitive
1790 / %x4D.61.72 ; "Mar", case-sensitive
1791 / %x41.70.72 ; "Apr", case-sensitive
1792 / %x4D.61.79 ; "May", case-sensitive
1793 / %x4A.75.6E ; "Jun", case-sensitive
1794 / %x4A.75.6C ; "Jul", case-sensitive
1795 / %x41.75.67 ; "Aug", case-sensitive
1796 / %x53.65.70 ; "Sep", case-sensitive
1797 / %x4F.63.74 ; "Oct", case-sensitive
1798 / %x4E.6F.76 ; "Nov", case-sensitive
1799 / %x44.65.63 ; "Dec", case-sensitive
1800 year = 4DIGIT
1802 GMT = %x47.4D.54 ; "GMT", case-sensitive
1804 time-of-day = hour ":" minute ":" second
1805 ; 00:00:00 - 23:59:59
1807 hour = 2DIGIT
1808 minute = 2DIGIT
1809 second = 2DIGIT
1811 The semantics of day-name, day, month, year, and time-of-day are the
1812 same as those defined for the RFC 5322 constructs with the
1813 corresponding name ([RFC5322], Section 3.3).
1815 Obsolete formats:
1817 obs-date = rfc850-date / asctime-date
1818 rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT
1819 date2 = day "-" month "-" 2DIGIT
1820 ; day-month-year (e.g., 02-Jun-82)
1822 day-name-l = %x4D.6F.6E.64.61.79 ; "Monday", case-sensitive
1823 / %x54.75.65.73.64.61.79 ; "Tuesday", case-sensitive
1824 / %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive
1825 / %x54.68.75.72.73.64.61.79 ; "Thursday", case-sensitive
1826 / %x46.72.69.64.61.79 ; "Friday", case-sensitive
1827 / %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive
1828 / %x53.75.6E.64.61.79 ; "Sunday", case-sensitive
1830 asctime-date = day-name SP date3 SP time-of-day SP year
1831 date3 = month SP ( 2DIGIT / ( SP 1DIGIT ))
1832 ; month day (e.g., Jun 2)
1834 Note: Recipients of date values are encouraged to be robust in
1835 accepting date values that might have been sent by non-HTTP
1836 applications, as is sometimes the case when retrieving or posting
1837 messages via proxies/gateways to SMTP or NNTP.
1839 Note: HTTP requirements for the date/time stamp format apply only
1840 to their usage within the protocol stream. Clients and servers
1841 are not required to use these formats for user presentation,
1842 request logging, etc.
1844 9. Product Tokens
1846 Product tokens are used to allow communicating applications to
1847 identify themselves by software name and version. Most fields using
1848 product tokens also allow sub-products which form a significant part
1849 of the application to be listed, separated by whitespace. By
1850 convention, the products are listed in order of their significance
1851 for identifying the application.
1853 product = token ["/" product-version]
1854 product-version = token
1856 Examples:
1858 User-Agent: CERN-LineMode/2.15 libwww/2.17b3
1859 Server: Apache/0.8.4
1861 Product tokens SHOULD be short and to the point. They MUST NOT be
1862 used for advertising or other non-essential information. Although
1863 any token octet MAY appear in a product-version, this token SHOULD
1864 only be used for a version identifier (i.e., successive versions of
1865 the same product SHOULD only differ in the product-version portion of
1866 the product value).
1868 10. Header Field Definitions
1870 This section defines the syntax and semantics of HTTP/1.1 header
1871 fields related to request and response semantics.
1873 10.1. Allow
1875 The "Allow" header field lists the set of methods advertised as
1876 supported by the target resource. The purpose of this field is
1877 strictly to inform the recipient of valid request methods associated
1878 with the resource.
1880 Allow = #method
1882 Example of use:
1884 Allow: GET, HEAD, PUT
1886 The actual set of allowed methods is defined by the origin server at
1887 the time of each request.
1889 A proxy MUST NOT modify the Allow header field -- it does not need to
1890 understand all the methods specified in order to handle them
1891 according to the generic message handling rules.
1893 10.2. Date
1895 The "Date" header field represents the date and time at which the
1896 message was originated, having the same semantics as the Origination
1897 Date Field (orig-date) defined in Section 3.6.1 of [RFC5322]. The
1898 field value is an HTTP-date, as defined in Section 8; it MUST be sent
1899 in rfc1123-date format.
1901 Date = HTTP-date
1903 An example is
1905 Date: Tue, 15 Nov 1994 08:12:31 GMT
1907 Origin servers MUST include a Date header field in all responses,
1908 except in these cases:
1910 1. If the response status code is 100 (Continue) or 101 (Switching
1911 Protocols), the response MAY include a Date header field, at the
1912 server's option.
1914 2. If the response status code conveys a server error, e.g., 500
1915 (Internal Server Error) or 503 (Service Unavailable), and it is
1916 inconvenient or impossible to generate a valid Date.
1918 3. If the server does not have a clock that can provide a reasonable
1919 approximation of the current time, its responses MUST NOT include
1920 a Date header field.
1922 A received message that does not have a Date header field MUST be
1923 assigned one by the recipient if the message will be cached by that
1924 recipient.
1926 Clients can use the Date header field as well; in order to keep
1927 request messages small, they are advised not to include it when it
1928 doesn't convey any useful information (as is usually the case for
1929 requests that do not contain a payload).
1931 The HTTP-date sent in a Date header field SHOULD NOT represent a date
1932 and time subsequent to the generation of the message. It SHOULD
1933 represent the best available approximation of the date and time of
1934 message generation, unless the implementation has no means of
1935 generating a reasonably accurate date and time. In theory, the date
1936 ought to represent the moment just before the payload is generated.
1937 In practice, the date can be generated at any time during the message
1938 origination without affecting its semantic value.
1940 10.3. Expect
1942 The "Expect" header field is used to indicate that particular server
1943 behaviors are required by the client.
1945 Expect = 1#expectation
1947 expectation = expect-name [ BWS "=" BWS expect-value ]
1948 *( OWS ";" [ OWS expect-param ] )
1949 expect-param = expect-name [ BWS "=" BWS expect-value ]
1951 expect-name = token
1952 expect-value = token / quoted-string
1954 If all received Expect header field(s) are syntactically valid but
1955 contain an expectation that the recipient does not understand or
1956 cannot comply with, the recipient MUST respond with a 417
1957 (Expectation Failed) status code. A recipient of a syntactically
1958 invalid Expectation header field MUST respond with a 4xx status code
1959 other than 417.
1961 The only expectation defined by this specification is:
1963 100-continue
1965 The "100-continue" expectation is defined Section 6.4.3 of
1966 [Part1]. It does not support any expect-params.
1968 Comparison is case-insensitive for names (expect-name), and case-
1969 sensitive for values (expect-value).
1971 The Expect mechanism is hop-by-hop: the above requirements apply to
1972 any server, including proxies. However, the Expect header field
1973 itself is end-to-end; it MUST be forwarded if the request is
1974 forwarded.
1976 Many older HTTP/1.0 and HTTP/1.1 applications do not understand the
1977 Expect header field.
1979 10.4. From
1981 The "From" header field, if given, SHOULD contain an Internet e-mail
1982 address for the human user who controls the requesting user agent.
1983 The address SHOULD be machine-usable, as defined by "mailbox" in
1984 Section 3.4 of [RFC5322]:
1986 From = mailbox
1988 mailbox =
1990 An example is:
1992 From: webmaster@example.org
1994 This header field MAY be used for logging purposes and as a means for
1995 identifying the source of invalid or unwanted requests. It SHOULD
1996 NOT be used as an insecure form of access protection. The
1997 interpretation of this field is that the request is being performed
1998 on behalf of the person given, who accepts responsibility for the
1999 method performed. In particular, robot agents SHOULD include this
2000 header field so that the person responsible for running the robot can
2001 be contacted if problems occur on the receiving end.
2003 The Internet e-mail address in this field MAY be separate from the
2004 Internet host which issued the request. For example, when a request
2005 is passed through a proxy the original issuer's address SHOULD be
2006 used.
2008 The client SHOULD NOT send the From header field without the user's
2009 approval, as it might conflict with the user's privacy interests or
2010 their site's security policy. It is strongly recommended that the
2011 user be able to disable, enable, and modify the value of this field
2012 at any time prior to a request.
2014 10.5. Location
2016 The "Location" header field MAY be sent in responses to refer to a
2017 specific resource in accordance with the semantics of the status
2018 code.
2020 Location = URI-reference
2022 For 201 (Created) responses, the Location is the URI of the new
2023 resource which was created by the request. For 3xx responses, the
2024 location SHOULD indicate the server's preferred URI for automatic
2025 redirection to the resource.
2027 The field value consists of a single URI-reference. When it has the
2028 form of a relative reference ([RFC3986], Section 4.2), the final
2029 value is computed by resolving it against the effective request URI
2030 ([RFC3986], Section 5). If the original URI, as navigated to by the
2031 user agent, did contain a fragment identifier, and the final value
2032 does not, then the original URI's fragment identifier is added to the
2033 final value.
2035 For example, the original URI "http://www.example.org/~tim", combined
2036 with a field value given as:
2038 Location: /pub/WWW/People.html#tim
2040 would result in a final value of
2041 "http://www.example.org/pub/WWW/People.html#tim"
2043 An original URI "http://www.example.org/index.html#larry", combined
2044 with a field value given as:
2046 Location: http://www.example.net/index.html
2048 would result in a final value of
2049 "http://www.example.net/index.html#larry", preserving the original
2050 fragment identifier.
2052 Note: Some recipients attempt to recover from Location fields that
2053 are not valid URI references. This specification does not mandate
2054 or define such processing, but does allow it (see Section 1.1).
2056 There are circumstances in which a fragment identifier in a Location
2057 URI would not be appropriate. For instance, when it appears in a 201
2058 Created response, where the Location header field specifies the URI
2059 for the entire created resource.
2061 Note: The Content-Location header field (Section 6.7 of [Part3])
2062 differs from Location in that the Content-Location identifies the
2063 most specific resource corresponding to the enclosed
2064 representation. It is therefore possible for a response to
2065 contain header fields for both Location and Content-Location.
2067 10.6. Max-Forwards
2069 The "Max-Forwards" header field provides a mechanism with the TRACE
2070 (Section 6.8) and OPTIONS (Section 6.2) methods to limit the number
2071 of times that the request is forwarded by proxies. This can be
2072 useful when the client is attempting to trace a request which appears
2073 to be failing or looping mid-chain.
2075 Max-Forwards = 1*DIGIT
2077 The Max-Forwards value is a decimal integer indicating the remaining
2078 number of times this request message can be forwarded.
2080 Each recipient of a TRACE or OPTIONS request containing a Max-
2081 Forwards header field MUST check and update its value prior to
2082 forwarding the request. If the received value is zero (0), the
2083 recipient MUST NOT forward the request; instead, it MUST respond as
2084 the final recipient. If the received Max-Forwards value is greater
2085 than zero, then the forwarded message MUST contain an updated Max-
2086 Forwards field with a value decremented by one (1).
2088 The Max-Forwards header field MAY be ignored for all other request
2089 methods.
2091 10.7. Referer
2093 The "Referer" [sic] header field allows the client to specify the URI
2094 of the resource from which the target URI was obtained (the
2095 "referrer", although the header field is misspelled.).
2097 The Referer header field allows servers to generate lists of back-
2098 links to resources for interest, logging, optimized caching, etc. It
2099 also allows obsolete or mistyped links to be traced for maintenance.
2100 Some servers use Referer as a means of controlling where they allow
2101 links from (so-called "deep linking"), but legitimate requests do not
2102 always contain a Referer header field.
2104 If the target URI was obtained from a source that does not have its
2105 own URI (e.g., input from the user keyboard), the Referer field MUST
2106 either be sent with the value "about:blank", or not be sent at all.
2108 Note that this requirement does not apply to sources with non-HTTP
2109 URIs (e.g., FTP).
2111 Referer = absolute-URI / partial-URI
2113 Example:
2115 Referer: http://www.example.org/hypertext/Overview.html
2117 If the field value is a relative URI, it SHOULD be interpreted
2118 relative to the effective request URI. The URI MUST NOT include a
2119 fragment. See Section 12.2 for security considerations.
2121 10.8. Retry-After
2123 The header "Retry-After" field can be used with a 503 (Service
2124 Unavailable) response to indicate how long the service is expected to
2125 be unavailable to the requesting client. This field MAY also be used
2126 with any 3xx (Redirection) response to indicate the minimum time the
2127 user-agent is asked to wait before issuing the redirected request.
2129 The value of this field can be either an HTTP-date or an integer
2130 number of seconds (in decimal) after the time of the response.
2132 Retry-After = HTTP-date / delta-seconds
2134 Time spans are non-negative decimal integers, representing time in
2135 seconds.
2137 delta-seconds = 1*DIGIT
2139 Two examples of its use are
2141 Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
2142 Retry-After: 120
2144 In the latter example, the delay is 2 minutes.
2146 10.9. Server
2148 The "Server" header field contains information about the software
2149 used by the origin server to handle the request.
2151 The field can contain multiple product tokens (Section 9) and
2152 comments (Section 3.2 of [Part1]) identifying the server and any
2153 significant subproducts. The product tokens are listed in order of
2154 their significance for identifying the application.
2156 Server = product *( RWS ( product / comment ) )
2158 Example:
2160 Server: CERN/3.0 libwww/2.17
2162 If the response is being forwarded through a proxy, the proxy
2163 application MUST NOT modify the Server header field. Instead, it
2164 MUST include a Via field (as described in Section 6.2 of [Part1]).
2166 Note: Revealing the specific software version of the server might
2167 allow the server machine to become more vulnerable to attacks
2168 against software that is known to contain security holes. Server
2169 implementors are encouraged to make this field a configurable
2170 option.
2172 10.10. User-Agent
2174 The "User-Agent" header field contains information about the user
2175 agent originating the request. User agents SHOULD include this field
2176 with requests.
2178 Typically, it is used for statistical purposes, the tracing of
2179 protocol violations, and tailoring responses to avoid particular user
2180 agent limitations.
2182 The field can contain multiple product tokens (Section 9) and
2183 comments (Section 3.2 of [Part1]) identifying the agent and its
2184 significant subproducts. By convention, the product tokens are
2185 listed in order of their significance for identifying the
2186 application.
2188 Because this field is usually sent on every request a user agent
2189 makes, implementations are encouraged not to include needlessly fine-
2190 grained detail, and to limit (or even prohibit) the addition of
2191 subproducts by third parties. Overly long and detailed User-Agent
2192 field values make requests larger and can also be used to identify
2193 ("fingerprint") the user against their wishes.
2195 Likewise, implementations are encouraged not to use the product
2196 tokens of other implementations in order to declare compatibility
2197 with them, as this circumvents the purpose of the field. Finally,
2198 they are encouraged not to use comments to identify products; doing
2199 so makes the field value more difficult to parse.
2201 User-Agent = product *( RWS ( product / comment ) )
2203 Example:
2205 User-Agent: CERN-LineMode/2.15 libwww/2.17b3
2207 11. IANA Considerations
2209 11.1. Method Registry
2211 The registration procedure for HTTP request methods is defined by
2212 Section 2.2 of this document.
2214 The HTTP Method Registry shall be created at
2215 and be populated with
2216 the registrations below:
2218 +---------+------+-------------+
2219 | Method | Safe | Reference |
2220 +---------+------+-------------+
2221 | CONNECT | no | Section 6.9 |
2222 | DELETE | no | Section 6.7 |
2223 | GET | yes | Section 6.3 |
2224 | HEAD | yes | Section 6.4 |
2225 | OPTIONS | yes | Section 6.2 |
2226 | POST | no | Section 6.5 |
2227 | PUT | no | Section 6.6 |
2228 | TRACE | yes | Section 6.8 |
2229 +---------+------+-------------+
2231 11.2. Status Code Registry
2233 The registration procedure for HTTP Status Codes -- previously
2234 defined in Section 7.1 of [RFC2817] -- is now defined by Section 4.2
2235 of this document.
2237 The HTTP Status Code Registry located at
2238 shall be updated
2239 with the registrations below:
2241 +-------+----------------------------------+----------------+
2242 | Value | Description | Reference |
2243 +-------+----------------------------------+----------------+
2244 | 100 | Continue | Section 7.1.1 |
2245 | 101 | Switching Protocols | Section 7.1.2 |
2246 | 200 | OK | Section 7.2.1 |
2247 | 201 | Created | Section 7.2.2 |
2248 | 202 | Accepted | Section 7.2.3 |
2249 | 203 | Non-Authoritative Information | Section 7.2.4 |
2250 | 204 | No Content | Section 7.2.5 |
2251 | 205 | Reset Content | Section 7.2.6 |
2252 | 300 | Multiple Choices | Section 7.3.1 |
2253 | 301 | Moved Permanently | Section 7.3.2 |
2254 | 302 | Found | Section 7.3.3 |
2255 | 303 | See Other | Section 7.3.4 |
2256 | 305 | Use Proxy | Section 7.3.5 |
2257 | 306 | (Unused) | Section 7.3.6 |
2258 | 307 | Temporary Redirect | Section 7.3.7 |
2259 | 400 | Bad Request | Section 7.4.1 |
2260 | 402 | Payment Required | Section 7.4.2 |
2261 | 403 | Forbidden | Section 7.4.3 |
2262 | 404 | Not Found | Section 7.4.4 |
2263 | 405 | Method Not Allowed | Section 7.4.5 |
2264 | 406 | Not Acceptable | Section 7.4.6 |
2265 | 408 | Request Timeout | Section 7.4.7 |
2266 | 409 | Conflict | Section 7.4.8 |
2267 | 410 | Gone | Section 7.4.9 |
2268 | 411 | Length Required | Section 7.4.10 |
2269 | 413 | Request Representation Too Large | Section 7.4.11 |
2270 | 414 | URI Too Long | Section 7.4.12 |
2271 | 415 | Unsupported Media Type | Section 7.4.13 |
2272 | 417 | Expectation Failed | Section 7.4.14 |
2273 | 426 | Upgrade Required | Section 7.4.15 |
2274 | 500 | Internal Server Error | Section 7.5.1 |
2275 | 501 | Not Implemented | Section 7.5.2 |
2276 | 502 | Bad Gateway | Section 7.5.3 |
2277 | 503 | Service Unavailable | Section 7.5.4 |
2278 | 504 | Gateway Timeout | Section 7.5.5 |
2279 | 505 | HTTP Version Not Supported | Section 7.5.6 |
2280 +-------+----------------------------------+----------------+
2282 11.3. Header Field Registration
2284 The Message Header Field Registry located at shall be
2286 updated with the permanent registrations below (see [RFC3864]):
2288 +-------------------+----------+----------+---------------+
2289 | Header Field Name | Protocol | Status | Reference |
2290 +-------------------+----------+----------+---------------+
2291 | Allow | http | standard | Section 10.1 |
2292 | Date | http | standard | Section 10.2 |
2293 | Expect | http | standard | Section 10.3 |
2294 | From | http | standard | Section 10.4 |
2295 | Location | http | standard | Section 10.5 |
2296 | Max-Forwards | http | standard | Section 10.6 |
2297 | Referer | http | standard | Section 10.7 |
2298 | Retry-After | http | standard | Section 10.8 |
2299 | Server | http | standard | Section 10.9 |
2300 | User-Agent | http | standard | Section 10.10 |
2301 +-------------------+----------+----------+---------------+
2303 The change controller is: "IETF (iesg@ietf.org) - Internet
2304 Engineering Task Force".
2306 12. Security Considerations
2308 This section is meant to inform application developers, information
2309 providers, and users of the security limitations in HTTP/1.1 as
2310 described by this document. The discussion does not include
2311 definitive solutions to the problems revealed, though it does make
2312 some suggestions for reducing security risks.
2314 12.1. Transfer of Sensitive Information
2316 Like any generic data transfer protocol, HTTP cannot regulate the
2317 content of the data that is transferred, nor is there any a priori
2318 method of determining the sensitivity of any particular piece of
2319 information within the context of any given request. Therefore,
2320 applications SHOULD supply as much control over this information as
2321 possible to the provider of that information. Four header fields are
2322 worth special mention in this context: Server, Via, Referer and From.
2324 Revealing the specific software version of the server might allow the
2325 server machine to become more vulnerable to attacks against software
2326 that is known to contain security holes. Implementors SHOULD make
2327 the Server header field a configurable option.
2329 Proxies which serve as a portal through a network firewall SHOULD
2330 take special precautions regarding the transfer of header information
2331 that identifies the hosts behind the firewall. In particular, they
2332 SHOULD remove, or replace with sanitized versions, any Via fields
2333 generated behind the firewall.
2335 The Referer header field allows reading patterns to be studied and
2336 reverse links drawn. Although it can be very useful, its power can
2337 be abused if user details are not separated from the information
2338 contained in the Referer. Even when the personal information has
2339 been removed, the Referer header field might indicate a private
2340 document's URI whose publication would be inappropriate.
2342 The information sent in the From field might conflict with the user's
2343 privacy interests or their site's security policy, and hence it
2344 SHOULD NOT be transmitted without the user being able to disable,
2345 enable, and modify the contents of the field. The user MUST be able
2346 to set the contents of this field within a user preference or
2347 application defaults configuration.
2349 We suggest, though do not require, that a convenient toggle interface
2350 be provided for the user to enable or disable the sending of From and
2351 Referer information.
2353 The User-Agent (Section 10.10) or Server (Section 10.9) header fields
2354 can sometimes be used to determine that a specific client or server
2355 has a particular security hole which might be exploited.
2356 Unfortunately, this same information is often used for other valuable
2357 purposes for which HTTP currently has no better mechanism.
2359 Furthermore, the User-Agent header field may contain enough entropy
2360 to be used, possibly in conjunction with other material, to uniquely
2361 identify the user.
2363 Some request methods, like TRACE (Section 6.8), expose information
2364 that was sent in request header fields within the body of their
2365 response. Clients SHOULD be careful with sensitive information, like
2366 Cookies, Authorization credentials, and other header fields that
2367 might be used to collect data from the client.
2369 12.2. Encoding Sensitive Information in URIs
2371 Because the source of a link might be private information or might
2372 reveal an otherwise private information source, it is strongly
2373 recommended that the user be able to select whether or not the
2374 Referer field is sent. For example, a browser client could have a
2375 toggle switch for browsing openly/anonymously, which would
2376 respectively enable/disable the sending of Referer and From
2377 information.
2379 Clients SHOULD NOT include a Referer header field in a (non-secure)
2380 HTTP request if the referring page was transferred with a secure
2381 protocol.
2383 Authors of services SHOULD NOT use GET-based forms for the submission
2384 of sensitive data because that data will be placed in the request-
2385 target. Many existing servers, proxies, and user agents log or
2386 display the request-target in places where it might be visible to
2387 third parties. Such services can use POST-based form submission
2388 instead.
2390 12.3. Location Header Fields: Spoofing and Information Leakage
2392 If a single server supports multiple organizations that do not trust
2393 one another, then it MUST check the values of Location and Content-
2394 Location header fields in responses that are generated under control
2395 of said organizations to make sure that they do not attempt to
2396 invalidate resources over which they have no authority.
2398 Furthermore, appending the fragment identifier from one URI to
2399 another one obtained from a Location header field might leak
2400 confidential information to the target server -- although the
2401 fragment identifier is not transmitted in the final request, it might
2402 be visible to the user agent through other means, such as scripting.
2404 12.4. Security Considerations for CONNECT
2406 Since tunneled data is opaque to the proxy, there are additional
2407 risks to tunneling to other well-known or reserved ports. A HTTP
2408 client CONNECTing to port 25 could relay spam via SMTP, for example.
2409 As such, proxies SHOULD restrict CONNECT access to a small number of
2410 known ports.
2412 13. Acknowledgments
2414 See Section 9 of [Part1].
2416 14. References
2418 14.1. Normative References
2420 [Part1] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
2421 "HTTP/1.1, part 1: URIs, Connections, and Message
2422 Parsing", draft-ietf-httpbis-p1-messaging-19 (work in
2423 progress), March 2012.
2425 [Part3] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
2426 "HTTP/1.1, part 3: Message Payload and Content
2427 Negotiation", draft-ietf-httpbis-p3-payload-19 (work in
2428 progress), March 2012.
2430 [Part4] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
2431 "HTTP/1.1, part 4: Conditional Requests",
2432 draft-ietf-httpbis-p4-conditional-19 (work in progress),
2433 March 2012.
2435 [Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
2436 "HTTP/1.1, part 5: Range Requests and Partial Responses",
2437 draft-ietf-httpbis-p5-range-19 (work in progress),
2438 March 2012.
2440 [Part6] Fielding, R., Ed., Lafon, Y., Ed., Nottingham, M., Ed.,
2441 and J. Reschke, Ed., "HTTP/1.1, part 6: Caching",
2442 draft-ietf-httpbis-p6-cache-19 (work in progress),
2443 March 2012.
2445 [Part7] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
2446 "HTTP/1.1, part 7: Authentication",
2447 draft-ietf-httpbis-p7-auth-19 (work in progress),
2448 March 2012.
2450 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
2451 Requirement Levels", BCP 14, RFC 2119, March 1997.
2453 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
2454 Resource Identifier (URI): Generic Syntax", STD 66,
2455 RFC 3986, January 2005.
2457 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
2458 Specifications: ABNF", STD 68, RFC 5234, January 2008.
2460 14.2. Informative References
2462 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application
2463 and Support", STD 3, RFC 1123, October 1989.
2465 [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext
2466 Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
2468 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.
2469 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
2470 RFC 2068, January 1997.
2472 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
2473 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
2474 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
2476 [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within
2477 HTTP/1.1", RFC 2817, May 2000.
2479 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
2480 Procedures for Message Header Fields", BCP 90, RFC 3864,
2481 September 2004.
2483 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
2484 IANA Considerations Section in RFCs", BCP 26, RFC 5226,
2485 May 2008.
2487 [RFC5322] Resnick, P., "Internet Message Format", RFC 5322,
2488 October 2008.
2490 [RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP",
2491 RFC 5789, March 2010.
2493 [RFC5987] Reschke, J., "Character Set and Language Encoding for
2494 Hypertext Transfer Protocol (HTTP) Header Field
2495 Parameters", RFC 5987, August 2010.
2497 Appendix A. Changes from RFC 2616
2499 This document takes over the Status Code Registry, previously defined
2500 in Section 7.1 of [RFC2817]. (Section 4.2)
2502 Clarify definition of POST. (Section 6.5)
2504 Remove requirement to handle all Content-* header fields; ban use of
2505 Content-Range with PUT. (Section 6.6)
2507 Take over definition of CONNECT method from [RFC2817]. (Section 6.9)
2509 Broadened the definition of 203 (Non-Authoritative Information) to
2510 include cases of payload transformations as well. (Section 7.2.4)
2512 Status codes 301, 302, and 307: removed the normative requirements on
2513 both response payloads and user interaction. (Section 7.3)
2515 Failed to consider that there are many other request methods that are
2516 safe to automatically redirect, and further that the user agent is
2517 able to make that determination based on the request method
2518 semantics. Furthermore, allow user agents to rewrite the method from
2519 POST to GET for status codes 301 and 302. (Sections 7.3.2, 7.3.3 and
2520 7.3.7)
2522 Deprecate 305 Use Proxy status code, because user agents did not
2523 implement it. It used to indicate that the target resource must be
2524 accessed through the proxy given by the Location field. The Location
2525 field gave the URI of the proxy. The recipient was expected to
2526 repeat this single request via the proxy. (Section 7.3.5)
2527 Define status 426 (Upgrade Required) (this was incorporated from
2528 [RFC2817]). (Section 7.4.15)
2530 Change ABNF productions for header fields to only define the field
2531 value. (Section 10)
2533 Reclassify "Allow" as response header field, removing the option to
2534 specify it in a PUT request. Relax the server requirement on the
2535 contents of the Allow header field and remove requirement on clients
2536 to always trust the header field value. (Section 10.1)
2538 The ABNF for the Expect header field has been both fixed (allowing
2539 parameters for value-less expectations as well) and simplified
2540 (allowing trailing semicolons after "100-continue" when they were
2541 invalid before). (Section 10.3)
2543 Correct syntax of Location header field to allow URI references
2544 (including relative references and fragments), as referred symbol
2545 "absoluteURI" wasn't what was expected, and add some clarifications
2546 as to when use of fragments would not be appropriate. (Section 10.5)
2548 Restrict Max-Forwards header field to OPTIONS and TRACE (previously,
2549 extension methods could have used it as well). (Section 10.6)
2551 Allow Referer field value of "about:blank" as alternative to not
2552 specifying it. (Section 10.7)
2554 In the description of the Server header field, the Via field was
2555 described as a SHOULD. The requirement was and is stated correctly
2556 in the description of the Via header field in Section 6.2 of [Part1].
2557 (Section 10.9)
2559 Appendix B. Collected ABNF
2561 Allow = [ ( "," / method ) *( OWS "," [ OWS method ] ) ]
2563 BWS =
2565 Date = HTTP-date
2567 Expect = *( "," OWS ) expectation *( OWS "," [ OWS expectation ] )
2569 From = mailbox
2571 GMT = %x47.4D.54 ; GMT
2573 HTTP-date = rfc1123-date / obs-date
2574 Location = URI-reference
2576 Max-Forwards = 1*DIGIT
2578 OWS =
2580 RWS =
2581 Referer = absolute-URI / partial-URI
2582 Retry-After = HTTP-date / delta-seconds
2584 Server = product *( RWS ( product / comment ) )
2586 URI-reference =
2587 User-Agent = product *( RWS ( product / comment ) )
2589 absolute-URI =
2590 asctime-date = day-name SP date3 SP time-of-day SP year
2592 comment =
2594 date1 = day SP month SP year
2595 date2 = day "-" month "-" 2DIGIT
2596 date3 = month SP ( 2DIGIT / ( SP DIGIT ) )
2597 day = 2DIGIT
2598 day-name = %x4D.6F.6E ; Mon
2599 / %x54.75.65 ; Tue
2600 / %x57.65.64 ; Wed
2601 / %x54.68.75 ; Thu
2602 / %x46.72.69 ; Fri
2603 / %x53.61.74 ; Sat
2604 / %x53.75.6E ; Sun
2605 day-name-l = %x4D.6F.6E.64.61.79 ; Monday
2606 / %x54.75.65.73.64.61.79 ; Tuesday
2607 / %x57.65.64.6E.65.73.64.61.79 ; Wednesday
2608 / %x54.68.75.72.73.64.61.79 ; Thursday
2609 / %x46.72.69.64.61.79 ; Friday
2610 / %x53.61.74.75.72.64.61.79 ; Saturday
2611 / %x53.75.6E.64.61.79 ; Sunday
2612 delta-seconds = 1*DIGIT
2614 expect-name = token
2615 expect-param = expect-name [ BWS "=" BWS expect-value ]
2616 expect-value = token / quoted-string
2617 expectation = expect-name [ BWS "=" BWS expect-value ] *( OWS ";" [
2618 OWS expect-param ] )
2620 hour = 2DIGIT
2621 mailbox =
2622 method = token
2623 minute = 2DIGIT
2624 month = %x4A.61.6E ; Jan
2625 / %x46.65.62 ; Feb
2626 / %x4D.61.72 ; Mar
2627 / %x41.70.72 ; Apr
2628 / %x4D.61.79 ; May
2629 / %x4A.75.6E ; Jun
2630 / %x4A.75.6C ; Jul
2631 / %x41.75.67 ; Aug
2632 / %x53.65.70 ; Sep
2633 / %x4F.63.74 ; Oct
2634 / %x4E.6F.76 ; Nov
2635 / %x44.65.63 ; Dec
2637 obs-date = rfc850-date / asctime-date
2638 obs-text =
2640 partial-URI =
2641 product = token [ "/" product-version ]
2642 product-version = token
2644 quoted-string =
2646 reason-phrase = *( HTAB / SP / VCHAR / obs-text )
2647 rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT
2648 rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT
2650 second = 2DIGIT
2651 status-code = 3DIGIT
2653 time-of-day = hour ":" minute ":" second
2654 token =
2656 year = 4DIGIT
2657 ABNF diagnostics:
2659 ; Allow defined but not used
2660 ; Date defined but not used
2661 ; Expect defined but not used
2662 ; From defined but not used
2663 ; Location defined but not used
2664 ; Max-Forwards defined but not used
2665 ; Referer defined but not used
2666 ; Retry-After defined but not used
2667 ; Server defined but not used
2668 ; User-Agent defined but not used
2669 ; reason-phrase defined but not used
2670 ; status-code defined but not used
2672 Appendix C. Change Log (to be removed by RFC Editor before publication)
2674 C.1. Since RFC 2616
2676 Extracted relevant partitions from [RFC2616].
2678 C.2. Since draft-ietf-httpbis-p2-semantics-00
2680 Closed issues:
2682 o : "Via is a MUST"
2683 ()
2685 o : "Fragments
2686 allowed in Location"
2687 ()
2689 o : "Safe Methods
2690 vs Redirection" ()
2692 o : "Revise
2693 description of the POST method"
2694 ()
2696 o : "Normative and
2697 Informative references"
2699 o : "RFC2606
2700 Compliance"
2702 o : "Informative
2703 references"
2705 o : "Redundant
2706 cross-references"
2708 Other changes:
2710 o Move definitions of 304 and 412 condition codes to [Part4]
2712 C.3. Since draft-ietf-httpbis-p2-semantics-01
2714 Closed issues:
2716 o : "PUT side
2717 effects"
2719 o : "Duplicate Host
2720 header requirements"
2722 Ongoing work on ABNF conversion
2723 ():
2725 o Move "Product Tokens" section (back) into Part 1, as "token" is
2726 used in the definition of the Upgrade header field.
2728 o Add explicit references to BNF syntax and rules imported from
2729 other parts of the specification.
2731 o Copy definition of delta-seconds from Part6 instead of referencing
2732 it.
2734 C.4. Since draft-ietf-httpbis-p2-semantics-02
2736 Closed issues:
2738 o : "Requiring
2739 Allow in 405 responses"
2741 o : "Status Code
2742 Registry"
2744 o : "Redirection
2745 vs. Location"
2747 o : "Cacheability
2748 of 303 response"
2750 o : "305 Use Proxy"
2751 o :
2752 "Classification for Allow header"
2754 o : "PUT - 'store
2755 under' vs 'store at'"
2757 Ongoing work on IANA Message Header Field Registration
2758 ():
2760 o Reference RFC 3984, and update header field registrations for
2761 headers defined in this document.
2763 Ongoing work on ABNF conversion
2764 ():
2766 o Replace string literals when the string really is case-sensitive
2767 (method).
2769 C.5. Since draft-ietf-httpbis-p2-semantics-03
2771 Closed issues:
2773 o : "OPTIONS
2774 request bodies"
2776 o : "Description
2777 of CONNECT should refer to RFC2817"
2779 o : "Location
2780 Content-Location reference request/response mixup"
2782 Ongoing work on Method Registry
2783 ():
2785 o Added initial proposal for registration process, plus initial
2786 content (non-HTTP/1.1 methods to be added by a separate
2787 specification).
2789 C.6. Since draft-ietf-httpbis-p2-semantics-04
2791 Closed issues:
2793 o : "Content-*"
2795 o : "RFC 2822 is
2796 updated by RFC 5322"
2798 Ongoing work on ABNF conversion
2799 ():
2801 o Use "/" instead of "|" for alternatives.
2803 o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
2804 whitespace ("OWS") and required whitespace ("RWS").
2806 o Rewrite ABNFs to spell out whitespace rules, factor out header
2807 field value format definitions.
2809 C.7. Since draft-ietf-httpbis-p2-semantics-05
2811 Closed issues:
2813 o : "reason-phrase
2814 BNF"
2816 Final work on ABNF conversion
2817 ():
2819 o Add appendix containing collected and expanded ABNF, reorganize
2820 ABNF introduction.
2822 C.8. Since draft-ietf-httpbis-p2-semantics-06
2824 Closed issues:
2826 o : "Clarify when
2827 Referer is sent"
2829 o : "status codes
2830 vs methods"
2832 o : "Do not
2833 require "updates" relation for specs that register status codes or
2834 method names"
2836 C.9. Since draft-ietf-httpbis-p2-semantics-07
2838 Closed issues:
2840 o : "Idempotency"
2842 o : "TRACE security
2843 considerations"
2845 o : "Clarify rules
2846 for determining what entities a response carries"
2848 o : "update note
2849 citing RFC 1945 and 2068"
2851 o : "update note
2852 about redirect limit"
2854 o : "Location
2855 header ABNF should use 'URI'"
2857 o : "fragments in
2858 Location vs status 303"
2860 o : "move IANA
2861 registrations for optional status codes"
2863 Partly resolved issues:
2865 o : "Are OPTIONS
2866 and TRACE safe?"
2868 C.10. Since draft-ietf-httpbis-p2-semantics-08
2870 Closed issues:
2872 o : "Safe Methods
2873 vs Redirection" (we missed the introduction to the 3xx status
2874 codes when fixing this previously)
2876 C.11. Since draft-ietf-httpbis-p2-semantics-09
2878 Closed issues:
2880 o : "Fragment
2881 combination / precedence during redirects"
2883 Partly resolved issues:
2885 o : "Location
2886 header payload handling"
2888 o : "Term for the
2889 requested resource's URI"
2891 C.12. Since draft-ietf-httpbis-p2-semantics-10
2893 Closed issues:
2895 o : "Clarify
2896 'Requested Variant'"
2898 o : "Clarify
2899 entity / representation / variant terminology"
2901 o : "Methods and
2902 Caching"
2904 o : "OPTIONS vs
2905 Max-Forwards"
2907 o : "Status codes
2908 and caching"
2910 o : "consider
2911 removing the 'changes from 2068' sections"
2913 C.13. Since draft-ietf-httpbis-p2-semantics-11
2915 Closed issues:
2917 o :
2918 "Considerations for new status codes"
2920 o :
2921 "Considerations for new methods"
2923 o : "User-Agent
2924 guidelines" (relating to the 'User-Agent' header field)
2926 C.14. Since draft-ietf-httpbis-p2-semantics-12
2928 Closed issues:
2930 o : "Fragment
2931 combination / precedence during redirects" (added warning about
2932 having a fragid on the redirect may cause inconvenience in some
2933 cases)
2935 o : "Content-* vs.
2936 PUT"
2938 o : "205 Bodies"
2940 o : "Understanding
2941 Content-* on non-PUT requests"
2943 o : "Content-*"
2945 o : "Header type
2946 defaulting"
2948 o : "PUT - 'store
2949 under' vs 'store at'"
2951 o : "duplicate
2952 ABNF for reason-phrase"
2954 o : "Note special
2955 status of Content-* prefix in header registration procedures"
2957 o : "Max-Forwards
2958 vs extension methods"
2960 o : "What is the
2961 value space of HTTP status codes?" (actually fixed in
2962 draft-ietf-httpbis-p2-semantics-11)
2964 o : "Header
2965 Classification"
2967 o : "PUT side
2968 effect: invalidation or just stale?"
2970 o : "proxies not
2971 supporting certain methods"
2973 o : "Migrate
2974 CONNECT from RFC2817 to p2"
2976 o : "Migrate
2977 Upgrade details from RFC2817"
2979 o : "clarify PUT
2980 semantics'"
2982 o : "duplicate
2983 ABNF for 'Method'"
2985 o : "untangle
2986 ABNFs for header fields"
2988 C.15. Since draft-ietf-httpbis-p2-semantics-13
2990 Closed issues:
2992 o : "untangle
2993 ABNFs for header fields"
2995 o : "message body
2996 in CONNECT request"
2998 C.16. Since draft-ietf-httpbis-p2-semantics-14
3000 Closed issues:
3002 o : "Clarify
3003 status code for rate limiting"
3005 o : "clarify 403
3006 forbidden"
3008 o : "Clarify 203
3009 Non-Authoritative Information"
3011 o : "update
3012 default reason phrase for 413"
3014 C.17. Since draft-ietf-httpbis-p2-semantics-15
3016 Closed issues:
3018 o : "Strength of
3019 requirements on Accept re: 406"
3021 o : "400 response
3022 isn't generic"
3024 C.18. Since draft-ietf-httpbis-p2-semantics-16
3026 Closed issues:
3028 o : "Redirects and
3029 non-GET methods"
3031 o : "Document
3032 HTTP's error-handling philosophy"
3034 o :
3035 "Considerations for new headers"
3037 o : "clarify 303
3038 redirect on HEAD"
3040 C.19. Since draft-ietf-httpbis-p2-semantics-17
3042 Closed issues:
3044 o : "Location
3045 header payload handling"
3047 o : "Clarify
3048 status code for rate limiting" (change backed out because a new
3049 status code is being defined for this purpose)
3051 o : "should there
3052 be a permanent variant of 307"
3054 o : "When are
3055 Location's semantics triggered?"
3057 o : "'expect'
3058 grammar missing OWS"
3060 o : "header field
3061 considerations: quoted-string vs use of double quotes"
3063 C.20. Since draft-ietf-httpbis-p2-semantics-18
3065 Closed issues:
3067 o : "Combining
3068 HEAD responses"
3070 o : "Requirements
3071 for user intervention during redirects"
3073 o : "message-body
3074 in CONNECT response"
3076 o : "Applying
3077 original fragment to 'plain' redirected URI"
3079 o : "Misplaced
3080 text on connection handling in p2"
3082 o : "clarify that
3083 201 doesn't require Location header fields"
3085 o : "relax
3086 requirements on hypertext in 3/4/5xx error responses"
3088 o : "example for
3089 426 response should have a payload"
3091 o : "drop
3092 indirection entries for status codes"
3094 Index
3096 1
3097 100 Continue (status code) 26
3098 100-continue (expect value) 44
3099 101 Switching Protocols (status code) 27
3101 2
3102 200 OK (status code) 27
3103 201 Created (status code) 27
3104 202 Accepted (status code) 28
3105 203 Non-Authoritative Information (status code) 28
3106 204 No Content (status code) 28
3107 205 Reset Content (status code) 29
3109 3
3110 300 Multiple Choices (status code) 31
3111 301 Moved Permanently (status code) 31
3112 302 Found (status code) 32
3113 303 See Other (status code) 32
3114 305 Use Proxy (status code) 33
3115 306 (Unused) (status code) 33
3116 307 Temporary Redirect (status code) 33
3118 4
3119 400 Bad Request (status code) 33
3120 402 Payment Required (status code) 33
3121 403 Forbidden (status code) 33
3122 404 Not Found (status code) 34
3123 405 Method Not Allowed (status code) 34
3124 406 Not Acceptable (status code) 34
3125 408 Request Timeout (status code) 35
3126 409 Conflict (status code) 35
3127 410 Gone (status code) 35
3128 411 Length Required (status code) 36
3129 413 Request Representation Too Large (status code) 36
3130 414 URI Too Long (status code) 36
3131 415 Unsupported Media Type (status code) 36
3132 417 Expectation Failed (status code) 36
3133 426 Upgrade Required (status code) 37
3135 5
3136 500 Internal Server Error (status code) 37
3137 501 Not Implemented (status code) 37
3138 502 Bad Gateway (status code) 37
3139 503 Service Unavailable (status code) 38
3140 504 Gateway Timeout (status code) 38
3141 505 HTTP Version Not Supported (status code) 38
3143 A
3144 Allow header field 42
3146 C
3147 CONNECT method 24
3149 D
3150 Date header field 42
3151 DELETE method 23
3153 E
3154 Expect header field 43
3155 Expect Values
3156 100-continue 44
3158 F
3159 From header field 44
3161 G
3162 GET method 19
3163 Grammar
3164 Allow 42
3165 asctime-date 41
3166 Date 42
3167 date1 40
3168 day 40
3169 day-name 40
3170 day-name-l 40
3171 delta-seconds 47
3172 Expect 43
3173 expect-name 43
3174 expect-param 43
3175 expect-value 43
3176 expectation 43
3177 extension-code 12
3178 From 44
3179 GMT 40
3180 hour 40
3181 HTTP-date 39
3182 Location 45
3183 Max-Forwards 46
3184 method 7
3185 minute 40
3186 month 40
3187 obs-date 40
3188 product 41
3189 product-version 41
3190 reason-phrase 12
3191 Referer 47
3192 Retry-After 47
3193 rfc850-date 41
3194 rfc1123-date 40
3195 second 40
3196 Server 47
3197 status-code 12
3198 time-of-day 40
3199 User-Agent 48
3200 year 40
3202 H
3203 HEAD method 19
3204 Header Fields
3205 Allow 42
3206 Date 42
3207 Expect 43
3208 From 44
3209 Location 45
3210 Max-Forwards 46
3211 Referer 46
3212 Retry-After 47
3213 Server 47
3214 User-Agent 48
3216 I
3217 Idempotent Methods 17
3219 L
3220 Location header field 45
3222 M
3223 Max-Forwards header field 46
3224 Methods
3225 CONNECT 24
3226 DELETE 23
3227 GET 19
3228 HEAD 19
3229 OPTIONS 18
3230 POST 20
3231 PUT 21
3232 TRACE 23
3234 O
3235 OPTIONS method 18
3237 P
3238 POST method 20
3239 PUT method 21
3241 R
3242 Referer header field 46
3243 Retry-After header field 47
3245 S
3246 Safe Methods 17
3247 Server header field 47
3248 Status Codes
3249 100 Continue 26
3250 101 Switching Protocols 27
3251 200 OK 27
3252 201 Created 27
3253 202 Accepted 28
3254 203 Non-Authoritative Information 28
3255 204 No Content 28
3256 205 Reset Content 29
3257 300 Multiple Choices 31
3258 301 Moved Permanently 31
3259 302 Found 32
3260 303 See Other 32
3261 305 Use Proxy 33
3262 306 (Unused) 33
3263 307 Temporary Redirect 33
3264 400 Bad Request 33
3265 402 Payment Required 33
3266 403 Forbidden 33
3267 404 Not Found 34
3268 405 Method Not Allowed 34
3269 406 Not Acceptable 34
3270 408 Request Timeout 35
3271 409 Conflict 35
3272 410 Gone 35
3273 411 Length Required 36
3274 413 Request Representation Too Large 36
3275 414 URI Too Long 36
3276 415 Unsupported Media Type 36
3277 417 Expectation Failed 36
3278 426 Upgrade Required 37
3279 500 Internal Server Error 37
3280 501 Not Implemented 37
3281 502 Bad Gateway 37
3282 503 Service Unavailable 38
3283 504 Gateway Timeout 38
3284 505 HTTP Version Not Supported 38
3286 T
3287 TRACE method 23
3289 U
3290 User-Agent header field 48
3292 Authors' Addresses
3294 Roy T. Fielding (editor)
3295 Adobe Systems Incorporated
3296 345 Park Ave
3297 San Jose, CA 95110
3298 USA
3300 EMail: fielding@gbiv.com
3301 URI: http://roy.gbiv.com/
3303 Yves Lafon (editor)
3304 World Wide Web Consortium
3305 W3C / ERCIM
3306 2004, rte des Lucioles
3307 Sophia-Antipolis, AM 06902
3308 France
3310 EMail: ylafon@w3.org
3311 URI: http://www.raubacapeu.net/people/yves/
3312 Julian F. Reschke (editor)
3313 greenbytes GmbH
3314 Hafenweg 16
3315 Muenster, NW 48155
3316 Germany
3318 Phone: +49 251 2807760
3319 Fax: +49 251 2807761
3320 EMail: julian.reschke@greenbytes.de
3321 URI: http://greenbytes.de/tech/webdav/