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