1 | |
---|
2 | |
---|
3 | |
---|
4 | HTTPbis Working Group R. Fielding, Ed. |
---|
5 | Internet-Draft Adobe |
---|
6 | Obsoletes: 2616 (if approved) J. Reschke, Ed. |
---|
7 | Updates: 2817 (if approved) greenbytes |
---|
8 | Intended status: Standards Track October 4, 2012 |
---|
9 | Expires: April 7, 2013 |
---|
10 | |
---|
11 | |
---|
12 | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content |
---|
13 | draft-ietf-httpbis-p2-semantics-21 |
---|
14 | |
---|
15 | Abstract |
---|
16 | |
---|
17 | The Hypertext Transfer Protocol (HTTP) is an application-level |
---|
18 | protocol for distributed, collaborative, hypertext information |
---|
19 | systems. This document defines the semantics of HTTP/1.1 messages, |
---|
20 | as expressed by request methods, request header fields, response |
---|
21 | status codes, and response header fields, along with the payload of |
---|
22 | messages (metadata and body content) and mechanisms for content |
---|
23 | negotiation. |
---|
24 | |
---|
25 | Editorial Note (To be removed by RFC Editor) |
---|
26 | |
---|
27 | Discussion of this draft takes place on the HTTPBIS working group |
---|
28 | mailing list (ietf-http-wg@w3.org), which is archived at |
---|
29 | <http://lists.w3.org/Archives/Public/ietf-http-wg/>. |
---|
30 | |
---|
31 | The current issues list is at |
---|
32 | <http://tools.ietf.org/wg/httpbis/trac/report/3> and related |
---|
33 | documents (including fancy diffs) can be found at |
---|
34 | <http://tools.ietf.org/wg/httpbis/>. |
---|
35 | |
---|
36 | The changes in this draft are summarized in Appendix F.41. |
---|
37 | |
---|
38 | Status of This Memo |
---|
39 | |
---|
40 | This Internet-Draft is submitted in full conformance with the |
---|
41 | provisions of BCP 78 and BCP 79. |
---|
42 | |
---|
43 | Internet-Drafts are working documents of the Internet Engineering |
---|
44 | Task Force (IETF). Note that other groups may also distribute |
---|
45 | working documents as Internet-Drafts. The list of current Internet- |
---|
46 | Drafts is at http://datatracker.ietf.org/drafts/current/. |
---|
47 | |
---|
48 | Internet-Drafts are draft documents valid for a maximum of six months |
---|
49 | and may be updated, replaced, or obsoleted by other documents at any |
---|
50 | time. It is inappropriate to use Internet-Drafts as reference |
---|
51 | material or to cite them other than as "work in progress." |
---|
52 | |
---|
53 | |
---|
54 | |
---|
55 | Fielding & Reschke Expires April 7, 2013 [Page 1] |
---|
56 | |
---|
57 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
58 | |
---|
59 | |
---|
60 | This Internet-Draft will expire on April 7, 2013. |
---|
61 | |
---|
62 | Copyright Notice |
---|
63 | |
---|
64 | Copyright (c) 2012 IETF Trust and the persons identified as the |
---|
65 | document authors. All rights reserved. |
---|
66 | |
---|
67 | This document is subject to BCP 78 and the IETF Trust's Legal |
---|
68 | Provisions Relating to IETF Documents |
---|
69 | (http://trustee.ietf.org/license-info) in effect on the date of |
---|
70 | publication of this document. Please review these documents |
---|
71 | carefully, as they describe your rights and restrictions with respect |
---|
72 | to this document. Code Components extracted from this document must |
---|
73 | include Simplified BSD License text as described in Section 4.e of |
---|
74 | the Trust Legal Provisions and are provided without warranty as |
---|
75 | described in the Simplified BSD License. |
---|
76 | |
---|
77 | This document may contain material from IETF Documents or IETF |
---|
78 | Contributions published or made publicly available before November |
---|
79 | 10, 2008. The person(s) controlling the copyright in some of this |
---|
80 | material may not have granted the IETF Trust the right to allow |
---|
81 | modifications of such material outside the IETF Standards Process. |
---|
82 | Without obtaining an adequate license from the person(s) controlling |
---|
83 | the copyright in such materials, this document may not be modified |
---|
84 | outside the IETF Standards Process, and derivative works of it may |
---|
85 | not be created outside the IETF Standards Process, except to format |
---|
86 | it for publication as an RFC or to translate it into languages other |
---|
87 | than English. |
---|
88 | |
---|
89 | Table of Contents |
---|
90 | |
---|
91 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 |
---|
92 | 1.1. Conformance and Error Handling . . . . . . . . . . . . . 7 |
---|
93 | 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7 |
---|
94 | 2. Resource . . . . . . . . . . . . . . . . . . . . . . . . . . 8 |
---|
95 | 3. Representation . . . . . . . . . . . . . . . . . . . . . . . 8 |
---|
96 | 3.1. Representation Metadata . . . . . . . . . . . . . . . . . 8 |
---|
97 | 3.1.1. Data Type . . . . . . . . . . . . . . . . . . . . . . 9 |
---|
98 | 3.1.2. Data Encoding . . . . . . . . . . . . . . . . . . . . 12 |
---|
99 | 3.1.3. Audience Language . . . . . . . . . . . . . . . . . . 14 |
---|
100 | 3.1.4. Identification . . . . . . . . . . . . . . . . . . . 15 |
---|
101 | 3.2. Representation Data . . . . . . . . . . . . . . . . . . . 18 |
---|
102 | 3.3. Payload Semantics . . . . . . . . . . . . . . . . . . . . 18 |
---|
103 | 3.4. Content Negotiation . . . . . . . . . . . . . . . . . . . 19 |
---|
104 | 3.4.1. Proactive Negotiation . . . . . . . . . . . . . . . . 20 |
---|
105 | 3.4.2. Reactive Negotiation . . . . . . . . . . . . . . . . 21 |
---|
106 | 4. Product Tokens . . . . . . . . . . . . . . . . . . . . . . . 22 |
---|
107 | 5. Request Methods . . . . . . . . . . . . . . . . . . . . . . . 22 |
---|
108 | |
---|
109 | |
---|
110 | |
---|
111 | Fielding & Reschke Expires April 7, 2013 [Page 2] |
---|
112 | |
---|
113 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
114 | |
---|
115 | |
---|
116 | 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 22 |
---|
117 | 5.2. Common Method Properties . . . . . . . . . . . . . . . . 24 |
---|
118 | 5.2.1. Safe Methods . . . . . . . . . . . . . . . . . . . . 24 |
---|
119 | 5.2.2. Idempotent Methods . . . . . . . . . . . . . . . . . 25 |
---|
120 | 5.2.3. Cacheable Methods . . . . . . . . . . . . . . . . . . 25 |
---|
121 | 5.3. Method Definitions . . . . . . . . . . . . . . . . . . . 25 |
---|
122 | 5.3.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 25 |
---|
123 | 5.3.2. HEAD . . . . . . . . . . . . . . . . . . . . . . . . 26 |
---|
124 | 5.3.3. POST . . . . . . . . . . . . . . . . . . . . . . . . 27 |
---|
125 | 5.3.4. PUT . . . . . . . . . . . . . . . . . . . . . . . . . 28 |
---|
126 | 5.3.5. DELETE . . . . . . . . . . . . . . . . . . . . . . . 30 |
---|
127 | 5.3.6. CONNECT . . . . . . . . . . . . . . . . . . . . . . . 30 |
---|
128 | 5.3.7. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . 32 |
---|
129 | 5.3.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . 33 |
---|
130 | 6. Request Header Fields . . . . . . . . . . . . . . . . . . . . 33 |
---|
131 | 6.1. Controls . . . . . . . . . . . . . . . . . . . . . . . . 33 |
---|
132 | 6.1.1. Max-Forwards . . . . . . . . . . . . . . . . . . . . 34 |
---|
133 | 6.1.2. Expect . . . . . . . . . . . . . . . . . . . . . . . 34 |
---|
134 | 6.2. Conditionals . . . . . . . . . . . . . . . . . . . . . . 37 |
---|
135 | 6.3. Content Negotiation . . . . . . . . . . . . . . . . . . . 38 |
---|
136 | 6.3.1. Quality Values . . . . . . . . . . . . . . . . . . . 38 |
---|
137 | 6.3.2. Accept . . . . . . . . . . . . . . . . . . . . . . . 38 |
---|
138 | 6.3.3. Accept-Charset . . . . . . . . . . . . . . . . . . . 41 |
---|
139 | 6.3.4. Accept-Encoding . . . . . . . . . . . . . . . . . . . 41 |
---|
140 | 6.3.5. Accept-Language . . . . . . . . . . . . . . . . . . . 42 |
---|
141 | 6.4. Authentication Credentials . . . . . . . . . . . . . . . 44 |
---|
142 | 6.5. Context . . . . . . . . . . . . . . . . . . . . . . . . . 44 |
---|
143 | 6.5.1. From . . . . . . . . . . . . . . . . . . . . . . . . 44 |
---|
144 | 6.5.2. Referer . . . . . . . . . . . . . . . . . . . . . . . 45 |
---|
145 | 6.5.3. User-Agent . . . . . . . . . . . . . . . . . . . . . 45 |
---|
146 | 7. Response Status Codes . . . . . . . . . . . . . . . . . . . . 46 |
---|
147 | 7.1. Overview of Status Codes . . . . . . . . . . . . . . . . 47 |
---|
148 | 7.2. Informational 1xx . . . . . . . . . . . . . . . . . . . . 49 |
---|
149 | 7.2.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 49 |
---|
150 | 7.2.2. 101 Switching Protocols . . . . . . . . . . . . . . . 49 |
---|
151 | 7.3. Successful 2xx . . . . . . . . . . . . . . . . . . . . . 50 |
---|
152 | 7.3.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 50 |
---|
153 | 7.3.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 50 |
---|
154 | 7.3.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . 51 |
---|
155 | 7.3.4. 203 Non-Authoritative Information . . . . . . . . . . 51 |
---|
156 | 7.3.5. 204 No Content . . . . . . . . . . . . . . . . . . . 51 |
---|
157 | 7.3.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 52 |
---|
158 | 7.4. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 52 |
---|
159 | 7.4.1. 300 Multiple Choices . . . . . . . . . . . . . . . . 54 |
---|
160 | 7.4.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 54 |
---|
161 | 7.4.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 55 |
---|
162 | 7.4.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 55 |
---|
163 | 7.4.5. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 56 |
---|
164 | |
---|
165 | |
---|
166 | |
---|
167 | Fielding & Reschke Expires April 7, 2013 [Page 3] |
---|
168 | |
---|
169 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
170 | |
---|
171 | |
---|
172 | 7.4.6. 306 (Unused) . . . . . . . . . . . . . . . . . . . . 56 |
---|
173 | 7.4.7. 307 Temporary Redirect . . . . . . . . . . . . . . . 56 |
---|
174 | 7.5. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 56 |
---|
175 | 7.5.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 56 |
---|
176 | 7.5.2. 402 Payment Required . . . . . . . . . . . . . . . . 56 |
---|
177 | 7.5.3. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 57 |
---|
178 | 7.5.4. 404 Not Found . . . . . . . . . . . . . . . . . . . . 57 |
---|
179 | 7.5.5. 405 Method Not Allowed . . . . . . . . . . . . . . . 57 |
---|
180 | 7.5.6. 406 Not Acceptable . . . . . . . . . . . . . . . . . 57 |
---|
181 | 7.5.7. 408 Request Timeout . . . . . . . . . . . . . . . . . 58 |
---|
182 | 7.5.8. 409 Conflict . . . . . . . . . . . . . . . . . . . . 58 |
---|
183 | 7.5.9. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 58 |
---|
184 | 7.5.10. 411 Length Required . . . . . . . . . . . . . . . . . 59 |
---|
185 | 7.5.11. 413 Request Representation Too Large . . . . . . . . 59 |
---|
186 | 7.5.12. 414 URI Too Long . . . . . . . . . . . . . . . . . . 59 |
---|
187 | 7.5.13. 415 Unsupported Media Type . . . . . . . . . . . . . 59 |
---|
188 | 7.5.14. 417 Expectation Failed . . . . . . . . . . . . . . . 60 |
---|
189 | 7.5.15. 426 Upgrade Required . . . . . . . . . . . . . . . . 60 |
---|
190 | 7.6. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 60 |
---|
191 | 7.6.1. 500 Internal Server Error . . . . . . . . . . . . . . 60 |
---|
192 | 7.6.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 60 |
---|
193 | 7.6.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 61 |
---|
194 | 7.6.4. 503 Service Unavailable . . . . . . . . . . . . . . . 61 |
---|
195 | 7.6.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 61 |
---|
196 | 7.6.6. 505 HTTP Version Not Supported . . . . . . . . . . . 61 |
---|
197 | 8. Response Header Fields . . . . . . . . . . . . . . . . . . . 61 |
---|
198 | 8.1. Control Data . . . . . . . . . . . . . . . . . . . . . . 62 |
---|
199 | 8.1.1. Origination Date . . . . . . . . . . . . . . . . . . 62 |
---|
200 | 8.1.2. Location . . . . . . . . . . . . . . . . . . . . . . 65 |
---|
201 | 8.1.3. Retry-After . . . . . . . . . . . . . . . . . . . . . 66 |
---|
202 | 8.2. Selected Representation Header Fields . . . . . . . . . . 67 |
---|
203 | 8.2.1. Vary . . . . . . . . . . . . . . . . . . . . . . . . 67 |
---|
204 | 8.3. Authentication Challenges . . . . . . . . . . . . . . . . 68 |
---|
205 | 8.4. Informative . . . . . . . . . . . . . . . . . . . . . . . 68 |
---|
206 | 8.4.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . 69 |
---|
207 | 8.4.2. Server . . . . . . . . . . . . . . . . . . . . . . . 69 |
---|
208 | 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 70 |
---|
209 | 9.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 70 |
---|
210 | 9.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 70 |
---|
211 | 9.1.2. Considerations for New Methods . . . . . . . . . . . 70 |
---|
212 | 9.1.3. Registrations . . . . . . . . . . . . . . . . . . . . 71 |
---|
213 | 9.2. Status Code Registry . . . . . . . . . . . . . . . . . . 71 |
---|
214 | 9.2.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 71 |
---|
215 | 9.2.2. Considerations for New Status Codes . . . . . . . . . 71 |
---|
216 | 9.2.3. Registrations . . . . . . . . . . . . . . . . . . . . 72 |
---|
217 | 9.3. Header Field Registry . . . . . . . . . . . . . . . . . . 73 |
---|
218 | 9.3.1. Considerations for New Header Fields . . . . . . . . 74 |
---|
219 | 9.3.2. Registrations . . . . . . . . . . . . . . . . . . . . 75 |
---|
220 | |
---|
221 | |
---|
222 | |
---|
223 | Fielding & Reschke Expires April 7, 2013 [Page 4] |
---|
224 | |
---|
225 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
226 | |
---|
227 | |
---|
228 | 9.4. Content Coding Registry . . . . . . . . . . . . . . . . . 76 |
---|
229 | 9.4.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 76 |
---|
230 | 9.4.2. Registrations . . . . . . . . . . . . . . . . . . . . 77 |
---|
231 | 10. Security Considerations . . . . . . . . . . . . . . . . . . . 77 |
---|
232 | 10.1. Transfer of Sensitive Information . . . . . . . . . . . . 77 |
---|
233 | 10.2. Encoding Sensitive Information in URIs . . . . . . . . . 78 |
---|
234 | 10.3. Location Header Fields: Spoofing and Information |
---|
235 | Leakage . . . . . . . . . . . . . . . . . . . . . . . . . 79 |
---|
236 | 10.4. Security Considerations for CONNECT . . . . . . . . . . . 79 |
---|
237 | 10.5. Privacy Issues Connected to Accept Header Fields . . . . 79 |
---|
238 | 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 80 |
---|
239 | 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 80 |
---|
240 | 12.1. Normative References . . . . . . . . . . . . . . . . . . 80 |
---|
241 | 12.2. Informative References . . . . . . . . . . . . . . . . . 81 |
---|
242 | Appendix A. Differences between HTTP and MIME . . . . . . . . . 83 |
---|
243 | A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . 84 |
---|
244 | A.2. Conversion to Canonical Form . . . . . . . . . . . . . . 84 |
---|
245 | A.3. Conversion of Date Formats . . . . . . . . . . . . . . . 84 |
---|
246 | A.4. Introduction of Content-Encoding . . . . . . . . . . . . 85 |
---|
247 | A.5. No Content-Transfer-Encoding . . . . . . . . . . . . . . 85 |
---|
248 | A.6. MHTML and Line Length Limitations . . . . . . . . . . . . 85 |
---|
249 | Appendix B. Additional Features . . . . . . . . . . . . . . . . 85 |
---|
250 | Appendix C. Changes from RFC 2616 . . . . . . . . . . . . . . . 86 |
---|
251 | Appendix D. Imported ABNF . . . . . . . . . . . . . . . . . . . 88 |
---|
252 | Appendix E. Collected ABNF . . . . . . . . . . . . . . . . . . . 88 |
---|
253 | Appendix F. Change Log (to be removed by RFC Editor before |
---|
254 | publication) . . . . . . . . . . . . . . . . . . . . 91 |
---|
255 | F.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . 91 |
---|
256 | F.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . 91 |
---|
257 | F.3. Since draft-ietf-httpbis-p3-payload-00 . . . . . . . . . 92 |
---|
258 | F.4. Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . 93 |
---|
259 | F.5. Since draft-ietf-httpbis-p3-payload-01 . . . . . . . . . 93 |
---|
260 | F.6. Since draft-ietf-httpbis-p2-semantics-02 . . . . . . . . 93 |
---|
261 | F.7. Since draft-ietf-httpbis-p3-payload-02 . . . . . . . . . 94 |
---|
262 | F.8. Since draft-ietf-httpbis-p2-semantics-03 . . . . . . . . 95 |
---|
263 | F.9. Since draft-ietf-httpbis-p3-payload-03 . . . . . . . . . 95 |
---|
264 | F.10. Since draft-ietf-httpbis-p2-semantics-04 . . . . . . . . 95 |
---|
265 | F.11. Since draft-ietf-httpbis-p3-payload-04 . . . . . . . . . 96 |
---|
266 | F.12. Since draft-ietf-httpbis-p2-semantics-05 . . . . . . . . 96 |
---|
267 | F.13. Since draft-ietf-httpbis-p3-payload-05 . . . . . . . . . 96 |
---|
268 | F.14. Since draft-ietf-httpbis-p2-semantics-06 . . . . . . . . 97 |
---|
269 | F.15. Since draft-ietf-httpbis-p3-payload-06 . . . . . . . . . 97 |
---|
270 | F.16. Since draft-ietf-httpbis-p2-semantics-07 . . . . . . . . 97 |
---|
271 | F.17. Since draft-ietf-httpbis-p3-payload-07 . . . . . . . . . 98 |
---|
272 | F.18. Since draft-ietf-httpbis-p2-semantics-08 . . . . . . . . 99 |
---|
273 | F.19. Since draft-ietf-httpbis-p3-payload-08 . . . . . . . . . 99 |
---|
274 | F.20. Since draft-ietf-httpbis-p2-semantics-09 . . . . . . . . 99 |
---|
275 | F.21. Since draft-ietf-httpbis-p3-payload-09 . . . . . . . . . 99 |
---|
276 | |
---|
277 | |
---|
278 | |
---|
279 | Fielding & Reschke Expires April 7, 2013 [Page 5] |
---|
280 | |
---|
281 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
282 | |
---|
283 | |
---|
284 | F.22. Since draft-ietf-httpbis-p2-semantics-10 . . . . . . . . 100 |
---|
285 | F.23. Since draft-ietf-httpbis-p3-payload-10 . . . . . . . . . 100 |
---|
286 | F.24. Since draft-ietf-httpbis-p2-semantics-11 . . . . . . . . 101 |
---|
287 | F.25. Since draft-ietf-httpbis-p3-payload-11 . . . . . . . . . 101 |
---|
288 | F.26. Since draft-ietf-httpbis-p2-semantics-12 . . . . . . . . 101 |
---|
289 | F.27. Since draft-ietf-httpbis-p3-payload-12 . . . . . . . . . 103 |
---|
290 | F.28. Since draft-ietf-httpbis-p2-semantics-13 . . . . . . . . 103 |
---|
291 | F.29. Since draft-ietf-httpbis-p3-payload-13 . . . . . . . . . 103 |
---|
292 | F.30. Since draft-ietf-httpbis-p2-semantics-14 . . . . . . . . 103 |
---|
293 | F.31. Since draft-ietf-httpbis-p3-payload-14 . . . . . . . . . 104 |
---|
294 | F.32. Since draft-ietf-httpbis-p2-semantics-15 . . . . . . . . 104 |
---|
295 | F.33. Since draft-ietf-httpbis-p3-payload-15 . . . . . . . . . 104 |
---|
296 | F.34. Since draft-ietf-httpbis-p2-semantics-16 . . . . . . . . 104 |
---|
297 | F.35. Since draft-ietf-httpbis-p3-payload-16 . . . . . . . . . 104 |
---|
298 | F.36. Since draft-ietf-httpbis-p2-semantics-17 . . . . . . . . 105 |
---|
299 | F.37. Since draft-ietf-httpbis-p3-payload-17 . . . . . . . . . 105 |
---|
300 | F.38. Since draft-ietf-httpbis-p2-semantics-18 . . . . . . . . 105 |
---|
301 | F.39. Since draft-ietf-httpbis-p3-payload-18 . . . . . . . . . 106 |
---|
302 | F.40. Since draft-ietf-httpbis-p2-semantics-19 and |
---|
303 | draft-ietf-httpbis-p3-payload-19 . . . . . . . . . . . . 106 |
---|
304 | F.41. Since draft-ietf-httpbis-p2-semantics-20 . . . . . . . . 107 |
---|
305 | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 |
---|
306 | |
---|
307 | |
---|
308 | |
---|
309 | |
---|
310 | |
---|
311 | |
---|
312 | |
---|
313 | |
---|
314 | |
---|
315 | |
---|
316 | |
---|
317 | |
---|
318 | |
---|
319 | |
---|
320 | |
---|
321 | |
---|
322 | |
---|
323 | |
---|
324 | |
---|
325 | |
---|
326 | |
---|
327 | |
---|
328 | |
---|
329 | |
---|
330 | |
---|
331 | |
---|
332 | |
---|
333 | |
---|
334 | |
---|
335 | Fielding & Reschke Expires April 7, 2013 [Page 6] |
---|
336 | |
---|
337 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
338 | |
---|
339 | |
---|
340 | 1. Introduction |
---|
341 | |
---|
342 | Each Hypertext Transfer Protocol (HTTP) message is either a request |
---|
343 | or a response. A server listens on a connection for a request, |
---|
344 | parses each message received, interprets the message semantics in |
---|
345 | relation to the identified request target, and responds to that |
---|
346 | request with one or more response messages. A client constructs |
---|
347 | request messages to communicate specific intentions, and examines |
---|
348 | received responses to see if the intentions were carried out and |
---|
349 | determine how to interpret the results. This document defines |
---|
350 | HTTP/1.1 request and response semantics in terms of the architecture |
---|
351 | defined in [Part1]. |
---|
352 | |
---|
353 | HTTP provides a uniform interface for interacting with a resource |
---|
354 | (Section 2), regardless of its type, nature, or implementation, and |
---|
355 | for transferring content in message payloads in the form of a |
---|
356 | representation (Section 3). |
---|
357 | |
---|
358 | HTTP semantics include the intentions defined by each request method |
---|
359 | (Section 5), extensions to those semantics that might be described in |
---|
360 | request header fields (Section 6), the meaning of status codes to |
---|
361 | indicate a machine-readable response (Section 7), and the meaning of |
---|
362 | other control data and resource metadata that might be given in |
---|
363 | response header fields (Section 8). |
---|
364 | |
---|
365 | This document also defines representation metadata that describe how |
---|
366 | a payload is intended to be interpreted by a recipient, the request |
---|
367 | header fields that might influence content selection, and the various |
---|
368 | selection algorithms that are collectively referred to as "content |
---|
369 | negotiation" (Section 3.4). |
---|
370 | |
---|
371 | 1.1. Conformance and Error Handling |
---|
372 | |
---|
373 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |
---|
374 | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |
---|
375 | document are to be interpreted as described in [RFC2119]. |
---|
376 | |
---|
377 | Conformance criteria and considerations regarding error handling are |
---|
378 | defined in Section 2.5 of [Part1]. |
---|
379 | |
---|
380 | 1.2. Syntax Notation |
---|
381 | |
---|
382 | This specification uses the Augmented Backus-Naur Form (ABNF) |
---|
383 | notation of [RFC5234] with the list rule extension defined in Section |
---|
384 | 1.2 of [Part1]. Appendix D describes rules imported from other |
---|
385 | documents. Appendix E shows the collected ABNF with the list rule |
---|
386 | expanded. |
---|
387 | |
---|
388 | |
---|
389 | |
---|
390 | |
---|
391 | Fielding & Reschke Expires April 7, 2013 [Page 7] |
---|
392 | |
---|
393 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
394 | |
---|
395 | |
---|
396 | 2. Resource |
---|
397 | |
---|
398 | The target of each HTTP request is called a resource. HTTP does not |
---|
399 | limit the nature of a resource; it merely defines an interface that |
---|
400 | might be used to interact with resources. Each resource is |
---|
401 | identified by a Uniform Resource Identifier (URI), as described in |
---|
402 | Section 2.7 of [Part1]. |
---|
403 | |
---|
404 | When a client constructs an HTTP/1.1 request message, it sends the |
---|
405 | "target URI" in one of various forms, as defined in (Section 5.3 of |
---|
406 | [Part1]). When a request is received, the server reconstructs an |
---|
407 | "effective request URI" for the target resource (Section 5.5 of |
---|
408 | [Part1]). |
---|
409 | |
---|
410 | One design goal of HTTP is to separate resource identification from |
---|
411 | request semantics, which is made possible by vesting the request |
---|
412 | semantics in the request method (Section 5) and a few request- |
---|
413 | modifying header fields (Section 6). Resource owners SHOULD NOT |
---|
414 | include request semantics within a URI, such as by specifying an |
---|
415 | action to invoke within the path or query components of the effective |
---|
416 | request URI, unless those semantics are disabled when they are |
---|
417 | inconsistent with the request method. |
---|
418 | |
---|
419 | 3. Representation |
---|
420 | |
---|
421 | If we consider that a resource could be anything, and that the |
---|
422 | uniform interface provided by HTTP is similar to a window through |
---|
423 | which one can observe and act upon such a thing only through the |
---|
424 | communication of messages to some independent actor on the other |
---|
425 | side, then we need an abstraction to represent ("take the place of") |
---|
426 | the current or desired state of that thing in our communications. We |
---|
427 | call that abstraction a "representation" [REST]. |
---|
428 | |
---|
429 | For the purposes of HTTP, a representation is information that |
---|
430 | reflects the current or desired state of a given resource, in a |
---|
431 | format that can be readily communicated via the protocol, consisting |
---|
432 | of a set of representation metadata and a potentially unbounded |
---|
433 | stream of representation data. |
---|
434 | |
---|
435 | 3.1. Representation Metadata |
---|
436 | |
---|
437 | Representation header fields provide metadata about the |
---|
438 | representation. When a message includes a payload body, the |
---|
439 | representation header fields describe how to interpret the |
---|
440 | representation data enclosed in the payload body. In a response to a |
---|
441 | HEAD request, the representation header fields describe the |
---|
442 | representation data that would have been enclosed in the payload body |
---|
443 | if the same request had been a GET. |
---|
444 | |
---|
445 | |
---|
446 | |
---|
447 | Fielding & Reschke Expires April 7, 2013 [Page 8] |
---|
448 | |
---|
449 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
450 | |
---|
451 | |
---|
452 | The following header fields are defined to convey representation |
---|
453 | metadata: |
---|
454 | |
---|
455 | +-------------------+------------------------+ |
---|
456 | | Header Field Name | Defined in... | |
---|
457 | +-------------------+------------------------+ |
---|
458 | | Content-Type | Section 3.1.1.5 | |
---|
459 | | Content-Encoding | Section 3.1.2.2 | |
---|
460 | | Content-Language | Section 3.1.3.2 | |
---|
461 | | Content-Location | Section 3.1.4.2 | |
---|
462 | | Expires | Section 7.3 of [Part6] | |
---|
463 | +-------------------+------------------------+ |
---|
464 | |
---|
465 | 3.1.1. Data Type |
---|
466 | |
---|
467 | 3.1.1.1. Media Types |
---|
468 | |
---|
469 | HTTP uses Internet Media Types [RFC2046] in the Content-Type |
---|
470 | (Section 3.1.1.5) and Accept (Section 6.3.2) header fields in order |
---|
471 | to provide open and extensible data typing and type negotiation. |
---|
472 | |
---|
473 | media-type = type "/" subtype *( OWS ";" OWS parameter ) |
---|
474 | type = token |
---|
475 | subtype = token |
---|
476 | |
---|
477 | The type/subtype MAY be followed by parameters in the form of |
---|
478 | attribute/value pairs. |
---|
479 | |
---|
480 | parameter = attribute "=" value |
---|
481 | attribute = token |
---|
482 | value = word |
---|
483 | |
---|
484 | The type, subtype, and parameter attribute names are case- |
---|
485 | insensitive. Parameter values might or might not be case-sensitive, |
---|
486 | depending on the semantics of the parameter name. The presence or |
---|
487 | absence of a parameter might be significant to the processing of a |
---|
488 | media-type, depending on its definition within the media type |
---|
489 | registry. |
---|
490 | |
---|
491 | A parameter value that matches the token production can be |
---|
492 | transmitted as either a token or within a quoted-string. The quoted |
---|
493 | and unquoted values are equivalent. |
---|
494 | |
---|
495 | Media-type values are registered with the Internet Assigned Number |
---|
496 | Authority (IANA). The media type registration process is outlined in |
---|
497 | [RFC4288]. Use of non-registered media types is discouraged. |
---|
498 | |
---|
499 | |
---|
500 | |
---|
501 | |
---|
502 | |
---|
503 | Fielding & Reschke Expires April 7, 2013 [Page 9] |
---|
504 | |
---|
505 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
506 | |
---|
507 | |
---|
508 | 3.1.1.2. Character Encodings (charset) |
---|
509 | |
---|
510 | HTTP uses charset names to indicate the character encoding of a |
---|
511 | textual representation. |
---|
512 | |
---|
513 | A character encoding is identified by a case-insensitive token. The |
---|
514 | complete set of tokens is defined by the IANA Character Set registry |
---|
515 | (<http://www.iana.org/assignments/character-sets>). |
---|
516 | |
---|
517 | charset = token |
---|
518 | |
---|
519 | Although HTTP allows an arbitrary token to be used as a charset |
---|
520 | value, any token that has a predefined value within the IANA |
---|
521 | Character Set registry MUST represent the character encoding defined |
---|
522 | by that registry. Applications SHOULD limit their use of character |
---|
523 | encodings to those defined within the IANA registry. |
---|
524 | |
---|
525 | HTTP uses charset in two contexts: within an Accept-Charset request |
---|
526 | header field (in which the charset value is an unquoted token) and as |
---|
527 | the value of a parameter in a Content-Type header field (within a |
---|
528 | request or response), in which case the parameter value of the |
---|
529 | charset parameter can be quoted. |
---|
530 | |
---|
531 | Implementers need to be aware of IETF character set requirements |
---|
532 | [RFC3629] [RFC2277]. |
---|
533 | |
---|
534 | 3.1.1.3. Canonicalization and Text Defaults |
---|
535 | |
---|
536 | Internet media types are registered with a canonical form. A |
---|
537 | representation transferred via HTTP messages MUST be in the |
---|
538 | appropriate canonical form prior to its transmission except for |
---|
539 | "text" types, as defined in the next paragraph. |
---|
540 | |
---|
541 | When in canonical form, media subtypes of the "text" type use CRLF as |
---|
542 | the text line break. HTTP relaxes this requirement and allows the |
---|
543 | transport of text media with plain CR or LF alone representing a line |
---|
544 | break when it is done consistently for an entire representation. |
---|
545 | HTTP applications MUST accept CRLF, bare CR, and bare LF as |
---|
546 | indicating a line break in text media received via HTTP. In |
---|
547 | addition, if the text is in a character encoding that does not use |
---|
548 | octets 13 and 10 for CR and LF respectively, as is the case for some |
---|
549 | multi-byte character encodings, HTTP allows the use of whatever octet |
---|
550 | sequences are defined by that character encoding to represent the |
---|
551 | equivalent of CR and LF for line breaks. This flexibility regarding |
---|
552 | line breaks applies only to text media in the payload body; a bare CR |
---|
553 | or LF MUST NOT be substituted for CRLF within any of the HTTP control |
---|
554 | structures (such as header fields and multipart boundaries). |
---|
555 | |
---|
556 | |
---|
557 | |
---|
558 | |
---|
559 | Fielding & Reschke Expires April 7, 2013 [Page 10] |
---|
560 | |
---|
561 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
562 | |
---|
563 | |
---|
564 | If a representation is encoded with a content-coding, the underlying |
---|
565 | data MUST be in a form defined above prior to being encoded. |
---|
566 | |
---|
567 | 3.1.1.4. Multipart Types |
---|
568 | |
---|
569 | MIME provides for a number of "multipart" types -- encapsulations of |
---|
570 | one or more representations within a single message body. All |
---|
571 | multipart types share a common syntax, as defined in Section 5.1.1 of |
---|
572 | [RFC2046], and include a boundary parameter as part of the media type |
---|
573 | value. The message body is itself a protocol element; a sender MUST |
---|
574 | generate only CRLF to represent line breaks between body-parts. |
---|
575 | |
---|
576 | In general, HTTP treats a multipart message body no differently than |
---|
577 | any other media type: strictly as payload. HTTP does not use the |
---|
578 | multipart boundary as an indicator of message body length. In all |
---|
579 | other respects, an HTTP user agent SHOULD follow the same or similar |
---|
580 | behavior as a MIME user agent would upon receipt of a multipart type. |
---|
581 | The MIME header fields within each body-part of a multipart message |
---|
582 | body do not have any significance to HTTP beyond that defined by |
---|
583 | their MIME semantics. |
---|
584 | |
---|
585 | A recipient MUST treat an unrecognized multipart subtype as being |
---|
586 | equivalent to "multipart/mixed". |
---|
587 | |
---|
588 | Note: The "multipart/form-data" type has been specifically defined |
---|
589 | for carrying form data suitable for processing via the POST |
---|
590 | request method, as described in [RFC2388]. |
---|
591 | |
---|
592 | 3.1.1.5. Content-Type |
---|
593 | |
---|
594 | The "Content-Type" header field indicates the media type of the |
---|
595 | representation, which defines both the data format and how that data |
---|
596 | SHOULD be processed by the recipient (within the scope of the request |
---|
597 | method semantics) after any Content-Encoding is decoded. For |
---|
598 | responses to the HEAD method, the media type is that which would have |
---|
599 | been sent had the request been a GET. |
---|
600 | |
---|
601 | Content-Type = media-type |
---|
602 | |
---|
603 | Media types are defined in Section 3.1.1.1. An example of the field |
---|
604 | is |
---|
605 | |
---|
606 | Content-Type: text/html; charset=ISO-8859-4 |
---|
607 | |
---|
608 | A sender SHOULD include a Content-Type header field in a message |
---|
609 | containing a payload body, defining the media type of the enclosed |
---|
610 | representation, unless the intended media type is unknown to the |
---|
611 | sender. If a Content-Type header field is not present, recipients |
---|
612 | |
---|
613 | |
---|
614 | |
---|
615 | Fielding & Reschke Expires April 7, 2013 [Page 11] |
---|
616 | |
---|
617 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
618 | |
---|
619 | |
---|
620 | MAY either assume a media type of "application/octet-stream" |
---|
621 | ([RFC2046], Section 4.5.1) or examine the representation data to |
---|
622 | determine its type. |
---|
623 | |
---|
624 | In practice, resource owners do not always properly configure their |
---|
625 | origin server to provide the correct Content-Type for a given |
---|
626 | representation, with the result that some clients will examine a |
---|
627 | payload's content and override the specified type. Clients that do |
---|
628 | so risk drawing incorrect conclusions, which might expose additional |
---|
629 | security risks (e.g., "privilege escalation"). Furthermore, it is |
---|
630 | impossible to determine the sender's intent by examining the data |
---|
631 | format: many data formats match multiple media types that differ only |
---|
632 | in processing semantics. Implementers are encouraged to provide a |
---|
633 | means of disabling such "content sniffing" when it is used. |
---|
634 | |
---|
635 | 3.1.2. Data Encoding |
---|
636 | |
---|
637 | 3.1.2.1. Content Codings |
---|
638 | |
---|
639 | Content coding values indicate an encoding transformation that has |
---|
640 | been or can be applied to a representation. Content codings are |
---|
641 | primarily used to allow a representation to be compressed or |
---|
642 | otherwise usefully transformed without losing the identity of its |
---|
643 | underlying media type and without loss of information. Frequently, |
---|
644 | the representation is stored in coded form, transmitted directly, and |
---|
645 | only decoded by the recipient. |
---|
646 | |
---|
647 | content-coding = token |
---|
648 | |
---|
649 | All content-coding values are case-insensitive and SHOULD be |
---|
650 | registered within the HTTP Content Coding registry, as defined in |
---|
651 | Section 9.4. They are used in the Accept-Encoding (Section 6.3.4) |
---|
652 | and Content-Encoding (Section 3.1.2.2) header fields. |
---|
653 | |
---|
654 | The following content-coding values are defined by this |
---|
655 | specification: |
---|
656 | |
---|
657 | compress (and x-compress): See Section 4.2.1 of [Part1]. |
---|
658 | |
---|
659 | deflate: See Section 4.2.2 of [Part1]. |
---|
660 | |
---|
661 | gzip (and x-gzip): See Section 4.2.3 of [Part1]. |
---|
662 | |
---|
663 | 3.1.2.2. Content-Encoding |
---|
664 | |
---|
665 | The "Content-Encoding" header field indicates what content codings |
---|
666 | have been applied to the representation, beyond those inherent in the |
---|
667 | media type, and thus what decoding mechanisms have to be applied in |
---|
668 | |
---|
669 | |
---|
670 | |
---|
671 | Fielding & Reschke Expires April 7, 2013 [Page 12] |
---|
672 | |
---|
673 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
674 | |
---|
675 | |
---|
676 | order to obtain data in the media type referenced by the Content-Type |
---|
677 | header field. Content-Encoding is primarily used to allow a |
---|
678 | representation's data to be compressed without losing the identity of |
---|
679 | its underlying media type. |
---|
680 | |
---|
681 | Content-Encoding = 1#content-coding |
---|
682 | |
---|
683 | An example of its use is |
---|
684 | |
---|
685 | Content-Encoding: gzip |
---|
686 | |
---|
687 | If multiple encodings have been applied to a representation, the |
---|
688 | content codings MUST be listed in the order in which they were |
---|
689 | applied. Additional information about the encoding parameters MAY be |
---|
690 | provided by other header fields not defined by this specification. |
---|
691 | |
---|
692 | Unlike Transfer-Encoding (Section 3.3.1 of [Part1]), the codings |
---|
693 | listed in Content-Encoding are a characteristic of the |
---|
694 | representation; the representation is defined in terms of the coded |
---|
695 | form, and all other metadata about the representation is about the |
---|
696 | coded form unless otherwise noted in the metadata definition. |
---|
697 | Typically, the representation is only decoded just prior to rendering |
---|
698 | or analogous usage. |
---|
699 | |
---|
700 | A transforming proxy MAY modify the content coding if the new coding |
---|
701 | is known to be acceptable to the recipient, unless the "no-transform" |
---|
702 | cache-control directive is present in the message. |
---|
703 | |
---|
704 | If the media type includes an inherent encoding, such as a data |
---|
705 | format that is always compressed, then that encoding would not be |
---|
706 | restated as a Content-Encoding even if it happens to be the same |
---|
707 | algorithm as one of the content codings. Such a content coding would |
---|
708 | only be listed if, for some bizarre reason, it is applied a second |
---|
709 | time to form the representation. Likewise, an origin server might |
---|
710 | choose to publish the same payload data as multiple representations |
---|
711 | that differ only in whether the coding is defined as part of Content- |
---|
712 | Type or Content-Encoding, since some user agents will behave |
---|
713 | differently in their handling of each response (e.g., open a "Save as |
---|
714 | ..." dialog instead of automatic decompression and rendering of |
---|
715 | content). |
---|
716 | |
---|
717 | If the content-coding of a representation in a request message is not |
---|
718 | acceptable to the origin server, the server SHOULD respond with a |
---|
719 | status code of 415 (Unsupported Media Type). |
---|
720 | |
---|
721 | |
---|
722 | |
---|
723 | |
---|
724 | |
---|
725 | |
---|
726 | |
---|
727 | Fielding & Reschke Expires April 7, 2013 [Page 13] |
---|
728 | |
---|
729 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
730 | |
---|
731 | |
---|
732 | 3.1.3. Audience Language |
---|
733 | |
---|
734 | 3.1.3.1. Language Tags |
---|
735 | |
---|
736 | A language tag, as defined in [RFC5646], identifies a natural |
---|
737 | language spoken, written, or otherwise conveyed by human beings for |
---|
738 | communication of information to other human beings. Computer |
---|
739 | languages are explicitly excluded. HTTP uses language tags within |
---|
740 | the Accept-Language and Content-Language fields. |
---|
741 | |
---|
742 | In summary, a language tag is composed of one or more parts: A |
---|
743 | primary language subtag followed by a possibly empty series of |
---|
744 | subtags: |
---|
745 | |
---|
746 | language-tag = <Language-Tag, defined in [RFC5646], Section 2.1> |
---|
747 | |
---|
748 | White space is not allowed within the tag and all tags are case- |
---|
749 | insensitive. The name space of language subtags is administered by |
---|
750 | the IANA (see |
---|
751 | <http://www.iana.org/assignments/language-subtag-registry>). |
---|
752 | |
---|
753 | Example tags include: |
---|
754 | |
---|
755 | en, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN |
---|
756 | |
---|
757 | See [RFC5646] for further information. |
---|
758 | |
---|
759 | 3.1.3.2. Content-Language |
---|
760 | |
---|
761 | The "Content-Language" header field describes the natural language(s) |
---|
762 | of the intended audience for the representation. Note that this |
---|
763 | might not be equivalent to all the languages used within the |
---|
764 | representation. |
---|
765 | |
---|
766 | Content-Language = 1#language-tag |
---|
767 | |
---|
768 | Language tags are defined in Section 3.1.3.1. The primary purpose of |
---|
769 | Content-Language is to allow a user to identify and differentiate |
---|
770 | representations according to the user's own preferred language. |
---|
771 | Thus, if the content is intended only for a Danish-literate audience, |
---|
772 | the appropriate field is |
---|
773 | |
---|
774 | Content-Language: da |
---|
775 | |
---|
776 | If no Content-Language is specified, the default is that the content |
---|
777 | is intended for all language audiences. This might mean that the |
---|
778 | sender does not consider it to be specific to any natural language, |
---|
779 | or that the sender does not know for which language it is intended. |
---|
780 | |
---|
781 | |
---|
782 | |
---|
783 | Fielding & Reschke Expires April 7, 2013 [Page 14] |
---|
784 | |
---|
785 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
786 | |
---|
787 | |
---|
788 | Multiple languages MAY be listed for content that is intended for |
---|
789 | multiple audiences. For example, a rendition of the "Treaty of |
---|
790 | Waitangi", presented simultaneously in the original Maori and English |
---|
791 | versions, would call for |
---|
792 | |
---|
793 | Content-Language: mi, en |
---|
794 | |
---|
795 | However, just because multiple languages are present within a |
---|
796 | representation does not mean that it is intended for multiple |
---|
797 | linguistic audiences. An example would be a beginner's language |
---|
798 | primer, such as "A First Lesson in Latin", which is clearly intended |
---|
799 | to be used by an English-literate audience. In this case, the |
---|
800 | Content-Language would properly only include "en". |
---|
801 | |
---|
802 | Content-Language MAY be applied to any media type -- it is not |
---|
803 | limited to textual documents. |
---|
804 | |
---|
805 | 3.1.4. Identification |
---|
806 | |
---|
807 | 3.1.4.1. Identifying a Representation |
---|
808 | |
---|
809 | When a complete or partial representation is transferred in a message |
---|
810 | payload, it is often desirable for the sender to supply, or the |
---|
811 | recipient to determine, an identifier for a resource corresponding to |
---|
812 | that representation. |
---|
813 | |
---|
814 | The following rules are used to determine such a URI for the payload |
---|
815 | of a request message: |
---|
816 | |
---|
817 | o If the request has a Content-Location header field, then the |
---|
818 | sender asserts that the payload is a representation of the |
---|
819 | resource identified by the Content-Location field-value. However, |
---|
820 | such an assertion cannot be trusted unless it can be verified by |
---|
821 | other means (not defined by HTTP). The information might still be |
---|
822 | useful for revision history links. |
---|
823 | |
---|
824 | o Otherwise, the payload is unidentified. |
---|
825 | |
---|
826 | The following rules, to be applied in order until a match is found, |
---|
827 | are used to determine such a URI for the payload of a response |
---|
828 | message: |
---|
829 | |
---|
830 | 1. If the request is GET or HEAD and the response status code is 200 |
---|
831 | (OK), 204 (No Content), 206 (Partial Content), or 304 (Not |
---|
832 | Modified), the payload's identifier is the effective request URI |
---|
833 | (Section 5.5 of [Part1]). |
---|
834 | |
---|
835 | |
---|
836 | |
---|
837 | |
---|
838 | |
---|
839 | Fielding & Reschke Expires April 7, 2013 [Page 15] |
---|
840 | |
---|
841 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
842 | |
---|
843 | |
---|
844 | 2. If the request is GET or HEAD and the response status code is 203 |
---|
845 | (Non-Authoritative Information), the payload is a potentially |
---|
846 | modified representation of the target resource; as such, the |
---|
847 | effective request URI might only act as an identifier for the |
---|
848 | payload's representation when a request is made via the same |
---|
849 | chain of intermediaries. |
---|
850 | |
---|
851 | 3. If the response has a Content-Location header field and its |
---|
852 | field-value is a reference to the same URI as the effective |
---|
853 | request URI, the payload's identifier is the effective request |
---|
854 | URI. |
---|
855 | |
---|
856 | 4. If the response has a Content-Location header field and its |
---|
857 | field-value is a reference to a URI different from the effective |
---|
858 | request URI, then the sender asserts that the payload is a |
---|
859 | representation of the resource identified by the Content-Location |
---|
860 | field-value. However, such an assertion cannot be trusted unless |
---|
861 | it can be verified by other means (not defined by HTTP). |
---|
862 | |
---|
863 | 5. Otherwise, the payload is unidentified. |
---|
864 | |
---|
865 | 3.1.4.2. Content-Location |
---|
866 | |
---|
867 | The "Content-Location" header field references a URI that can be used |
---|
868 | as a specific identifier for the representation in this message |
---|
869 | payload. In other words, if one were to perform a GET on this URI at |
---|
870 | the time of this message's generation, then a 200 (OK) response would |
---|
871 | contain the same representation that is enclosed as payload in this |
---|
872 | message. |
---|
873 | |
---|
874 | Content-Location = absolute-URI / partial-URI |
---|
875 | |
---|
876 | The Content-Location value is not a replacement for the effective |
---|
877 | Request URI (Section 5.5 of [Part1]). It is representation metadata. |
---|
878 | It has the same syntax and semantics as the header field of the same |
---|
879 | name defined for MIME body parts in Section 4 of [RFC2557]. However, |
---|
880 | its appearance in an HTTP message has some special implications for |
---|
881 | HTTP recipients. |
---|
882 | |
---|
883 | If Content-Location is included in a 2xx (Successful) response |
---|
884 | message and its value refers (after conversion to absolute form) to a |
---|
885 | URI that is the same as the effective request URI, then the response |
---|
886 | payload SHOULD be considered a current representation of that |
---|
887 | resource. For a GET or HEAD request, this is the same as the default |
---|
888 | semantics when no Content-Location is provided by the server. For a |
---|
889 | state-changing request like PUT or POST, it implies that the server's |
---|
890 | response contains the new representation of that resource, thereby |
---|
891 | distinguishing it from representations that might only report about |
---|
892 | |
---|
893 | |
---|
894 | |
---|
895 | Fielding & Reschke Expires April 7, 2013 [Page 16] |
---|
896 | |
---|
897 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
898 | |
---|
899 | |
---|
900 | the action (e.g., "It worked!"). This allows authoring applications |
---|
901 | to update their local copies without the need for a subsequent GET |
---|
902 | request. |
---|
903 | |
---|
904 | If Content-Location is included in a 2xx (Successful) response |
---|
905 | message and its field-value refers to a URI that differs from the |
---|
906 | effective request URI, then the origin server claims that the field- |
---|
907 | value is an identifier for the payload's representation. Such a |
---|
908 | claim can only be trusted if both identifiers share the same resource |
---|
909 | owner, which cannot be programmatically determined via HTTP. |
---|
910 | |
---|
911 | o For a response to a GET or HEAD request, this is an indication |
---|
912 | that the effective request URI identifies a resource that is |
---|
913 | subject to content negotiation and the Content-Location field- |
---|
914 | value is a more specific identifier for the selected |
---|
915 | representation. |
---|
916 | |
---|
917 | o For a 201 (Created) response to a state-changing method, a |
---|
918 | Content-Location field-value that is identical to the Location |
---|
919 | field-value indicates that this payload is a current |
---|
920 | representation of the newly created resource. |
---|
921 | |
---|
922 | o Otherwise, such a Content-Location indicates that this payload is |
---|
923 | a representation reporting on the requested action's status and |
---|
924 | that the same report is available (for future access with GET) at |
---|
925 | the given URI. For example, a purchase transaction made via a |
---|
926 | POST request might include a receipt document as the payload of |
---|
927 | the 200 (OK) response; the Content-Location field-value provides |
---|
928 | an identifier for retrieving a copy of that same receipt in the |
---|
929 | future. |
---|
930 | |
---|
931 | If Content-Location is included in a request message, then it MAY be |
---|
932 | interpreted by the origin server as an indication of where the user |
---|
933 | agent originally obtained the content of the enclosed representation |
---|
934 | (prior to any subsequent modification of the content by that user |
---|
935 | agent). In other words, the user agent is providing the same |
---|
936 | representation metadata that it received with the original |
---|
937 | representation. However, such interpretation MUST NOT be used to |
---|
938 | alter the semantics of the method requested by the client. For |
---|
939 | example, if a client makes a PUT request on a negotiated resource and |
---|
940 | the origin server accepts that PUT (without redirection), then the |
---|
941 | new set of values for that resource is expected to be consistent with |
---|
942 | the one representation supplied in that PUT; the Content-Location |
---|
943 | cannot be used as a form of reverse content selection that identifies |
---|
944 | only one of the negotiated representations to be updated. If the |
---|
945 | user agent had wanted the latter semantics, it would have applied the |
---|
946 | PUT directly to the Content-Location URI. |
---|
947 | |
---|
948 | |
---|
949 | |
---|
950 | |
---|
951 | Fielding & Reschke Expires April 7, 2013 [Page 17] |
---|
952 | |
---|
953 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
954 | |
---|
955 | |
---|
956 | A Content-Location field received in a request message is transitory |
---|
957 | information that SHOULD NOT be saved with other representation |
---|
958 | metadata for use in later responses. The Content-Location's value |
---|
959 | might be saved for use in other contexts, such as within source links |
---|
960 | or other metadata. |
---|
961 | |
---|
962 | A cache cannot assume that a representation with a Content-Location |
---|
963 | different from the URI used to retrieve it can be used to respond to |
---|
964 | later requests on that Content-Location URI. |
---|
965 | |
---|
966 | 3.2. Representation Data |
---|
967 | |
---|
968 | The representation data associated with an HTTP message is either |
---|
969 | provided as the payload body of the message or referred to by the |
---|
970 | message semantics and the effective request URI. The representation |
---|
971 | data is in a format and encoding defined by the representation |
---|
972 | metadata header fields. |
---|
973 | |
---|
974 | The data type of the representation data is determined via the header |
---|
975 | fields Content-Type and Content-Encoding. These define a two-layer, |
---|
976 | ordered encoding model: |
---|
977 | |
---|
978 | representation-data := Content-Encoding( Content-Type( bits ) ) |
---|
979 | |
---|
980 | 3.3. Payload Semantics |
---|
981 | |
---|
982 | Some HTTP messages transfer a complete or partial representation as |
---|
983 | the message "payload". In some cases, a payload might only contain |
---|
984 | the associated representation's header fields (e.g., responses to |
---|
985 | HEAD) or only some part(s) of the representation data (e.g., the 206 |
---|
986 | (Partial Content) status code). |
---|
987 | |
---|
988 | The purpose of a payload in a request is defined by the method |
---|
989 | semantics. In a response, the payload's purpose is defined by both |
---|
990 | the request method and the response status code. |
---|
991 | |
---|
992 | For example, a representation in the payload of a PUT request |
---|
993 | (Section 5.3.4) represents the desired state of the target resource |
---|
994 | if the request is successfully applied, whereas a representation in |
---|
995 | the payload of a POST request (Section 5.3.3) represents an anonymous |
---|
996 | resource for providing data to be processed, such as the information |
---|
997 | that a user entered within an HTML form. |
---|
998 | |
---|
999 | Likewise, the payload of a 200 (OK) response to GET (Section 5.3.1) |
---|
1000 | contains a representation of the target resource, as observed at the |
---|
1001 | time of the message origination date (Section 8.1.1.2), whereas the |
---|
1002 | same status code in a response to POST might contain either a |
---|
1003 | representation of the processing result or a current representation |
---|
1004 | |
---|
1005 | |
---|
1006 | |
---|
1007 | Fielding & Reschke Expires April 7, 2013 [Page 18] |
---|
1008 | |
---|
1009 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
1010 | |
---|
1011 | |
---|
1012 | of the target resource after applying the processing. Response |
---|
1013 | messages with an error status code usually contain a representation |
---|
1014 | that describes the error and what next steps are suggested for |
---|
1015 | resolving it. |
---|
1016 | |
---|
1017 | Header fields that specifically describe the payload, rather than the |
---|
1018 | associated representation, are referred to as "payload header |
---|
1019 | fields". Payload header fields are defined in other parts of this |
---|
1020 | specification, due to their impact on message parsing. |
---|
1021 | |
---|
1022 | +-------------------+--------------------------+ |
---|
1023 | | Header Field Name | Defined in... | |
---|
1024 | +-------------------+--------------------------+ |
---|
1025 | | Content-Length | Section 3.3.2 of [Part1] | |
---|
1026 | | Content-Range | Section 5.2 of [Part5] | |
---|
1027 | | Transfer-Encoding | Section 3.3.1 of [Part1] | |
---|
1028 | +-------------------+--------------------------+ |
---|
1029 | |
---|
1030 | 3.4. Content Negotiation |
---|
1031 | |
---|
1032 | HTTP responses include a representation which contains information |
---|
1033 | for interpretation, whether by a human user or for further |
---|
1034 | processing. Often, the server has different ways of representing the |
---|
1035 | same information; for example, in different formats, languages, or |
---|
1036 | using different character encodings. |
---|
1037 | |
---|
1038 | HTTP clients and their users might have different or variable |
---|
1039 | capabilities, characteristics or preferences which would influence |
---|
1040 | which representation, among those available from the server, would be |
---|
1041 | best for the server to deliver. For this reason, HTTP provides |
---|
1042 | mechanisms for "content negotiation" -- a process of allowing |
---|
1043 | selection of a representation of a given resource, when more than one |
---|
1044 | is available. |
---|
1045 | |
---|
1046 | This specification defines two patterns of content negotiation; |
---|
1047 | "proactive", where the server selects the representation based upon |
---|
1048 | the client's stated preferences, and "reactive" negotiation, where |
---|
1049 | the server provides a list of representations for the client to |
---|
1050 | choose from, based upon their metadata. In addition, there are other |
---|
1051 | patterns: some applications use an "active content" pattern, where |
---|
1052 | the server returns active content which runs on the client and, based |
---|
1053 | on client available parameters, selects additional resources to |
---|
1054 | invoke. "Transparent Content Negotiation" ([RFC2295]) has also been |
---|
1055 | proposed. |
---|
1056 | |
---|
1057 | These patterns are all widely used, and have trade-offs in |
---|
1058 | applicability and practicality. In particular, when the number of |
---|
1059 | preferences or capabilities to be expressed by a client are large |
---|
1060 | |
---|
1061 | |
---|
1062 | |
---|
1063 | Fielding & Reschke Expires April 7, 2013 [Page 19] |
---|
1064 | |
---|
1065 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
1066 | |
---|
1067 | |
---|
1068 | (such as when many different formats are supported by a user-agent), |
---|
1069 | proactive negotiation becomes unwieldy, and might not be appropriate. |
---|
1070 | Conversely, when the number of representations to choose from is very |
---|
1071 | large, reactive negotiation might not be appropriate. |
---|
1072 | |
---|
1073 | Note that, in all cases, the supplier of representations has the |
---|
1074 | responsibility for determining which representations might be |
---|
1075 | considered to be the "same information". |
---|
1076 | |
---|
1077 | 3.4.1. Proactive Negotiation |
---|
1078 | |
---|
1079 | If the selection of the best representation for a response is made by |
---|
1080 | an algorithm located at the server, it is called proactive |
---|
1081 | negotiation. Selection is based on the available representations of |
---|
1082 | the response (the dimensions over which it can vary; e.g., language, |
---|
1083 | content-coding, etc.) and the contents of particular header fields in |
---|
1084 | the request message or on other information pertaining to the request |
---|
1085 | (such as the network address of the client). |
---|
1086 | |
---|
1087 | Proactive negotiation is advantageous when the algorithm for |
---|
1088 | selecting from among the available representations is difficult to |
---|
1089 | describe to the user agent, or when the server desires to send its |
---|
1090 | "best guess" to the client along with the first response (hoping to |
---|
1091 | avoid the round-trip delay of a subsequent request if the "best |
---|
1092 | guess" is good enough for the user). In order to improve the |
---|
1093 | server's guess, the user agent MAY include request header fields |
---|
1094 | (Accept, Accept-Language, Accept-Encoding, etc.) which describe its |
---|
1095 | preferences for such a response. |
---|
1096 | |
---|
1097 | Proactive negotiation has disadvantages: |
---|
1098 | |
---|
1099 | 1. It is impossible for the server to accurately determine what |
---|
1100 | might be "best" for any given user, since that would require |
---|
1101 | complete knowledge of both the capabilities of the user agent and |
---|
1102 | the intended use for the response (e.g., does the user want to |
---|
1103 | view it on screen or print it on paper?). |
---|
1104 | |
---|
1105 | 2. Having the user agent describe its capabilities in every request |
---|
1106 | can be both very inefficient (given that only a small percentage |
---|
1107 | of responses have multiple representations) and a potential |
---|
1108 | violation of the user's privacy. |
---|
1109 | |
---|
1110 | 3. It complicates the implementation of an origin server and the |
---|
1111 | algorithms for generating responses to a request. |
---|
1112 | |
---|
1113 | 4. It might limit a public cache's ability to use the same response |
---|
1114 | for multiple user's requests. |
---|
1115 | |
---|
1116 | |
---|
1117 | |
---|
1118 | |
---|
1119 | Fielding & Reschke Expires April 7, 2013 [Page 20] |
---|
1120 | |
---|
1121 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
1122 | |
---|
1123 | |
---|
1124 | Proactive negotiation allows the user agent to specify its |
---|
1125 | preferences, but it cannot expect responses to always honor them. |
---|
1126 | For example, the origin server might not implement proactive |
---|
1127 | negotiation, or it might decide that sending a response that doesn't |
---|
1128 | conform to them is better than sending a 406 (Not Acceptable) |
---|
1129 | response. |
---|
1130 | |
---|
1131 | HTTP/1.1 includes the following header fields for enabling proactive |
---|
1132 | negotiation through description of user agent capabilities and user |
---|
1133 | preferences: Accept (Section 6.3.2), Accept-Charset (Section 6.3.3), |
---|
1134 | Accept-Encoding (Section 6.3.4), Accept-Language (Section 6.3.5), and |
---|
1135 | User-Agent (Section 6.5.3). However, an origin server is not limited |
---|
1136 | to these dimensions and MAY vary the response based on any aspect of |
---|
1137 | the request, including aspects of the connection (e.g., IP address) |
---|
1138 | or information within extension header fields not defined by this |
---|
1139 | specification. |
---|
1140 | |
---|
1141 | Note: In practice, User-Agent based negotiation is fragile, |
---|
1142 | because new clients might not be recognized. |
---|
1143 | |
---|
1144 | The Vary header field (Section 8.2.1) can be used to express the |
---|
1145 | parameters the server uses to select a representation that is subject |
---|
1146 | to proactive negotiation. |
---|
1147 | |
---|
1148 | 3.4.2. Reactive Negotiation |
---|
1149 | |
---|
1150 | With reactive negotiation, selection of the best representation for a |
---|
1151 | response is performed by the user agent after receiving an initial |
---|
1152 | response from the origin server. Selection is based on a list of the |
---|
1153 | available representations of the response included within the header |
---|
1154 | fields or body of the initial response, with each representation |
---|
1155 | identified by its own URI. Selection from among the representations |
---|
1156 | can be performed automatically (if the user agent is capable of doing |
---|
1157 | so) or manually by the user selecting from a generated (possibly |
---|
1158 | hypertext) menu. |
---|
1159 | |
---|
1160 | Reactive negotiation is advantageous when the response would vary |
---|
1161 | over commonly-used dimensions (such as type, language, or encoding), |
---|
1162 | when the origin server is unable to determine a user agent's |
---|
1163 | capabilities from examining the request, and generally when public |
---|
1164 | caches are used to distribute server load and reduce network usage. |
---|
1165 | |
---|
1166 | Reactive negotiation suffers from the disadvantage of needing a |
---|
1167 | second request to obtain the best alternate representation. This |
---|
1168 | second request is only efficient when caching is used. In addition, |
---|
1169 | this specification does not define any mechanism for supporting |
---|
1170 | automatic selection, though it also does not prevent any such |
---|
1171 | mechanism from being developed as an extension and used within |
---|
1172 | |
---|
1173 | |
---|
1174 | |
---|
1175 | Fielding & Reschke Expires April 7, 2013 [Page 21] |
---|
1176 | |
---|
1177 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
1178 | |
---|
1179 | |
---|
1180 | HTTP/1.1. |
---|
1181 | |
---|
1182 | This specification defines the 300 (Multiple Choices) and 406 (Not |
---|
1183 | Acceptable) status codes for enabling reactive negotiation when the |
---|
1184 | server is unwilling or unable to provide a varying response using |
---|
1185 | proactive negotiation. |
---|
1186 | |
---|
1187 | 4. Product Tokens |
---|
1188 | |
---|
1189 | Product tokens are used to allow communicating applications to |
---|
1190 | identify themselves by software name and version. Most fields using |
---|
1191 | product tokens also allow sub-products which form a significant part |
---|
1192 | of the application to be listed, separated by whitespace. By |
---|
1193 | convention, the products are listed in order of their significance |
---|
1194 | for identifying the application. |
---|
1195 | |
---|
1196 | product = token ["/" product-version] |
---|
1197 | product-version = token |
---|
1198 | |
---|
1199 | Examples: |
---|
1200 | |
---|
1201 | User-Agent: CERN-LineMode/2.15 libwww/2.17b3 |
---|
1202 | Server: Apache/0.8.4 |
---|
1203 | |
---|
1204 | Product tokens SHOULD be short and to the point. They MUST NOT be |
---|
1205 | used for advertising or other non-essential information. Although |
---|
1206 | any token octet MAY appear in a product-version, this token SHOULD |
---|
1207 | only be used for a version identifier (i.e., successive versions of |
---|
1208 | the same product SHOULD only differ in the product-version portion of |
---|
1209 | the product value). |
---|
1210 | |
---|
1211 | 5. Request Methods |
---|
1212 | |
---|
1213 | 5.1. Overview |
---|
1214 | |
---|
1215 | The request method token is the primary source of request semantics; |
---|
1216 | it indicates the purpose for which the client has made this request |
---|
1217 | and what is expected by the client as a successful result. The |
---|
1218 | request semantics MAY be further specialized by the semantics of some |
---|
1219 | header fields when present in a request (Section 6) if those |
---|
1220 | additional semantics do not conflict with the method. |
---|
1221 | |
---|
1222 | method = token |
---|
1223 | |
---|
1224 | HTTP was originally designed to be usable as an interface to |
---|
1225 | distributed object systems. The request method was envisioned as |
---|
1226 | applying semantics to a target resource in much the same way as |
---|
1227 | invoking a defined method on an identified object would apply |
---|
1228 | |
---|
1229 | |
---|
1230 | |
---|
1231 | Fielding & Reschke Expires April 7, 2013 [Page 22] |
---|
1232 | |
---|
1233 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
1234 | |
---|
1235 | |
---|
1236 | semantics. The method token is case-sensitive because it might be |
---|
1237 | used as a gateway to object-based systems with case-sensitive method |
---|
1238 | names. |
---|
1239 | |
---|
1240 | Unlike distributed objects, the standardized request methods in HTTP |
---|
1241 | are not resource-specific, since uniform interfaces provide for |
---|
1242 | better visibility and reuse in network-based systems [REST]. Once |
---|
1243 | defined, a standardized method MUST have the same semantics when |
---|
1244 | applied to any resource, though each resource determines for itself |
---|
1245 | whether those semantics are implemented or allowed. |
---|
1246 | |
---|
1247 | This specification defines a number of standardized methods that are |
---|
1248 | commonly used in HTTP, as outlined by the following table. By |
---|
1249 | convention, standardized methods are defined in all-uppercase ASCII |
---|
1250 | letters. |
---|
1251 | |
---|
1252 | +---------+-------------------------------------------------+-------+ |
---|
1253 | | Method | Description | Sec. | |
---|
1254 | +---------+-------------------------------------------------+-------+ |
---|
1255 | | GET | Transfer a current representation of the target | 5.3.1 | |
---|
1256 | | | resource. | | |
---|
1257 | | HEAD | Same as GET, but do not include a message body | 5.3.2 | |
---|
1258 | | | in the response. | | |
---|
1259 | | POST | Perform resource-specific processing on the | 5.3.3 | |
---|
1260 | | | request payload. | | |
---|
1261 | | PUT | Replace all current representations of the | 5.3.4 | |
---|
1262 | | | target resource with the request payload. | | |
---|
1263 | | DELETE | Remove all current representations of the | 5.3.5 | |
---|
1264 | | | target resource. | | |
---|
1265 | | CONNECT | Establish a tunnel to the server identified by | 5.3.6 | |
---|
1266 | | | the target resource. | | |
---|
1267 | | OPTIONS | Describe the communication options for the | 5.3.7 | |
---|
1268 | | | target resource. | | |
---|
1269 | | TRACE | Perform a message loop-back test along the path | 5.3.8 | |
---|
1270 | | | to the target resource. | | |
---|
1271 | +---------+-------------------------------------------------+-------+ |
---|
1272 | |
---|
1273 | The methods GET and HEAD MUST be supported by all general-purpose |
---|
1274 | servers. All other methods are OPTIONAL. When implemented, a server |
---|
1275 | MUST implement the above methods according to the semantics defined |
---|
1276 | for them in Section 5.3. |
---|
1277 | |
---|
1278 | Additional methods MAY be used in HTTP; many have already been |
---|
1279 | standardized outside the scope of this specification and registered |
---|
1280 | within the HTTP Method Registry maintained by IANA, as defined in |
---|
1281 | Section 9.1. |
---|
1282 | |
---|
1283 | The set of methods allowed by a target resource can be listed in an |
---|
1284 | |
---|
1285 | |
---|
1286 | |
---|
1287 | Fielding & Reschke Expires April 7, 2013 [Page 23] |
---|
1288 | |
---|
1289 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
1290 | |
---|
1291 | |
---|
1292 | Allow header field (Section 8.4.1). However, the set of allowed |
---|
1293 | methods can change dynamically. When a request message is received |
---|
1294 | that is unrecognized or not implemented by an origin server, the |
---|
1295 | origin server SHOULD respond with the 501 (Not Implemented) status |
---|
1296 | code. When a request message is received that is known by an origin |
---|
1297 | server but not allowed for the target resource, the origin server |
---|
1298 | SHOULD respond with the 405 (Method Not Allowed) status code. |
---|
1299 | |
---|
1300 | 5.2. Common Method Properties |
---|
1301 | |
---|
1302 | 5.2.1. Safe Methods |
---|
1303 | |
---|
1304 | Request methods are considered "safe" if their defined semantics are |
---|
1305 | essentially read-only; i.e., the client does not request, and does |
---|
1306 | not expect, any state change on the origin server as a result of |
---|
1307 | applying a safe method to a target resource. Likewise, reasonable |
---|
1308 | use of a safe method is not expected to cause any harm, loss of |
---|
1309 | property, or unusual burden on the origin server. |
---|
1310 | |
---|
1311 | This definition of safe methods does not prevent an implementation |
---|
1312 | from including behavior that is potentially harmful, not entirely |
---|
1313 | read-only, or which causes side-effects while invoking a safe method. |
---|
1314 | What is important, however, is that the client did not request that |
---|
1315 | additional behavior and cannot be held accountable for it. For |
---|
1316 | example, most servers append request information to access log files |
---|
1317 | at the completion of every response, regardless of the method, and |
---|
1318 | that is considered safe even though the log storage might become full |
---|
1319 | and crash the server. Likewise, a safe request initiated by |
---|
1320 | selecting an advertisement on the Web will often have the side-effect |
---|
1321 | of charging an advertising account. |
---|
1322 | |
---|
1323 | The GET, HEAD, OPTIONS, and TRACE request methods are defined to be |
---|
1324 | safe. |
---|
1325 | |
---|
1326 | The purpose of distinguishing between safe and unsafe methods is to |
---|
1327 | allow automated retrieval processes (spiders) and cache performance |
---|
1328 | optimization (pre-fetching) to work without fear of causing harm. In |
---|
1329 | addition, it allows a user agent to apply appropriate constraints on |
---|
1330 | the automated use of unsafe methods when processing potentially |
---|
1331 | untrusted content. |
---|
1332 | |
---|
1333 | A user agent SHOULD distinguish between safe and unsafe methods when |
---|
1334 | presenting potential actions to a user, such that the user can be |
---|
1335 | made aware of an unsafe action before it is requested. |
---|
1336 | |
---|
1337 | When a resource is constructed such that parameters within the |
---|
1338 | effective request URI have the effect of selecting an action, it is |
---|
1339 | the resource owner's responsibility to ensure that the action is |
---|
1340 | |
---|
1341 | |
---|
1342 | |
---|
1343 | Fielding & Reschke Expires April 7, 2013 [Page 24] |
---|
1344 | |
---|
1345 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
1346 | |
---|
1347 | |
---|
1348 | consistent with the request method semantics. For example, it is |
---|
1349 | common for Web-based content editing software to use actions within |
---|
1350 | query parameters, such as "page?do=delete". If the purpose of such a |
---|
1351 | resource is to perform an unsafe action, then the resource MUST |
---|
1352 | disable or disallow that action when it is accessed using a safe |
---|
1353 | request method. Failure to do so will result in unfortunate side- |
---|
1354 | effects when automated processes perform a GET on every URI reference |
---|
1355 | for the sake of link maintenance, pre-fetching, building a search |
---|
1356 | index, etc. |
---|
1357 | |
---|
1358 | 5.2.2. Idempotent Methods |
---|
1359 | |
---|
1360 | Request methods are considered "idempotent" if the intended effect of |
---|
1361 | multiple identical requests is the same as for a single request. |
---|
1362 | PUT, DELETE, and all safe request methods are idempotent. |
---|
1363 | |
---|
1364 | Like the definition of safe, the idempotent property only applies to |
---|
1365 | what has been requested by the user; a server is free to log each |
---|
1366 | request separately, retain a revision control history, or implement |
---|
1367 | other non-idempotent side-effects for each idempotent request. |
---|
1368 | |
---|
1369 | Idempotent methods are distinguished because the request can be |
---|
1370 | repeated automatically if a communication failure occurs before the |
---|
1371 | client is able to read the server's response. For example, if a |
---|
1372 | client sends a PUT request and the underlying connection is closed |
---|
1373 | before any response is received, then it can establish a new |
---|
1374 | connection and retry the idempotent request because it knows that |
---|
1375 | repeating the request will have the same effect even if the original |
---|
1376 | request succeeded. Note, however, that repeated failures would |
---|
1377 | indicate a problem within the server. |
---|
1378 | |
---|
1379 | 5.2.3. Cacheable Methods |
---|
1380 | |
---|
1381 | Request methods are considered "cacheable" if it is possible and |
---|
1382 | useful to answer a current client request with a stored response from |
---|
1383 | a prior request. GET and HEAD are defined to be cacheable. In |
---|
1384 | general, safe methods that do not depend on a current or |
---|
1385 | authoritative response are cacheable, though the overwhelming |
---|
1386 | majority of caches only support GET and HEAD. HTTP requirements for |
---|
1387 | cache behavior and cacheable responses are defined in [Part6]. |
---|
1388 | |
---|
1389 | 5.3. Method Definitions |
---|
1390 | |
---|
1391 | 5.3.1. GET |
---|
1392 | |
---|
1393 | The GET method requests transfer of a current representation of the |
---|
1394 | target resource. |
---|
1395 | |
---|
1396 | |
---|
1397 | |
---|
1398 | |
---|
1399 | Fielding & Reschke Expires April 7, 2013 [Page 25] |
---|
1400 | |
---|
1401 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
1402 | |
---|
1403 | |
---|
1404 | If the target resource is a data-producing process, it is the |
---|
1405 | produced data which shall be returned as the representation in the |
---|
1406 | response and not the source text of the process, unless that text |
---|
1407 | happens to be the output of the process. |
---|
1408 | |
---|
1409 | The semantics of the GET method change to a "conditional GET" if the |
---|
1410 | request message includes an If-Modified-Since, If-Unmodified-Since, |
---|
1411 | If-Match, If-None-Match, or If-Range header field ([Part4]). A |
---|
1412 | conditional GET requests that the representation be transferred only |
---|
1413 | under the circumstances described by the conditional header field(s). |
---|
1414 | The conditional GET request is intended to reduce unnecessary network |
---|
1415 | usage by allowing cached representations to be refreshed without |
---|
1416 | requiring multiple requests or transferring data already held by the |
---|
1417 | client. |
---|
1418 | |
---|
1419 | The semantics of the GET method change to a "partial GET" if the |
---|
1420 | request message includes a Range header field ([Part5]). A partial |
---|
1421 | GET requests that only part of the representation be transferred, as |
---|
1422 | described in Section 5.4 of [Part5]. The partial GET request is |
---|
1423 | intended to reduce unnecessary network usage by allowing partially- |
---|
1424 | retrieved representations to be completed without transferring data |
---|
1425 | already held by the client. |
---|
1426 | |
---|
1427 | A payload within a GET request message has no defined semantics; |
---|
1428 | sending a payload body on a GET request might cause some existing |
---|
1429 | implementations to reject the request. |
---|
1430 | |
---|
1431 | The response to a GET request is cacheable and MAY be used to satisfy |
---|
1432 | subsequent GET and HEAD requests (see [Part6]). |
---|
1433 | |
---|
1434 | See Section 10.2 for security considerations when used for forms. |
---|
1435 | |
---|
1436 | 5.3.2. HEAD |
---|
1437 | |
---|
1438 | The HEAD method is identical to GET except that the server MUST NOT |
---|
1439 | return a message body in the response. The metadata contained in the |
---|
1440 | HTTP header fields in response to a HEAD request SHOULD be identical |
---|
1441 | to the information sent in response to a GET request. This method |
---|
1442 | can be used for obtaining metadata about the representation implied |
---|
1443 | by the request without transferring the representation data. This |
---|
1444 | method is often used for testing hypertext links for validity, |
---|
1445 | accessibility, and recent modification. |
---|
1446 | |
---|
1447 | The response to a HEAD request is cacheable and MAY be used to |
---|
1448 | satisfy a subsequent HEAD request. It also has potential side |
---|
1449 | effects on previously stored responses to GET; see Section 5 of |
---|
1450 | [Part6]. |
---|
1451 | |
---|
1452 | |
---|
1453 | |
---|
1454 | |
---|
1455 | Fielding & Reschke Expires April 7, 2013 [Page 26] |
---|
1456 | |
---|
1457 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
1458 | |
---|
1459 | |
---|
1460 | A payload within a HEAD request message has no defined semantics; |
---|
1461 | sending a payload body on a HEAD request might cause some existing |
---|
1462 | implementations to reject the request. |
---|
1463 | |
---|
1464 | 5.3.3. POST |
---|
1465 | |
---|
1466 | The POST method requests that the origin server accept the |
---|
1467 | representation enclosed in the request as data to be processed by the |
---|
1468 | target resource. POST is designed to allow a uniform method to cover |
---|
1469 | the following functions: |
---|
1470 | |
---|
1471 | o Annotation of existing resources; |
---|
1472 | |
---|
1473 | o Posting a message to a bulletin board, newsgroup, mailing list, or |
---|
1474 | similar group of articles; |
---|
1475 | |
---|
1476 | o Providing a block of data, such as the result of submitting a |
---|
1477 | form, to a data-handling process; |
---|
1478 | |
---|
1479 | o Extending a database through an append operation. |
---|
1480 | |
---|
1481 | The actual function performed by the POST method is determined by the |
---|
1482 | server and is usually dependent on the effective request URI. |
---|
1483 | |
---|
1484 | The action performed by the POST method might not result in a |
---|
1485 | resource that can be identified by a URI. In this case, either 200 |
---|
1486 | (OK) or 204 (No Content) is the appropriate response status code, |
---|
1487 | depending on whether or not the response includes a representation |
---|
1488 | that describes the result. |
---|
1489 | |
---|
1490 | If a resource has been created on the origin server, the response |
---|
1491 | SHOULD be 201 (Created) and contain a representation which describes |
---|
1492 | the status of the request and refers to the new resource, and a |
---|
1493 | Location header field (see Section 8.1.2). |
---|
1494 | |
---|
1495 | Responses to POST requests are only cacheable when they include |
---|
1496 | explicit freshness information (see Section 4.1.1 of [Part6]). A |
---|
1497 | cached POST response with a Content-Location header field (see |
---|
1498 | Section 3.1.4.2) whose value is the effective Request URI MAY be used |
---|
1499 | to satisfy subsequent GET and HEAD (not POST) requests. |
---|
1500 | |
---|
1501 | Note that POST caching is not widely implemented. However, the 303 |
---|
1502 | (See Other) response can be used to direct the user agent to retrieve |
---|
1503 | a cacheable representation of the resource. |
---|
1504 | |
---|
1505 | |
---|
1506 | |
---|
1507 | |
---|
1508 | |
---|
1509 | |
---|
1510 | |
---|
1511 | Fielding & Reschke Expires April 7, 2013 [Page 27] |
---|
1512 | |
---|
1513 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
1514 | |
---|
1515 | |
---|
1516 | 5.3.4. PUT |
---|
1517 | |
---|
1518 | The PUT method requests that the state of the target resource be |
---|
1519 | created or replaced with the state defined by the representation |
---|
1520 | enclosed in the request message payload. A successful PUT of a given |
---|
1521 | representation would suggest that a subsequent GET on that same |
---|
1522 | target resource will result in an equivalent representation being |
---|
1523 | returned in a 200 (OK) response. However, there is no guarantee that |
---|
1524 | such a state change will be observable, since the target resource |
---|
1525 | might be acted upon by other user agents in parallel, or might be |
---|
1526 | subject to dynamic processing by the origin server, before any |
---|
1527 | subsequent GET is received. A successful response only implies that |
---|
1528 | the user agent's intent was achieved at the time of its processing by |
---|
1529 | the origin server. |
---|
1530 | |
---|
1531 | If the target resource does not have a current representation and the |
---|
1532 | PUT successfully creates one, then the origin server MUST inform the |
---|
1533 | user agent by sending a 201 (Created) response. If the target |
---|
1534 | resource does have a current representation and that representation |
---|
1535 | is successfully modified in accordance with the state of the enclosed |
---|
1536 | representation, then either a 200 (OK) or 204 (No Content) response |
---|
1537 | SHOULD be sent to indicate successful completion of the request. |
---|
1538 | |
---|
1539 | Unrecognized header fields SHOULD be ignored (i.e., not saved as part |
---|
1540 | of the resource state). |
---|
1541 | |
---|
1542 | An origin server SHOULD verify that the PUT representation is |
---|
1543 | consistent with any constraints which the server has for the target |
---|
1544 | resource that cannot or will not be changed by the PUT. This is |
---|
1545 | particularly important when the origin server uses internal |
---|
1546 | configuration information related to the URI in order to set the |
---|
1547 | values for representation metadata on GET responses. When a PUT |
---|
1548 | representation is inconsistent with the target resource, the origin |
---|
1549 | server SHOULD either make them consistent, by transforming the |
---|
1550 | representation or changing the resource configuration, or respond |
---|
1551 | with an appropriate error message containing sufficient information |
---|
1552 | to explain why the representation is unsuitable. The 409 (Conflict) |
---|
1553 | or 415 (Unsupported Media Type) status codes are suggested, with the |
---|
1554 | latter being specific to constraints on Content-Type values. |
---|
1555 | |
---|
1556 | For example, if the target resource is configured to always have a |
---|
1557 | Content-Type of "text/html" and the representation being PUT has a |
---|
1558 | Content-Type of "image/jpeg", then the origin server SHOULD do one |
---|
1559 | of: |
---|
1560 | |
---|
1561 | a. reconfigure the target resource to reflect the new media type; |
---|
1562 | |
---|
1563 | |
---|
1564 | |
---|
1565 | |
---|
1566 | |
---|
1567 | Fielding & Reschke Expires April 7, 2013 [Page 28] |
---|
1568 | |
---|
1569 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
1570 | |
---|
1571 | |
---|
1572 | b. transform the PUT representation to a format consistent with that |
---|
1573 | of the resource before saving it as the new resource state; or, |
---|
1574 | |
---|
1575 | c. reject the request with a 415 (Unsupported Media Type) response |
---|
1576 | indicating that the target resource is limited to "text/html", |
---|
1577 | perhaps including a link to a different resource that would be a |
---|
1578 | suitable target for the new representation. |
---|
1579 | |
---|
1580 | HTTP does not define exactly how a PUT method affects the state of an |
---|
1581 | origin server beyond what can be expressed by the intent of the user |
---|
1582 | agent request and the semantics of the origin server response. It |
---|
1583 | does not define what a resource might be, in any sense of that word, |
---|
1584 | beyond the interface provided via HTTP. It does not define how |
---|
1585 | resource state is "stored", nor how such storage might change as a |
---|
1586 | result of a change in resource state, nor how the origin server |
---|
1587 | translates resource state into representations. Generally speaking, |
---|
1588 | all implementation details behind the resource interface are |
---|
1589 | intentionally hidden by the server. |
---|
1590 | |
---|
1591 | The fundamental difference between the POST and PUT methods is |
---|
1592 | highlighted by the different intent for the target resource. The |
---|
1593 | target resource in a POST request is intended to handle the enclosed |
---|
1594 | representation as a data-accepting process, such as for a gateway to |
---|
1595 | some other protocol or a document that accepts annotations. In |
---|
1596 | contrast, the target resource in a PUT request is intended to take |
---|
1597 | the enclosed representation as a new or replacement value. Hence, |
---|
1598 | the intent of PUT is idempotent and visible to intermediaries, even |
---|
1599 | though the exact effect is only known by the origin server. |
---|
1600 | |
---|
1601 | Proper interpretation of a PUT request presumes that the user agent |
---|
1602 | knows what target resource is desired. A service that is intended to |
---|
1603 | select a proper URI on behalf of the client, after receiving a state- |
---|
1604 | changing request, SHOULD be implemented using the POST method rather |
---|
1605 | than PUT. If the origin server will not make the requested PUT state |
---|
1606 | change to the target resource and instead wishes to have it applied |
---|
1607 | to a different resource, such as when the resource has been moved to |
---|
1608 | a different URI, then the origin server MUST send a 301 (Moved |
---|
1609 | Permanently) response; the user agent MAY then make its own decision |
---|
1610 | regarding whether or not to redirect the request. |
---|
1611 | |
---|
1612 | A PUT request applied to the target resource MAY have side-effects on |
---|
1613 | other resources. For example, an article might have a URI for |
---|
1614 | identifying "the current version" (a resource) which is separate from |
---|
1615 | the URIs identifying each particular version (different resources |
---|
1616 | that at one point shared the same state as the current version |
---|
1617 | resource). A successful PUT request on "the current version" URI |
---|
1618 | might therefore create a new version resource in addition to changing |
---|
1619 | the state of the target resource, and might also cause links to be |
---|
1620 | |
---|
1621 | |
---|
1622 | |
---|
1623 | Fielding & Reschke Expires April 7, 2013 [Page 29] |
---|
1624 | |
---|
1625 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
1626 | |
---|
1627 | |
---|
1628 | added between the related resources. |
---|
1629 | |
---|
1630 | An origin server SHOULD reject any PUT request that contains a |
---|
1631 | Content-Range header field (Section 5.2 of [Part5]), since it might |
---|
1632 | be misinterpreted as partial content (or might be partial content |
---|
1633 | that is being mistakenly PUT as a full representation). Partial |
---|
1634 | content updates are possible by targeting a separately identified |
---|
1635 | resource with state that overlaps a portion of the larger resource, |
---|
1636 | or by using a different method that has been specifically defined for |
---|
1637 | partial updates (for example, the PATCH method defined in [RFC5789]). |
---|
1638 | |
---|
1639 | Responses to the PUT method are not cacheable. If a PUT request |
---|
1640 | passes through a cache that has one or more stored responses for the |
---|
1641 | effective request URI, those stored responses will be invalidated |
---|
1642 | (see Section 6 of [Part6]). |
---|
1643 | |
---|
1644 | 5.3.5. DELETE |
---|
1645 | |
---|
1646 | The DELETE method requests that the origin server delete the target |
---|
1647 | resource. This method MAY be overridden by human intervention (or |
---|
1648 | other means) on the origin server. The client cannot be guaranteed |
---|
1649 | that the operation has been carried out, even if the status code |
---|
1650 | returned from the origin server indicates that the action has been |
---|
1651 | completed successfully. However, the server SHOULD NOT indicate |
---|
1652 | success unless, at the time the response is given, it intends to |
---|
1653 | delete the resource or move it to an inaccessible location. |
---|
1654 | |
---|
1655 | A successful response SHOULD be 200 (OK) if the response includes a |
---|
1656 | representation describing the status, 202 (Accepted) if the action |
---|
1657 | has not yet been enacted, or 204 (No Content) if the action has been |
---|
1658 | enacted but the response does not include a representation. |
---|
1659 | |
---|
1660 | A payload within a DELETE request message has no defined semantics; |
---|
1661 | sending a payload body on a DELETE request might cause some existing |
---|
1662 | implementations to reject the request. |
---|
1663 | |
---|
1664 | Responses to the DELETE method are not cacheable. If a DELETE |
---|
1665 | request passes through a cache that has one or more stored responses |
---|
1666 | for the effective request URI, those stored responses will be |
---|
1667 | invalidated (see Section 6 of [Part6]). |
---|
1668 | |
---|
1669 | 5.3.6. CONNECT |
---|
1670 | |
---|
1671 | The CONNECT method requests that the proxy establish a tunnel to the |
---|
1672 | request-target and, if successful, thereafter restrict its behavior |
---|
1673 | to blind forwarding of packets until the connection is closed. |
---|
1674 | |
---|
1675 | When using CONNECT, the request-target MUST use the authority form |
---|
1676 | |
---|
1677 | |
---|
1678 | |
---|
1679 | Fielding & Reschke Expires April 7, 2013 [Page 30] |
---|
1680 | |
---|
1681 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
1682 | |
---|
1683 | |
---|
1684 | (Section 5.3 of [Part1]); i.e., the request-target consists of only |
---|
1685 | the host name and port number of the tunnel destination, separated by |
---|
1686 | a colon. For example, |
---|
1687 | |
---|
1688 | CONNECT server.example.com:80 HTTP/1.1 |
---|
1689 | Host: server.example.com:80 |
---|
1690 | |
---|
1691 | |
---|
1692 | Any 2xx (Successful) response to a CONNECT request indicates that the |
---|
1693 | proxy has established a connection to the requested host and port, |
---|
1694 | and has switched to tunneling the current connection to that server |
---|
1695 | connection. The tunneled data from the server begins immediately |
---|
1696 | after the blank line that concludes the successful response's header |
---|
1697 | block. |
---|
1698 | |
---|
1699 | A server SHOULD NOT send any Transfer-Encoding or Content-Length |
---|
1700 | header fields in a successful response. A client MUST ignore any |
---|
1701 | Content-Length or Transfer-Encoding header fields received in a |
---|
1702 | successful response. |
---|
1703 | |
---|
1704 | Any response other than a successful response indicates that the |
---|
1705 | tunnel has not yet been formed and that the connection remains |
---|
1706 | governed by HTTP. |
---|
1707 | |
---|
1708 | Proxy authentication might be used to establish the authority to |
---|
1709 | create a tunnel: |
---|
1710 | |
---|
1711 | CONNECT server.example.com:80 HTTP/1.1 |
---|
1712 | Host: server.example.com:80 |
---|
1713 | Proxy-Authorization: basic aGVsbG86d29ybGQ= |
---|
1714 | |
---|
1715 | |
---|
1716 | A payload within a CONNECT request message has no defined semantics; |
---|
1717 | sending a payload body on a CONNECT request might cause some existing |
---|
1718 | implementations to reject the request. |
---|
1719 | |
---|
1720 | Similar to a pipelined HTTP/1.1 request, data to be tunneled from |
---|
1721 | client to server MAY be sent immediately after the request (before a |
---|
1722 | response is received). The usual caveats also apply: data can be |
---|
1723 | discarded if the eventual response is negative, and the connection |
---|
1724 | can be reset with no response if more than one TCP segment is |
---|
1725 | outstanding. |
---|
1726 | |
---|
1727 | It might be the case that the proxy itself can only reach the |
---|
1728 | requested origin server through another proxy. In this case, the |
---|
1729 | first proxy SHOULD make a CONNECT request of that next proxy, |
---|
1730 | requesting a tunnel to the authority. A proxy MUST NOT respond with |
---|
1731 | any 2xx status code unless it has either a direct or tunnel |
---|
1732 | |
---|
1733 | |
---|
1734 | |
---|
1735 | Fielding & Reschke Expires April 7, 2013 [Page 31] |
---|
1736 | |
---|
1737 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
1738 | |
---|
1739 | |
---|
1740 | connection established to the authority. |
---|
1741 | |
---|
1742 | If at any point either one of the peers gets disconnected, any |
---|
1743 | outstanding data that came from that peer will be passed to the other |
---|
1744 | one, and after that also the other connection will be terminated by |
---|
1745 | the proxy. If there is outstanding data to that peer undelivered, |
---|
1746 | that data will be discarded. |
---|
1747 | |
---|
1748 | An origin server which receives a CONNECT request for itself MAY |
---|
1749 | respond with a 2xx status code to indicate that a connection is |
---|
1750 | established. However, most origin servers do not implement CONNECT. |
---|
1751 | |
---|
1752 | 5.3.7. OPTIONS |
---|
1753 | |
---|
1754 | The OPTIONS method requests information about the communication |
---|
1755 | options available on the request/response chain identified by the |
---|
1756 | effective request URI. This method allows a client to determine the |
---|
1757 | options and/or requirements associated with a resource, or the |
---|
1758 | capabilities of a server, without implying a resource action or |
---|
1759 | initiating a resource retrieval. |
---|
1760 | |
---|
1761 | Responses to the OPTIONS method are not cacheable. |
---|
1762 | |
---|
1763 | If the OPTIONS request includes a payload, then the media type MUST |
---|
1764 | be indicated by a Content-Type field. Although this specification |
---|
1765 | does not define any use for such a body, future extensions to HTTP |
---|
1766 | might use the OPTIONS body to make more detailed queries on the |
---|
1767 | server. |
---|
1768 | |
---|
1769 | If the request-target (Section 5.3 of [Part1]) is an asterisk ("*"), |
---|
1770 | the OPTIONS request is intended to apply to the server in general |
---|
1771 | rather than to a specific resource. Since a server's communication |
---|
1772 | options typically depend on the resource, the "*" request is only |
---|
1773 | useful as a "ping" or "no-op" type of method; it does nothing beyond |
---|
1774 | allowing the client to test the capabilities of the server. For |
---|
1775 | example, this can be used to test a proxy for HTTP/1.1 conformance |
---|
1776 | (or lack thereof). |
---|
1777 | |
---|
1778 | If the request-target is not an asterisk, the OPTIONS request applies |
---|
1779 | only to the options that are available when communicating with that |
---|
1780 | resource. |
---|
1781 | |
---|
1782 | A 200 (OK) response SHOULD include any header fields that indicate |
---|
1783 | optional features implemented by the server and applicable to that |
---|
1784 | resource (e.g., Allow), possibly including extensions not defined by |
---|
1785 | this specification. The response payload, if any, SHOULD also |
---|
1786 | include information about the communication options. The format for |
---|
1787 | such a payload is not defined by this specification, but might be |
---|
1788 | |
---|
1789 | |
---|
1790 | |
---|
1791 | Fielding & Reschke Expires April 7, 2013 [Page 32] |
---|
1792 | |
---|
1793 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
1794 | |
---|
1795 | |
---|
1796 | defined by future extensions to HTTP. Content negotiation MAY be |
---|
1797 | used to select the appropriate representation. If no payload body is |
---|
1798 | included, the response MUST include a Content-Length field with a |
---|
1799 | field-value of "0". |
---|
1800 | |
---|
1801 | The Max-Forwards header field MAY be used to target a specific proxy |
---|
1802 | in the request chain (see Section 6.1.1). If no Max-Forwards field |
---|
1803 | is present in the request, then the forwarded request MUST NOT |
---|
1804 | include a Max-Forwards field. |
---|
1805 | |
---|
1806 | 5.3.8. TRACE |
---|
1807 | |
---|
1808 | The TRACE method requests a remote, application-level loop-back of |
---|
1809 | the request message. The final recipient of the request SHOULD |
---|
1810 | reflect the message received back to the client as the message body |
---|
1811 | of a 200 (OK) response. The final recipient is either the origin |
---|
1812 | server or the first proxy to receive a Max-Forwards value of zero (0) |
---|
1813 | in the request (see Section 6.1.1). A TRACE request MUST NOT include |
---|
1814 | a message body. |
---|
1815 | |
---|
1816 | TRACE allows the client to see what is being received at the other |
---|
1817 | end of the request chain and use that data for testing or diagnostic |
---|
1818 | information. The value of the Via header field (Section 5.7 of |
---|
1819 | [Part1]) is of particular interest, since it acts as a trace of the |
---|
1820 | request chain. Use of the Max-Forwards header field allows the |
---|
1821 | client to limit the length of the request chain, which is useful for |
---|
1822 | testing a chain of proxies forwarding messages in an infinite loop. |
---|
1823 | |
---|
1824 | If the request is valid, the response SHOULD have a Content-Type of |
---|
1825 | "message/http" (see Section 7.3.1 of [Part1]) and contain a message |
---|
1826 | body that encloses a copy of the entire request message. Responses |
---|
1827 | to the TRACE method are not cacheable. |
---|
1828 | |
---|
1829 | 6. Request Header Fields |
---|
1830 | |
---|
1831 | A client sends request header fields to provide more information |
---|
1832 | about the request context, make the request conditional based on the |
---|
1833 | target resource state, suggest preferred formats for the response, |
---|
1834 | supply authentication credentials, or modify the expected request |
---|
1835 | processing. These fields act as request modifiers, similar to the |
---|
1836 | parameters on a programming language method invocation. |
---|
1837 | |
---|
1838 | 6.1. Controls |
---|
1839 | |
---|
1840 | Controls are request header fields that direct specific handling of |
---|
1841 | the request. |
---|
1842 | |
---|
1843 | |
---|
1844 | |
---|
1845 | |
---|
1846 | |
---|
1847 | Fielding & Reschke Expires April 7, 2013 [Page 33] |
---|
1848 | |
---|
1849 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
1850 | |
---|
1851 | |
---|
1852 | +-------------------+------------------------+ |
---|
1853 | | Header Field Name | Defined in... | |
---|
1854 | +-------------------+------------------------+ |
---|
1855 | | Host | Section 5.4 of [Part1] | |
---|
1856 | | Max-Forwards | Section 6.1.1 | |
---|
1857 | | Expect | Section 6.1.2 | |
---|
1858 | | Range | Section 5.4 of [Part5] | |
---|
1859 | +-------------------+------------------------+ |
---|
1860 | |
---|
1861 | 6.1.1. Max-Forwards |
---|
1862 | |
---|
1863 | The "Max-Forwards" header field provides a mechanism with the TRACE |
---|
1864 | (Section 5.3.8) and OPTIONS (Section 5.3.7) methods to limit the |
---|
1865 | number of times that the request is forwarded by proxies. This can |
---|
1866 | be useful when the client is attempting to trace a request which |
---|
1867 | appears to be failing or looping mid-chain. |
---|
1868 | |
---|
1869 | Max-Forwards = 1*DIGIT |
---|
1870 | |
---|
1871 | The Max-Forwards value is a decimal integer indicating the remaining |
---|
1872 | number of times this request message can be forwarded. |
---|
1873 | |
---|
1874 | Each recipient of a TRACE or OPTIONS request containing a Max- |
---|
1875 | Forwards header field MUST check and update its value prior to |
---|
1876 | forwarding the request. If the received value is zero (0), the |
---|
1877 | recipient MUST NOT forward the request; instead, it MUST respond as |
---|
1878 | the final recipient. If the received Max-Forwards value is greater |
---|
1879 | than zero, then the forwarded message MUST contain an updated Max- |
---|
1880 | Forwards field with a value decremented by one (1). |
---|
1881 | |
---|
1882 | The Max-Forwards header field MAY be ignored for all other request |
---|
1883 | methods. |
---|
1884 | |
---|
1885 | 6.1.2. Expect |
---|
1886 | |
---|
1887 | The "Expect" header field is used to indicate that particular server |
---|
1888 | behaviors are required by the client. |
---|
1889 | |
---|
1890 | Expect = 1#expectation |
---|
1891 | |
---|
1892 | expectation = expect-name [ BWS "=" BWS expect-value ] |
---|
1893 | *( OWS ";" [ OWS expect-param ] ) |
---|
1894 | expect-param = expect-name [ BWS "=" BWS expect-value ] |
---|
1895 | |
---|
1896 | expect-name = token |
---|
1897 | expect-value = token / quoted-string |
---|
1898 | |
---|
1899 | If all received Expect header field(s) are syntactically valid but |
---|
1900 | |
---|
1901 | |
---|
1902 | |
---|
1903 | Fielding & Reschke Expires April 7, 2013 [Page 34] |
---|
1904 | |
---|
1905 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
1906 | |
---|
1907 | |
---|
1908 | contain an expectation that the recipient does not understand or |
---|
1909 | cannot comply with, the recipient MUST respond with a 417 |
---|
1910 | (Expectation Failed) status code. A recipient of a syntactically |
---|
1911 | invalid Expectation header field MUST respond with a 4xx status code |
---|
1912 | other than 417. |
---|
1913 | |
---|
1914 | The only expectation defined by this specification is: |
---|
1915 | |
---|
1916 | 100-continue |
---|
1917 | |
---|
1918 | The "100-continue" expectation is defined below. It does not |
---|
1919 | support any expect-params. |
---|
1920 | |
---|
1921 | Comparison is case-insensitive for names (expect-name), and case- |
---|
1922 | sensitive for values (expect-value). |
---|
1923 | |
---|
1924 | The Expect mechanism is hop-by-hop: the above requirements apply to |
---|
1925 | any server, including proxies. However, the Expect header field |
---|
1926 | itself is end-to-end; it MUST be forwarded if the request is |
---|
1927 | forwarded. |
---|
1928 | |
---|
1929 | Many older HTTP/1.0 and HTTP/1.1 applications do not understand the |
---|
1930 | Expect header field. |
---|
1931 | |
---|
1932 | 6.1.2.1. Use of the 100 (Continue) Status |
---|
1933 | |
---|
1934 | The purpose of the 100 (Continue) status code (Section 7.2.1) is to |
---|
1935 | allow a client that is sending a request message with a payload to |
---|
1936 | determine if the origin server is willing to accept the request |
---|
1937 | (based on the request header fields) before the client sends the |
---|
1938 | payload body. In some cases, it might either be inappropriate or |
---|
1939 | highly inefficient for the client to send the payload body if the |
---|
1940 | server will reject the message without looking at the body. |
---|
1941 | |
---|
1942 | Requirements for HTTP/1.1 clients: |
---|
1943 | |
---|
1944 | o If a client will wait for a 100 (Continue) response before sending |
---|
1945 | the payload body, it MUST send an Expect header field with the |
---|
1946 | "100-continue" expectation. |
---|
1947 | |
---|
1948 | o A client MUST NOT send an Expect header field with the "100- |
---|
1949 | continue" expectation if it does not intend to send a payload |
---|
1950 | body. |
---|
1951 | |
---|
1952 | Because of the presence of older implementations, the protocol allows |
---|
1953 | ambiguous situations in which a client might send "Expect: 100- |
---|
1954 | continue" without receiving either a 417 (Expectation Failed) or a |
---|
1955 | 100 (Continue) status code. Therefore, when a client sends this |
---|
1956 | |
---|
1957 | |
---|
1958 | |
---|
1959 | Fielding & Reschke Expires April 7, 2013 [Page 35] |
---|
1960 | |
---|
1961 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
1962 | |
---|
1963 | |
---|
1964 | header field to an origin server (possibly via a proxy) from which it |
---|
1965 | has never seen a 100 (Continue) status code, the client SHOULD NOT |
---|
1966 | wait for an indefinite period before sending the payload body. |
---|
1967 | |
---|
1968 | Requirements for HTTP/1.1 origin servers: |
---|
1969 | |
---|
1970 | o Upon receiving a request which includes an Expect header field |
---|
1971 | with the "100-continue" expectation, an origin server MUST either |
---|
1972 | respond with 100 (Continue) status code and continue to read from |
---|
1973 | the input stream, or respond with a final status code. The origin |
---|
1974 | server MUST NOT wait for the payload body before sending the 100 |
---|
1975 | (Continue) response. If it responds with a final status code, it |
---|
1976 | MAY close the transport connection or it MAY continue to read and |
---|
1977 | discard the rest of the request. It MUST NOT perform the request |
---|
1978 | method if it returns a final status code. |
---|
1979 | |
---|
1980 | o An origin server SHOULD NOT send a 100 (Continue) response if the |
---|
1981 | request message does not include an Expect header field with the |
---|
1982 | "100-continue" expectation, and MUST NOT send a 100 (Continue) |
---|
1983 | response if such a request comes from an HTTP/1.0 (or earlier) |
---|
1984 | client. There is an exception to this rule: for compatibility |
---|
1985 | with [RFC2068], a server MAY send a 100 (Continue) status code in |
---|
1986 | response to an HTTP/1.1 PUT or POST request that does not include |
---|
1987 | an Expect header field with the "100-continue" expectation. This |
---|
1988 | exception, the purpose of which is to minimize any client |
---|
1989 | processing delays associated with an undeclared wait for 100 |
---|
1990 | (Continue) status code, applies only to HTTP/1.1 requests, and not |
---|
1991 | to requests with any other HTTP-version value. |
---|
1992 | |
---|
1993 | o An origin server MAY omit a 100 (Continue) response if it has |
---|
1994 | already received some or all of the payload body for the |
---|
1995 | corresponding request. |
---|
1996 | |
---|
1997 | o An origin server that sends a 100 (Continue) response MUST |
---|
1998 | ultimately send a final status code, once the payload body is |
---|
1999 | received and processed, unless it terminates the transport |
---|
2000 | connection prematurely. |
---|
2001 | |
---|
2002 | o If an origin server receives a request that does not include an |
---|
2003 | Expect header field with the "100-continue" expectation, the |
---|
2004 | request includes a payload body, and the server responds with a |
---|
2005 | final status code before reading the entire payload body from the |
---|
2006 | transport connection, then the server SHOULD NOT close the |
---|
2007 | transport connection until it has read the entire request, or |
---|
2008 | until the client closes the connection. Otherwise, the client |
---|
2009 | might not reliably receive the response message. However, this |
---|
2010 | requirement ought not be construed as preventing a server from |
---|
2011 | defending itself against denial-of-service attacks, or from badly |
---|
2012 | |
---|
2013 | |
---|
2014 | |
---|
2015 | Fielding & Reschke Expires April 7, 2013 [Page 36] |
---|
2016 | |
---|
2017 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
2018 | |
---|
2019 | |
---|
2020 | broken client implementations. |
---|
2021 | |
---|
2022 | Requirements for HTTP/1.1 proxies: |
---|
2023 | |
---|
2024 | o If a proxy receives a request that includes an Expect header field |
---|
2025 | with the "100-continue" expectation, and the proxy either knows |
---|
2026 | that the next-hop server complies with HTTP/1.1 or higher, or does |
---|
2027 | not know the HTTP version of the next-hop server, it MUST forward |
---|
2028 | the request, including the Expect header field. |
---|
2029 | |
---|
2030 | o If the proxy knows that the version of the next-hop server is |
---|
2031 | HTTP/1.0 or lower, it MUST NOT forward the request, and it MUST |
---|
2032 | respond with a 417 (Expectation Failed) status code. |
---|
2033 | |
---|
2034 | o Proxies SHOULD maintain a record of the HTTP version numbers |
---|
2035 | received from recently-referenced next-hop servers. |
---|
2036 | |
---|
2037 | o A proxy MUST NOT forward a 100 (Continue) response if the request |
---|
2038 | message was received from an HTTP/1.0 (or earlier) client and did |
---|
2039 | not include an Expect header field with the "100-continue" |
---|
2040 | expectation. This requirement overrides the general rule for |
---|
2041 | forwarding of 1xx responses (see Section 7.2.1). |
---|
2042 | |
---|
2043 | 6.2. Conditionals |
---|
2044 | |
---|
2045 | Conditionals are request header fields that indicate a precondition |
---|
2046 | to be tested before applying the method semantics to the target |
---|
2047 | resource. Each precondition is based on metadata that is expected to |
---|
2048 | change if the selected representation of the target resource is |
---|
2049 | changed. The HTTP/1.1 conditional request mechanisms are defined in |
---|
2050 | [Part4]. |
---|
2051 | |
---|
2052 | +---------------------+------------------------+ |
---|
2053 | | Header Field Name | Defined in... | |
---|
2054 | +---------------------+------------------------+ |
---|
2055 | | If-Match | Section 3.1 of [Part4] | |
---|
2056 | | If-None-Match | Section 3.2 of [Part4] | |
---|
2057 | | If-Modified-Since | Section 3.3 of [Part4] | |
---|
2058 | | If-Unmodified-Since | Section 3.4 of [Part4] | |
---|
2059 | | If-Range | Section 5.3 of [Part5] | |
---|
2060 | +---------------------+------------------------+ |
---|
2061 | |
---|
2062 | |
---|
2063 | |
---|
2064 | |
---|
2065 | |
---|
2066 | |
---|
2067 | |
---|
2068 | |
---|
2069 | |
---|
2070 | |
---|
2071 | Fielding & Reschke Expires April 7, 2013 [Page 37] |
---|
2072 | |
---|
2073 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
2074 | |
---|
2075 | |
---|
2076 | 6.3. Content Negotiation |
---|
2077 | |
---|
2078 | +-------------------+---------------+ |
---|
2079 | | Header Field Name | Defined in... | |
---|
2080 | +-------------------+---------------+ |
---|
2081 | | Accept | Section 6.3.2 | |
---|
2082 | | Accept-Charset | Section 6.3.3 | |
---|
2083 | | Accept-Encoding | Section 6.3.4 | |
---|
2084 | | Accept-Language | Section 6.3.5 | |
---|
2085 | +-------------------+---------------+ |
---|
2086 | |
---|
2087 | 6.3.1. Quality Values |
---|
2088 | |
---|
2089 | Many of the request header fields for proactive content negotiation |
---|
2090 | use a common parameter, named "q" (case-insensitive), to assign a |
---|
2091 | relative "weight" to the preference for that associated kind of |
---|
2092 | content. This weight is referred to as a "quality value" (or |
---|
2093 | "qvalue") because the same parameter name is often used within server |
---|
2094 | configurations to assign a weight to the relative quality of the |
---|
2095 | various representations that can be selected for a resource. |
---|
2096 | |
---|
2097 | The weight is normalized to a real number in the range 0 through 1, |
---|
2098 | where 0.001 is the least preferred and 1 is the most preferred; a |
---|
2099 | value of 0 means "not acceptable". If no "q" parameter is present, |
---|
2100 | the default weight is 1. |
---|
2101 | |
---|
2102 | weight = OWS ";" OWS "q=" qvalue |
---|
2103 | qvalue = ( "0" [ "." 0*3DIGIT ] ) |
---|
2104 | / ( "1" [ "." 0*3("0") ] ) |
---|
2105 | |
---|
2106 | A sender of qvalue MUST NOT generate more than three digits after the |
---|
2107 | decimal point. User configuration of these values ought to be |
---|
2108 | limited in the same fashion. |
---|
2109 | |
---|
2110 | 6.3.2. Accept |
---|
2111 | |
---|
2112 | The "Accept" header field can be used by user agents to specify |
---|
2113 | response media types that are acceptable. Accept header fields can |
---|
2114 | be used to indicate that the request is specifically limited to a |
---|
2115 | small set of desired types, as in the case of a request for an in- |
---|
2116 | line image. |
---|
2117 | |
---|
2118 | |
---|
2119 | |
---|
2120 | |
---|
2121 | |
---|
2122 | |
---|
2123 | |
---|
2124 | |
---|
2125 | |
---|
2126 | |
---|
2127 | Fielding & Reschke Expires April 7, 2013 [Page 38] |
---|
2128 | |
---|
2129 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
2130 | |
---|
2131 | |
---|
2132 | Accept = #( media-range [ accept-params ] ) |
---|
2133 | |
---|
2134 | media-range = ( "*/*" |
---|
2135 | / ( type "/" "*" ) |
---|
2136 | / ( type "/" subtype ) |
---|
2137 | ) *( OWS ";" OWS parameter ) |
---|
2138 | accept-params = weight *( accept-ext ) |
---|
2139 | accept-ext = OWS ";" OWS token [ "=" word ] |
---|
2140 | |
---|
2141 | The asterisk "*" character is used to group media types into ranges, |
---|
2142 | with "*/*" indicating all media types and "type/*" indicating all |
---|
2143 | subtypes of that type. The media-range MAY include media type |
---|
2144 | parameters that are applicable to that range. |
---|
2145 | |
---|
2146 | Each media-range MAY be followed by one or more accept-params, |
---|
2147 | beginning with the "q" parameter for indicating a relative weight, as |
---|
2148 | defined in Section 6.3.1. The first "q" parameter (if any) separates |
---|
2149 | the media-range parameter(s) from the accept-params. |
---|
2150 | |
---|
2151 | Note: Use of the "q" parameter name to separate media type |
---|
2152 | parameters from Accept extension parameters is due to historical |
---|
2153 | practice. Although this prevents any media type parameter named |
---|
2154 | "q" from being used with a media range, such an event is believed |
---|
2155 | to be unlikely given the lack of any "q" parameters in the IANA |
---|
2156 | media type registry and the rare usage of any media type |
---|
2157 | parameters in Accept. Future media types are discouraged from |
---|
2158 | registering any parameter named "q". |
---|
2159 | |
---|
2160 | The example |
---|
2161 | |
---|
2162 | Accept: audio/*; q=0.2, audio/basic |
---|
2163 | |
---|
2164 | SHOULD be interpreted as "I prefer audio/basic, but send me any audio |
---|
2165 | type if it is the best available after an 80% mark-down in quality". |
---|
2166 | |
---|
2167 | A request without any Accept header field implies that the user agent |
---|
2168 | will accept any media type in response. If an Accept header field is |
---|
2169 | present in a request and none of the available representations for |
---|
2170 | the response have a media type that is listed as acceptable, the |
---|
2171 | origin server MAY either honor the Accept header field by sending a |
---|
2172 | 406 (Not Acceptable) response or disregard the Accept header field by |
---|
2173 | treating the response as if it is not subject to content negotiation. |
---|
2174 | |
---|
2175 | A more elaborate example is |
---|
2176 | |
---|
2177 | Accept: text/plain; q=0.5, text/html, |
---|
2178 | text/x-dvi; q=0.8, text/x-c |
---|
2179 | |
---|
2180 | |
---|
2181 | |
---|
2182 | |
---|
2183 | Fielding & Reschke Expires April 7, 2013 [Page 39] |
---|
2184 | |
---|
2185 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
2186 | |
---|
2187 | |
---|
2188 | Verbally, this would be interpreted as "text/html and text/x-c are |
---|
2189 | the preferred media types, but if they do not exist, then send the |
---|
2190 | text/x-dvi representation, and if that does not exist, send the text/ |
---|
2191 | plain representation". |
---|
2192 | |
---|
2193 | Media ranges can be overridden by more specific media ranges or |
---|
2194 | specific media types. If more than one media range applies to a |
---|
2195 | given type, the most specific reference has precedence. For example, |
---|
2196 | |
---|
2197 | Accept: text/*, text/plain, text/plain;format=flowed, */* |
---|
2198 | |
---|
2199 | have the following precedence: |
---|
2200 | |
---|
2201 | 1. text/plain;format=flowed |
---|
2202 | |
---|
2203 | 2. text/plain |
---|
2204 | |
---|
2205 | 3. text/* |
---|
2206 | |
---|
2207 | 4. */* |
---|
2208 | |
---|
2209 | The media type quality factor associated with a given type is |
---|
2210 | determined by finding the media range with the highest precedence |
---|
2211 | which matches that type. For example, |
---|
2212 | |
---|
2213 | Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1, |
---|
2214 | text/html;level=2;q=0.4, */*;q=0.5 |
---|
2215 | |
---|
2216 | would cause the following values to be associated: |
---|
2217 | |
---|
2218 | +-------------------+---------------+ |
---|
2219 | | Media Type | Quality Value | |
---|
2220 | +-------------------+---------------+ |
---|
2221 | | text/html;level=1 | 1 | |
---|
2222 | | text/html | 0.7 | |
---|
2223 | | text/plain | 0.3 | |
---|
2224 | | image/jpeg | 0.5 | |
---|
2225 | | text/html;level=2 | 0.4 | |
---|
2226 | | text/html;level=3 | 0.7 | |
---|
2227 | +-------------------+---------------+ |
---|
2228 | |
---|
2229 | Note: A user agent might be provided with a default set of quality |
---|
2230 | values for certain media ranges. However, unless the user agent is a |
---|
2231 | closed system which cannot interact with other rendering agents, this |
---|
2232 | default set ought to be configurable by the user. |
---|
2233 | |
---|
2234 | |
---|
2235 | |
---|
2236 | |
---|
2237 | |
---|
2238 | |
---|
2239 | Fielding & Reschke Expires April 7, 2013 [Page 40] |
---|
2240 | |
---|
2241 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
2242 | |
---|
2243 | |
---|
2244 | 6.3.3. Accept-Charset |
---|
2245 | |
---|
2246 | The "Accept-Charset" header field can be used by user agents to |
---|
2247 | indicate what character encodings are acceptable in a response |
---|
2248 | payload. This field allows clients capable of understanding more |
---|
2249 | comprehensive or special-purpose character encodings to signal that |
---|
2250 | capability to a server which is capable of representing documents in |
---|
2251 | those character encodings. |
---|
2252 | |
---|
2253 | Accept-Charset = 1#( ( charset / "*" ) [ weight ] ) |
---|
2254 | |
---|
2255 | Character encoding values (a.k.a., charsets) are described in |
---|
2256 | Section 3.1.1.2. Each charset MAY be given an associated quality |
---|
2257 | value which represents the user's preference for that charset, as |
---|
2258 | defined in Section 6.3.1. An example is |
---|
2259 | |
---|
2260 | Accept-Charset: iso-8859-5, unicode-1-1;q=0.8 |
---|
2261 | |
---|
2262 | The special value "*", if present in the Accept-Charset field, |
---|
2263 | matches every character encoding which is not mentioned elsewhere in |
---|
2264 | the Accept-Charset field. If no "*" is present in an Accept-Charset |
---|
2265 | field, then any character encodings not explicitly mentioned in the |
---|
2266 | field are considered "not acceptable" to the client. |
---|
2267 | |
---|
2268 | A request without any Accept-Charset header field implies that the |
---|
2269 | user agent will accept any character encoding in response. |
---|
2270 | |
---|
2271 | If an Accept-Charset header field is present in a request and none of |
---|
2272 | the available representations for the response have a character |
---|
2273 | encoding that is listed as acceptable, the origin server MAY either |
---|
2274 | honor the Accept-Charset header field by sending a 406 (Not |
---|
2275 | Acceptable) response or disregard the Accept-Charset header field by |
---|
2276 | treating the response as if it is not subject to content negotiation. |
---|
2277 | |
---|
2278 | 6.3.4. Accept-Encoding |
---|
2279 | |
---|
2280 | The "Accept-Encoding" header field can be used by user agents to |
---|
2281 | indicate what response content-codings (Section 3.1.2.1) are |
---|
2282 | acceptable in the response. An "identity" token is used as a synonym |
---|
2283 | for "no encoding" in order to communicate when no encoding is |
---|
2284 | preferred. |
---|
2285 | |
---|
2286 | Accept-Encoding = #( codings [ weight ] ) |
---|
2287 | codings = content-coding / "identity" / "*" |
---|
2288 | |
---|
2289 | Each codings value MAY be given an associated quality value which |
---|
2290 | represents the preference for that encoding, as defined in |
---|
2291 | Section 6.3.1. |
---|
2292 | |
---|
2293 | |
---|
2294 | |
---|
2295 | Fielding & Reschke Expires April 7, 2013 [Page 41] |
---|
2296 | |
---|
2297 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
2298 | |
---|
2299 | |
---|
2300 | For example, |
---|
2301 | |
---|
2302 | Accept-Encoding: compress, gzip |
---|
2303 | Accept-Encoding: |
---|
2304 | Accept-Encoding: * |
---|
2305 | Accept-Encoding: compress;q=0.5, gzip;q=1.0 |
---|
2306 | Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0 |
---|
2307 | |
---|
2308 | A server tests whether a content-coding for a given representation is |
---|
2309 | acceptable, according to an Accept-Encoding field, using these rules: |
---|
2310 | |
---|
2311 | 1. The special "*" symbol in an Accept-Encoding field matches any |
---|
2312 | available content-coding not explicitly listed in the header |
---|
2313 | field. |
---|
2314 | |
---|
2315 | 2. If the representation has no content-coding, then it is |
---|
2316 | acceptable by default unless specifically excluded by the Accept- |
---|
2317 | Encoding field stating either "identity;q=0" or "*;q=0" without a |
---|
2318 | more specific entry for "identity". |
---|
2319 | |
---|
2320 | 3. If the representation's content-coding is one of the content- |
---|
2321 | codings listed in the Accept-Encoding field, then it is |
---|
2322 | acceptable unless it is accompanied by a qvalue of 0. (As |
---|
2323 | defined in Section 6.3.1, a qvalue of 0 means "not acceptable".) |
---|
2324 | |
---|
2325 | 4. If multiple content-codings are acceptable, then the acceptable |
---|
2326 | content-coding with the highest non-zero qvalue is preferred. |
---|
2327 | |
---|
2328 | An Accept-Encoding header field with a combined field-value that is |
---|
2329 | empty implies that the user agent does not want any content-coding in |
---|
2330 | response. If an Accept-Encoding header field is present in a request |
---|
2331 | and none of the available representations for the response have a |
---|
2332 | content-coding that is listed as acceptable, the origin server SHOULD |
---|
2333 | send a response without any content-coding. |
---|
2334 | |
---|
2335 | A request without an Accept-Encoding header field implies that the |
---|
2336 | user agent will accept any content-coding in response. |
---|
2337 | |
---|
2338 | Note: Most HTTP/1.0 applications do not recognize or obey qvalues |
---|
2339 | associated with content-codings. This means that qvalues will not |
---|
2340 | work and are not permitted with x-gzip or x-compress. |
---|
2341 | |
---|
2342 | 6.3.5. Accept-Language |
---|
2343 | |
---|
2344 | The "Accept-Language" header field can be used by user agents to |
---|
2345 | indicate the set of natural languages that are preferred in the |
---|
2346 | response. Language tags are defined in Section 3.1.3.1. |
---|
2347 | |
---|
2348 | |
---|
2349 | |
---|
2350 | |
---|
2351 | Fielding & Reschke Expires April 7, 2013 [Page 42] |
---|
2352 | |
---|
2353 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
2354 | |
---|
2355 | |
---|
2356 | Accept-Language = 1#( language-range [ weight ] ) |
---|
2357 | language-range = |
---|
2358 | <language-range, defined in [RFC4647], Section 2.1> |
---|
2359 | |
---|
2360 | Each language-range can be given an associated quality value which |
---|
2361 | represents an estimate of the user's preference for the languages |
---|
2362 | specified by that range, as defined in Section 6.3.1. For example, |
---|
2363 | |
---|
2364 | Accept-Language: da, en-gb;q=0.8, en;q=0.7 |
---|
2365 | |
---|
2366 | would mean: "I prefer Danish, but will accept British English and |
---|
2367 | other types of English". (see also Section 2.3 of [RFC4647]) |
---|
2368 | |
---|
2369 | For matching, Section 3 of [RFC4647] defines several matching |
---|
2370 | schemes. Implementations can offer the most appropriate matching |
---|
2371 | scheme for their requirements. |
---|
2372 | |
---|
2373 | Note: The "Basic Filtering" scheme ([RFC4647], Section 3.3.1) is |
---|
2374 | identical to the matching scheme that was previously defined in |
---|
2375 | Section 14.4 of [RFC2616]. |
---|
2376 | |
---|
2377 | It might be contrary to the privacy expectations of the user to send |
---|
2378 | an Accept-Language header field with the complete linguistic |
---|
2379 | preferences of the user in every request. For a discussion of this |
---|
2380 | issue, see Section 10.5. |
---|
2381 | |
---|
2382 | As intelligibility is highly dependent on the individual user, it is |
---|
2383 | recommended that client applications make the choice of linguistic |
---|
2384 | preference available to the user. If the choice is not made |
---|
2385 | available, then the Accept-Language header field MUST NOT be given in |
---|
2386 | the request. |
---|
2387 | |
---|
2388 | Note: When making the choice of linguistic preference available to |
---|
2389 | the user, we remind implementers of the fact that users are not |
---|
2390 | familiar with the details of language matching as described above, |
---|
2391 | and ought to be provided appropriate guidance. As an example, |
---|
2392 | users might assume that on selecting "en-gb", they will be served |
---|
2393 | any kind of English document if British English is not available. |
---|
2394 | A user agent might suggest in such a case to add "en" to get the |
---|
2395 | best matching behavior. |
---|
2396 | |
---|
2397 | |
---|
2398 | |
---|
2399 | |
---|
2400 | |
---|
2401 | |
---|
2402 | |
---|
2403 | |
---|
2404 | |
---|
2405 | |
---|
2406 | |
---|
2407 | Fielding & Reschke Expires April 7, 2013 [Page 43] |
---|
2408 | |
---|
2409 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
2410 | |
---|
2411 | |
---|
2412 | 6.4. Authentication Credentials |
---|
2413 | |
---|
2414 | +---------------------+------------------------+ |
---|
2415 | | Header Field Name | Defined in... | |
---|
2416 | +---------------------+------------------------+ |
---|
2417 | | Authorization | Section 4.1 of [Part7] | |
---|
2418 | | Proxy-Authorization | Section 4.3 of [Part7] | |
---|
2419 | +---------------------+------------------------+ |
---|
2420 | |
---|
2421 | 6.5. Context |
---|
2422 | |
---|
2423 | +-------------------+------------------------+ |
---|
2424 | | Header Field Name | Defined in... | |
---|
2425 | +-------------------+------------------------+ |
---|
2426 | | From | Section 6.5.1 | |
---|
2427 | | Referer | Section 6.5.2 | |
---|
2428 | | TE | Section 4.3 of [Part1] | |
---|
2429 | | User-Agent | Section 6.5.3 | |
---|
2430 | +-------------------+------------------------+ |
---|
2431 | |
---|
2432 | 6.5.1. From |
---|
2433 | |
---|
2434 | The "From" header field, if given, SHOULD contain an Internet e-mail |
---|
2435 | address for the human user who controls the requesting user agent. |
---|
2436 | The address SHOULD be machine-usable, as defined by "mailbox" in |
---|
2437 | Section 3.4 of [RFC5322]: |
---|
2438 | |
---|
2439 | From = mailbox |
---|
2440 | |
---|
2441 | mailbox = <mailbox, defined in [RFC5322], Section 3.4> |
---|
2442 | |
---|
2443 | An example is: |
---|
2444 | |
---|
2445 | From: webmaster@example.org |
---|
2446 | |
---|
2447 | This header field MAY be used for logging purposes and as a means for |
---|
2448 | identifying the source of invalid or unwanted requests. It SHOULD |
---|
2449 | NOT be used as an insecure form of access protection. The |
---|
2450 | interpretation of this field is that the request is being performed |
---|
2451 | on behalf of the person given, who accepts responsibility for the |
---|
2452 | method performed. In particular, robot agents SHOULD include this |
---|
2453 | header field so that the person responsible for running the robot can |
---|
2454 | be contacted if problems occur on the receiving end. |
---|
2455 | |
---|
2456 | The Internet e-mail address in this field MAY be separate from the |
---|
2457 | Internet host which issued the request. For example, when a request |
---|
2458 | is passed through a proxy the original issuer's address SHOULD be |
---|
2459 | used. |
---|
2460 | |
---|
2461 | |
---|
2462 | |
---|
2463 | Fielding & Reschke Expires April 7, 2013 [Page 44] |
---|
2464 | |
---|
2465 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
2466 | |
---|
2467 | |
---|
2468 | The client SHOULD NOT send the From header field without the user's |
---|
2469 | approval, as it might conflict with the user's privacy interests or |
---|
2470 | their site's security policy. It is strongly recommended that the |
---|
2471 | user be able to disable, enable, and modify the value of this field |
---|
2472 | at any time prior to a request. |
---|
2473 | |
---|
2474 | 6.5.2. Referer |
---|
2475 | |
---|
2476 | The "Referer" [sic] header field allows the client to specify the URI |
---|
2477 | of the resource from which the target URI was obtained (the |
---|
2478 | "referrer", although the header field is misspelled.). |
---|
2479 | |
---|
2480 | The Referer header field allows servers to generate lists of back- |
---|
2481 | links to resources for interest, logging, optimized caching, etc. It |
---|
2482 | also allows obsolete or mistyped links to be traced for maintenance. |
---|
2483 | Some servers use Referer as a means of controlling where they allow |
---|
2484 | links from (so-called "deep linking"), but legitimate requests do not |
---|
2485 | always contain a Referer header field. |
---|
2486 | |
---|
2487 | If the target URI was obtained from a source that does not have its |
---|
2488 | own URI (e.g., input from the user keyboard), the Referer field MUST |
---|
2489 | either be sent with the value "about:blank", or not be sent at all. |
---|
2490 | Note that this requirement does not apply to sources with non-HTTP |
---|
2491 | URIs (e.g., FTP). |
---|
2492 | |
---|
2493 | Referer = absolute-URI / partial-URI |
---|
2494 | |
---|
2495 | Example: |
---|
2496 | |
---|
2497 | Referer: http://www.example.org/hypertext/Overview.html |
---|
2498 | |
---|
2499 | If the field value is a relative URI, it SHOULD be interpreted |
---|
2500 | relative to the effective request URI. The URI MUST NOT include a |
---|
2501 | fragment. See Section 10.2 for security considerations. |
---|
2502 | |
---|
2503 | 6.5.3. User-Agent |
---|
2504 | |
---|
2505 | The "User-Agent" header field contains information about the user |
---|
2506 | agent originating the request. User agents SHOULD include this field |
---|
2507 | with requests. |
---|
2508 | |
---|
2509 | Typically, it is used for statistical purposes, the tracing of |
---|
2510 | protocol violations, and tailoring responses to avoid particular user |
---|
2511 | agent limitations. |
---|
2512 | |
---|
2513 | The field can contain multiple product tokens (Section 4) and |
---|
2514 | comments (Section 3.2 of [Part1]) identifying the agent and its |
---|
2515 | significant subproducts. By convention, the product tokens are |
---|
2516 | |
---|
2517 | |
---|
2518 | |
---|
2519 | Fielding & Reschke Expires April 7, 2013 [Page 45] |
---|
2520 | |
---|
2521 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
2522 | |
---|
2523 | |
---|
2524 | listed in order of their significance for identifying the |
---|
2525 | application. |
---|
2526 | |
---|
2527 | Because this field is usually sent on every request a user agent |
---|
2528 | makes, implementations are encouraged not to include needlessly fine- |
---|
2529 | grained detail, and to limit (or even prohibit) the addition of |
---|
2530 | subproducts by third parties. Overly long and detailed User-Agent |
---|
2531 | field values make requests larger and can also be used to identify |
---|
2532 | ("fingerprint") the user against their wishes. |
---|
2533 | |
---|
2534 | Likewise, implementations are encouraged not to use the product |
---|
2535 | tokens of other implementations in order to declare compatibility |
---|
2536 | with them, as this circumvents the purpose of the field. Finally, |
---|
2537 | they are encouraged not to use comments to identify products; doing |
---|
2538 | so makes the field value more difficult to parse. |
---|
2539 | |
---|
2540 | User-Agent = product *( RWS ( product / comment ) ) |
---|
2541 | |
---|
2542 | Example: |
---|
2543 | |
---|
2544 | User-Agent: CERN-LineMode/2.15 libwww/2.17b3 |
---|
2545 | |
---|
2546 | 7. Response Status Codes |
---|
2547 | |
---|
2548 | The status-code element is a 3-digit integer result code of the |
---|
2549 | attempt to understand and satisfy the request. |
---|
2550 | |
---|
2551 | HTTP status codes are extensible. HTTP applications are not required |
---|
2552 | to understand the meaning of all registered status codes, though such |
---|
2553 | understanding is obviously desirable. However, applications MUST |
---|
2554 | understand the class of any status code, as indicated by the first |
---|
2555 | digit, and treat any unrecognized response as being equivalent to the |
---|
2556 | x00 status code of that class, with the exception that an |
---|
2557 | unrecognized response MUST NOT be cached. For example, if an |
---|
2558 | unrecognized status code of 431 is received by the client, it can |
---|
2559 | safely assume that there was something wrong with its request and |
---|
2560 | treat the response as if it had received a 400 status code. In such |
---|
2561 | cases, user agents SHOULD present to the user the representation |
---|
2562 | enclosed with the response, since that representation is likely to |
---|
2563 | include human-readable information which will explain the unusual |
---|
2564 | status. |
---|
2565 | |
---|
2566 | The first digit of the status-code defines the class of response. |
---|
2567 | The last two digits do not have any categorization role. There are 5 |
---|
2568 | values for the first digit: |
---|
2569 | |
---|
2570 | o 1xx (Informational): Request received, continuing process |
---|
2571 | |
---|
2572 | |
---|
2573 | |
---|
2574 | |
---|
2575 | Fielding & Reschke Expires April 7, 2013 [Page 46] |
---|
2576 | |
---|
2577 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
2578 | |
---|
2579 | |
---|
2580 | o 2xx (Successful): The action was successfully received, |
---|
2581 | understood, and accepted |
---|
2582 | |
---|
2583 | o 3xx (Redirection): Further action needs to be taken in order to |
---|
2584 | complete the request |
---|
2585 | |
---|
2586 | o 4xx (Client Error): The request contains bad syntax or cannot be |
---|
2587 | fulfilled |
---|
2588 | |
---|
2589 | o 5xx (Server Error): The server failed to fulfill an apparently |
---|
2590 | valid request |
---|
2591 | |
---|
2592 | For most status codes the response can carry a payload, in which case |
---|
2593 | a Content-Type header field indicates the payload's media type |
---|
2594 | (Section 3.1.1.5). |
---|
2595 | |
---|
2596 | 7.1. Overview of Status Codes |
---|
2597 | |
---|
2598 | The status codes listed below are defined in this specification, |
---|
2599 | Section 4 of [Part4], Section 3 of [Part5], and Section 3 of [Part7]. |
---|
2600 | The reason phrases listed here are only recommendations -- they can |
---|
2601 | be replaced by local equivalents without affecting the protocol. |
---|
2602 | |
---|
2603 | |
---|
2604 | |
---|
2605 | |
---|
2606 | |
---|
2607 | |
---|
2608 | |
---|
2609 | |
---|
2610 | |
---|
2611 | |
---|
2612 | |
---|
2613 | |
---|
2614 | |
---|
2615 | |
---|
2616 | |
---|
2617 | |
---|
2618 | |
---|
2619 | |
---|
2620 | |
---|
2621 | |
---|
2622 | |
---|
2623 | |
---|
2624 | |
---|
2625 | |
---|
2626 | |
---|
2627 | |
---|
2628 | |
---|
2629 | |
---|
2630 | |
---|
2631 | Fielding & Reschke Expires April 7, 2013 [Page 47] |
---|
2632 | |
---|
2633 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
2634 | |
---|
2635 | |
---|
2636 | +-------------+------------------------------+----------------------+ |
---|
2637 | | status-code | reason-phrase | Defined in... | |
---|
2638 | +-------------+------------------------------+----------------------+ |
---|
2639 | | 100 | Continue | Section 7.2.1 | |
---|
2640 | | 101 | Switching Protocols | Section 7.2.2 | |
---|
2641 | | 200 | OK | Section 7.3.1 | |
---|
2642 | | 201 | Created | Section 7.3.2 | |
---|
2643 | | 202 | Accepted | Section 7.3.3 | |
---|
2644 | | 203 | Non-Authoritative | Section 7.3.4 | |
---|
2645 | | | Information | | |
---|
2646 | | 204 | No Content | Section 7.3.5 | |
---|
2647 | | 205 | Reset Content | Section 7.3.6 | |
---|
2648 | | 206 | Partial Content | Section 3.1 of | |
---|
2649 | | | | [Part5] | |
---|
2650 | | 300 | Multiple Choices | Section 7.4.1 | |
---|
2651 | | 301 | Moved Permanently | Section 7.4.2 | |
---|
2652 | | 302 | Found | Section 7.4.3 | |
---|
2653 | | 303 | See Other | Section 7.4.4 | |
---|
2654 | | 304 | Not Modified | Section 4.1 of | |
---|
2655 | | | | [Part4] | |
---|
2656 | | 305 | Use Proxy | Section 7.4.5 | |
---|
2657 | | 307 | Temporary Redirect | Section 7.4.7 | |
---|
2658 | | 400 | Bad Request | Section 7.5.1 | |
---|
2659 | | 401 | Unauthorized | Section 3.1 of | |
---|
2660 | | | | [Part7] | |
---|
2661 | | 402 | Payment Required | Section 7.5.2 | |
---|
2662 | | 403 | Forbidden | Section 7.5.3 | |
---|
2663 | | 404 | Not Found | Section 7.5.4 | |
---|
2664 | | 405 | Method Not Allowed | Section 7.5.5 | |
---|
2665 | | 406 | Not Acceptable | Section 7.5.6 | |
---|
2666 | | 407 | Proxy Authentication | Section 3.2 of | |
---|
2667 | | | Required | [Part7] | |
---|
2668 | | 408 | Request Time-out | Section 7.5.7 | |
---|
2669 | | 409 | Conflict | Section 7.5.8 | |
---|
2670 | | 410 | Gone | Section 7.5.9 | |
---|
2671 | | 411 | Length Required | Section 7.5.10 | |
---|
2672 | | 412 | Precondition Failed | Section 4.2 of | |
---|
2673 | | | | [Part4] | |
---|
2674 | | 413 | Request Representation Too | Section 7.5.11 | |
---|
2675 | | | Large | | |
---|
2676 | | 414 | URI Too Long | Section 7.5.12 | |
---|
2677 | | 415 | Unsupported Media Type | Section 7.5.13 | |
---|
2678 | | 416 | Requested range not | Section 3.2 of | |
---|
2679 | | | satisfiable | [Part5] | |
---|
2680 | | 417 | Expectation Failed | Section 7.5.14 | |
---|
2681 | | 426 | Upgrade Required | Section 7.5.15 | |
---|
2682 | | 500 | Internal Server Error | Section 7.6.1 | |
---|
2683 | | 501 | Not Implemented | Section 7.6.2 | |
---|
2684 | |
---|
2685 | |
---|
2686 | |
---|
2687 | Fielding & Reschke Expires April 7, 2013 [Page 48] |
---|
2688 | |
---|
2689 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
2690 | |
---|
2691 | |
---|
2692 | | 502 | Bad Gateway | Section 7.6.3 | |
---|
2693 | | 503 | Service Unavailable | Section 7.6.4 | |
---|
2694 | | 504 | Gateway Time-out | Section 7.6.5 | |
---|
2695 | | 505 | HTTP Version not supported | Section 7.6.6 | |
---|
2696 | +-------------+------------------------------+----------------------+ |
---|
2697 | |
---|
2698 | Note that this list is not exhaustive -- it does not include |
---|
2699 | extension status codes defined in other specifications. |
---|
2700 | |
---|
2701 | 7.2. Informational 1xx |
---|
2702 | |
---|
2703 | This class of status code indicates a provisional response, |
---|
2704 | consisting only of the status-line and optional header fields, and is |
---|
2705 | terminated by an empty line. There are no required header fields for |
---|
2706 | this class of status code. Since HTTP/1.0 did not define any 1xx |
---|
2707 | status codes, servers MUST NOT send a 1xx response to an HTTP/1.0 |
---|
2708 | client except under experimental conditions. |
---|
2709 | |
---|
2710 | A client MUST be prepared to accept one or more 1xx status responses |
---|
2711 | prior to a regular response, even if the client does not expect a 100 |
---|
2712 | (Continue) status message. Unexpected 1xx status responses MAY be |
---|
2713 | ignored by a user agent. |
---|
2714 | |
---|
2715 | Proxies MUST forward 1xx responses, unless the connection between the |
---|
2716 | proxy and its client has been closed, or unless the proxy itself |
---|
2717 | requested the generation of the 1xx response. (For example, if a |
---|
2718 | proxy adds an "Expect: 100-continue" field when it forwards a |
---|
2719 | request, then it need not forward the corresponding 100 (Continue) |
---|
2720 | response(s).) |
---|
2721 | |
---|
2722 | 7.2.1. 100 Continue |
---|
2723 | |
---|
2724 | The client SHOULD continue with its request. This interim response |
---|
2725 | is used to inform the client that the initial part of the request has |
---|
2726 | been received and has not yet been rejected by the server. The |
---|
2727 | client SHOULD continue by sending the remainder of the request or, if |
---|
2728 | the request has already been completed, ignore this response. The |
---|
2729 | server MUST send a final response after the request has been |
---|
2730 | completed. See Section 6.1.2.1 for detailed discussion of the use |
---|
2731 | and handling of this status code. |
---|
2732 | |
---|
2733 | 7.2.2. 101 Switching Protocols |
---|
2734 | |
---|
2735 | The server understands and is willing to comply with the client's |
---|
2736 | request, via the Upgrade message header field (Section 6.3 of |
---|
2737 | [Part1]), for a change in the application protocol being used on this |
---|
2738 | connection. The server will switch protocols to those defined by the |
---|
2739 | response's Upgrade header field immediately after the empty line |
---|
2740 | |
---|
2741 | |
---|
2742 | |
---|
2743 | Fielding & Reschke Expires April 7, 2013 [Page 49] |
---|
2744 | |
---|
2745 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
2746 | |
---|
2747 | |
---|
2748 | which terminates the 101 response. |
---|
2749 | |
---|
2750 | The protocol SHOULD be switched only when it is advantageous to do |
---|
2751 | so. For example, switching to a newer version of HTTP is |
---|
2752 | advantageous over older versions, and switching to a real-time, |
---|
2753 | synchronous protocol might be advantageous when delivering resources |
---|
2754 | that use such features. |
---|
2755 | |
---|
2756 | 7.3. Successful 2xx |
---|
2757 | |
---|
2758 | This class of status code indicates that the client's request was |
---|
2759 | successfully received, understood, and accepted. |
---|
2760 | |
---|
2761 | 7.3.1. 200 OK |
---|
2762 | |
---|
2763 | The request has succeeded. The payload returned with the response is |
---|
2764 | dependent on the method used in the request, for example: |
---|
2765 | |
---|
2766 | GET a representation of the target resource is sent in the response; |
---|
2767 | |
---|
2768 | HEAD the same representation as GET, except without the message |
---|
2769 | body; |
---|
2770 | |
---|
2771 | POST a representation describing or containing the result of the |
---|
2772 | action; |
---|
2773 | |
---|
2774 | TRACE a representation containing the request message as received by |
---|
2775 | the end server. |
---|
2776 | |
---|
2777 | Caches MAY use a heuristic (see Section 4.1.2 of [Part6]) to |
---|
2778 | determine freshness for 200 responses. |
---|
2779 | |
---|
2780 | 7.3.2. 201 Created |
---|
2781 | |
---|
2782 | The request has been fulfilled and has resulted in one or more new |
---|
2783 | resources being created. |
---|
2784 | |
---|
2785 | Newly created resources are typically linked to from the response |
---|
2786 | payload, with the most relevant URI also being carried in the |
---|
2787 | Location header field. If the newly created resource's URI is the |
---|
2788 | same as the Effective Request URI, this information can be omitted |
---|
2789 | (e.g., in the case of a response to a PUT request). |
---|
2790 | |
---|
2791 | The origin server MUST create the resource(s) before returning the |
---|
2792 | 201 status code. If the action cannot be carried out immediately, |
---|
2793 | the server SHOULD respond with 202 (Accepted) response instead. |
---|
2794 | |
---|
2795 | A 201 response MAY contain an ETag response header field indicating |
---|
2796 | |
---|
2797 | |
---|
2798 | |
---|
2799 | Fielding & Reschke Expires April 7, 2013 [Page 50] |
---|
2800 | |
---|
2801 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
2802 | |
---|
2803 | |
---|
2804 | the current value of the entity-tag for the representation of the |
---|
2805 | resource identified by the Location header field or, in case the |
---|
2806 | Location header field was omitted, by the Effective Request URI (see |
---|
2807 | Section 2.3 of [Part4]). |
---|
2808 | |
---|
2809 | 7.3.3. 202 Accepted |
---|
2810 | |
---|
2811 | The request has been accepted for processing, but the processing has |
---|
2812 | not been completed. The request might or might not eventually be |
---|
2813 | acted upon, as it might be disallowed when processing actually takes |
---|
2814 | place. There is no facility for re-sending a status code from an |
---|
2815 | asynchronous operation such as this. |
---|
2816 | |
---|
2817 | The 202 response is intentionally non-committal. Its purpose is to |
---|
2818 | allow a server to accept a request for some other process (perhaps a |
---|
2819 | batch-oriented process that is only run once per day) without |
---|
2820 | requiring that the user agent's connection to the server persist |
---|
2821 | until the process is completed. The representation returned with |
---|
2822 | this response SHOULD include an indication of the request's current |
---|
2823 | status and either a pointer to a status monitor or some estimate of |
---|
2824 | when the user can expect the request to be fulfilled. |
---|
2825 | |
---|
2826 | 7.3.4. 203 Non-Authoritative Information |
---|
2827 | |
---|
2828 | The representation in the response has been transformed or otherwise |
---|
2829 | modified by a transforming proxy (Section 2.3 of [Part1]). Note that |
---|
2830 | the behavior of transforming intermediaries is controlled by the no- |
---|
2831 | transform Cache-Control directive (Section 7.2 of [Part6]). |
---|
2832 | |
---|
2833 | This status code is only appropriate when the response status code |
---|
2834 | would have been 200 (OK) otherwise. When the status code before |
---|
2835 | transformation would have been different, the 214 Transformation |
---|
2836 | Applied warn-code (Section 7.5 of [Part6]) is appropriate. |
---|
2837 | |
---|
2838 | Caches MAY use a heuristic (see Section 4.1.2 of [Part6]) to |
---|
2839 | determine freshness for 203 responses. |
---|
2840 | |
---|
2841 | 7.3.5. 204 No Content |
---|
2842 | |
---|
2843 | The 204 (No Content) status code indicates that the server has |
---|
2844 | successfully fulfilled the request and that there is no additional |
---|
2845 | content to return in the response payload body. Metadata in the |
---|
2846 | response header fields refer to the target resource and its current |
---|
2847 | representation after the requested action. |
---|
2848 | |
---|
2849 | For example, if a 204 status code is received in response to a PUT |
---|
2850 | request and the response contains an ETag header field, then the PUT |
---|
2851 | was successful and the ETag field-value contains the entity-tag for |
---|
2852 | |
---|
2853 | |
---|
2854 | |
---|
2855 | Fielding & Reschke Expires April 7, 2013 [Page 51] |
---|
2856 | |
---|
2857 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
2858 | |
---|
2859 | |
---|
2860 | the new representation of that target resource. |
---|
2861 | |
---|
2862 | The 204 response allows a server to indicate that the action has been |
---|
2863 | successfully applied to the target resource while implying that the |
---|
2864 | user agent SHOULD NOT traverse away from its current "document view" |
---|
2865 | (if any). The server assumes that the user agent will provide some |
---|
2866 | indication of the success to its user, in accord with its own |
---|
2867 | interface, and apply any new or updated metadata in the response to |
---|
2868 | the active representation. |
---|
2869 | |
---|
2870 | For example, a 204 status code is commonly used with document editing |
---|
2871 | interfaces corresponding to a "save" action, such that the document |
---|
2872 | being saved remains available to the user for editing. It is also |
---|
2873 | frequently used with interfaces that expect automated data transfers |
---|
2874 | to be prevalent, such as within distributed version control systems. |
---|
2875 | |
---|
2876 | The 204 response MUST NOT include a message body, and thus is always |
---|
2877 | terminated by the first empty line after the header fields. |
---|
2878 | |
---|
2879 | 7.3.6. 205 Reset Content |
---|
2880 | |
---|
2881 | The server has fulfilled the request and the user agent SHOULD reset |
---|
2882 | the document view which caused the request to be sent. This response |
---|
2883 | is primarily intended to allow input for actions to take place via |
---|
2884 | user input, followed by a clearing of the form in which the input is |
---|
2885 | given so that the user can easily initiate another input action. |
---|
2886 | |
---|
2887 | The message body included with the response MUST be empty. Note that |
---|
2888 | receivers still need to parse the response according to the algorithm |
---|
2889 | defined in Section 3.3 of [Part1]. |
---|
2890 | |
---|
2891 | 7.4. Redirection 3xx |
---|
2892 | |
---|
2893 | This class of status code indicates that further action needs to be |
---|
2894 | taken by the user agent in order to fulfill the request. If the |
---|
2895 | required action involves a subsequent HTTP request, it MAY be carried |
---|
2896 | out by the user agent without interaction with the user if and only |
---|
2897 | if the method used in the second request is known to be "safe", as |
---|
2898 | defined in Section 5.2.1. |
---|
2899 | |
---|
2900 | There are several types of redirects: |
---|
2901 | |
---|
2902 | 1. Redirects of the request to another URI, either temporarily or |
---|
2903 | permanently. The new URI is specified in the Location header |
---|
2904 | field. In this specification, the status codes 301 (Moved |
---|
2905 | Permanently), 302 (Found), and 307 (Temporary Redirect) fall |
---|
2906 | under this category. |
---|
2907 | |
---|
2908 | |
---|
2909 | |
---|
2910 | |
---|
2911 | Fielding & Reschke Expires April 7, 2013 [Page 52] |
---|
2912 | |
---|
2913 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
2914 | |
---|
2915 | |
---|
2916 | 2. Redirection to a new location that represents an indirect |
---|
2917 | response to the request, such as the result of a POST operation |
---|
2918 | to be retrieved with a subsequent GET request. This is status |
---|
2919 | code 303 (See Other). |
---|
2920 | |
---|
2921 | 3. Redirection offering a choice of matching resources for use by |
---|
2922 | reactive content negotiation (Section 3.4.2). This is status |
---|
2923 | code 300 (Multiple Choices). |
---|
2924 | |
---|
2925 | 4. Other kinds of redirection, such as to a cached result (status |
---|
2926 | code 304 (Not Modified), see Section 4.1 of [Part4]). |
---|
2927 | |
---|
2928 | Note: In HTTP/1.0, only the status codes 301 (Moved Permanently) |
---|
2929 | and 302 (Found) were defined for the first type of redirect, and |
---|
2930 | the second type did not exist at all ([RFC1945], Section 9.3). |
---|
2931 | However it turned out that web forms using POST expected redirects |
---|
2932 | to change the operation for the subsequent request to retrieval |
---|
2933 | (GET). To address this use case, HTTP/1.1 introduced the second |
---|
2934 | type of redirect with the status code 303 (See Other) ([RFC2068], |
---|
2935 | Section 10.3.4). As user agents did not change their behavior to |
---|
2936 | maintain backwards compatibility, the first revision of HTTP/1.1 |
---|
2937 | added yet another status code, 307 (Temporary Redirect), for which |
---|
2938 | the backwards compatibility problems did not apply ([RFC2616], |
---|
2939 | Section 10.3.8). Over 10 years later, most user agents still do |
---|
2940 | method rewriting for status codes 301 and 302, therefore this |
---|
2941 | specification makes that behavior conformant in case the original |
---|
2942 | request was POST. |
---|
2943 | |
---|
2944 | A Location header field on a 3xx response indicates that a client MAY |
---|
2945 | automatically redirect to the URI provided; see Section 8.1.2. |
---|
2946 | |
---|
2947 | Note that for methods not known to be "safe", as defined in |
---|
2948 | Section 5.2.1, automatic redirection needs to done with care, since |
---|
2949 | the redirect might change the conditions under which the request was |
---|
2950 | issued. |
---|
2951 | |
---|
2952 | Clients SHOULD detect and intervene in cyclical redirections (i.e., |
---|
2953 | "infinite" redirection loops). |
---|
2954 | |
---|
2955 | Note: An earlier version of this specification recommended a |
---|
2956 | maximum of five redirections ([RFC2068], Section 10.3). Content |
---|
2957 | developers need to be aware that some clients might implement such |
---|
2958 | a fixed limitation. |
---|
2959 | |
---|
2960 | |
---|
2961 | |
---|
2962 | |
---|
2963 | |
---|
2964 | |
---|
2965 | |
---|
2966 | |
---|
2967 | Fielding & Reschke Expires April 7, 2013 [Page 53] |
---|
2968 | |
---|
2969 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
2970 | |
---|
2971 | |
---|
2972 | 7.4.1. 300 Multiple Choices |
---|
2973 | |
---|
2974 | The target resource has more than one representation, each with its |
---|
2975 | own specific location, and reactive negotiation information |
---|
2976 | (Section 3.4) is being provided so that the user (or user agent) can |
---|
2977 | select a preferred representation by redirecting its request to that |
---|
2978 | location. |
---|
2979 | |
---|
2980 | Unless it was a HEAD request, the response SHOULD include a |
---|
2981 | representation containing a list of representation metadata and |
---|
2982 | location(s) from which the user or user agent can choose the one most |
---|
2983 | appropriate. Depending upon the format and the capabilities of the |
---|
2984 | user agent, selection of the most appropriate choice MAY be performed |
---|
2985 | automatically. However, this specification does not define any |
---|
2986 | standard for such automatic selection. |
---|
2987 | |
---|
2988 | If the server has a preferred choice of representation, it SHOULD |
---|
2989 | include the specific URI for that representation in the Location |
---|
2990 | field; user agents MAY use the Location field value for automatic |
---|
2991 | redirection. |
---|
2992 | |
---|
2993 | Caches MAY use a heuristic (see Section 4.1.2 of [Part6]) to |
---|
2994 | determine freshness for 300 responses. |
---|
2995 | |
---|
2996 | 7.4.2. 301 Moved Permanently |
---|
2997 | |
---|
2998 | The target resource has been assigned a new permanent URI and any |
---|
2999 | future references to this resource SHOULD use one of the returned |
---|
3000 | URIs. Clients with link editing capabilities ought to automatically |
---|
3001 | re-link references to the effective request URI to one or more of the |
---|
3002 | new references returned by the server, where possible. |
---|
3003 | |
---|
3004 | Caches MAY use a heuristic (see Section 4.1.2 of [Part6]) to |
---|
3005 | determine freshness for 301 responses. |
---|
3006 | |
---|
3007 | The new permanent URI SHOULD be given by the Location field in the |
---|
3008 | response. A response payload can contain a short hypertext note with |
---|
3009 | a hyperlink to the new URI(s). |
---|
3010 | |
---|
3011 | Note: For historic reasons, user agents MAY change the request |
---|
3012 | method from POST to GET for the subsequent request. If this |
---|
3013 | behavior is undesired, status code 307 (Temporary Redirect) can be |
---|
3014 | used instead. |
---|
3015 | |
---|
3016 | |
---|
3017 | |
---|
3018 | |
---|
3019 | |
---|
3020 | |
---|
3021 | |
---|
3022 | |
---|
3023 | Fielding & Reschke Expires April 7, 2013 [Page 54] |
---|
3024 | |
---|
3025 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
3026 | |
---|
3027 | |
---|
3028 | 7.4.3. 302 Found |
---|
3029 | |
---|
3030 | The target resource resides temporarily under a different URI. Since |
---|
3031 | the redirection might be altered on occasion, the client SHOULD |
---|
3032 | continue to use the effective request URI for future requests. |
---|
3033 | |
---|
3034 | The temporary URI SHOULD be given by the Location field in the |
---|
3035 | response. A response payload can contain a short hypertext note with |
---|
3036 | a hyperlink to the new URI(s). |
---|
3037 | |
---|
3038 | Note: For historic reasons, user agents MAY change the request |
---|
3039 | method from POST to GET for the subsequent request. If this |
---|
3040 | behavior is undesired, status code 307 (Temporary Redirect) can be |
---|
3041 | used instead. |
---|
3042 | |
---|
3043 | 7.4.4. 303 See Other |
---|
3044 | |
---|
3045 | The 303 status code indicates that the server is redirecting the user |
---|
3046 | agent to a different resource, as indicated by a URI in the Location |
---|
3047 | header field, that is intended to provide an indirect response to the |
---|
3048 | original request. In order to satisfy the original request, a user |
---|
3049 | agent SHOULD perform a retrieval request using the Location URI (a |
---|
3050 | GET or HEAD request if using HTTP), which can itself be redirected |
---|
3051 | further, and present the eventual result as an answer to the original |
---|
3052 | request. Note that the new URI in the Location header field is not |
---|
3053 | considered equivalent to the effective request URI. |
---|
3054 | |
---|
3055 | This status code is generally applicable to any HTTP method. It is |
---|
3056 | primarily used to allow the output of a POST action to redirect the |
---|
3057 | user agent to a selected resource, since doing so provides the |
---|
3058 | information corresponding to the POST response in a form that can be |
---|
3059 | separately identified, bookmarked, and cached independent of the |
---|
3060 | original request. |
---|
3061 | |
---|
3062 | A 303 response to a GET request indicates that the requested resource |
---|
3063 | does not have a representation of its own that can be transferred by |
---|
3064 | the server over HTTP. The Location URI indicates a resource that is |
---|
3065 | descriptive of the target resource, such that the follow-on |
---|
3066 | representation might be useful to recipients without implying that it |
---|
3067 | adequately represents the target resource. Note that answers to the |
---|
3068 | questions of what can be represented, what representations are |
---|
3069 | adequate, and what might be a useful description are outside the |
---|
3070 | scope of HTTP and thus entirely determined by the URI owner(s). |
---|
3071 | |
---|
3072 | Except for responses to a HEAD request, the representation of a 303 |
---|
3073 | response SHOULD contain a short hypertext note with a hyperlink to |
---|
3074 | the Location URI. |
---|
3075 | |
---|
3076 | |
---|
3077 | |
---|
3078 | |
---|
3079 | Fielding & Reschke Expires April 7, 2013 [Page 55] |
---|
3080 | |
---|
3081 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
3082 | |
---|
3083 | |
---|
3084 | 7.4.5. 305 Use Proxy |
---|
3085 | |
---|
3086 | The 305 status code was defined in a previous version of this |
---|
3087 | specification (see Appendix C), and is now deprecated. |
---|
3088 | |
---|
3089 | 7.4.6. 306 (Unused) |
---|
3090 | |
---|
3091 | The 306 status code was used in a previous version of the |
---|
3092 | specification, is no longer used, and the code is reserved. |
---|
3093 | |
---|
3094 | 7.4.7. 307 Temporary Redirect |
---|
3095 | |
---|
3096 | The target resource resides temporarily under a different URI. Since |
---|
3097 | the redirection can change over time, the client SHOULD continue to |
---|
3098 | use the effective request URI for future requests. |
---|
3099 | |
---|
3100 | The temporary URI SHOULD be given by the Location field in the |
---|
3101 | response. A response payload can contain a short hypertext note with |
---|
3102 | a hyperlink to the new URI(s). |
---|
3103 | |
---|
3104 | Note: This status code is similar to 302 (Found), except that it |
---|
3105 | does not allow rewriting the request method from POST to GET. |
---|
3106 | This specification defines no equivalent counterpart for 301 |
---|
3107 | (Moved Permanently) ([status-308], however, defines the status |
---|
3108 | code 308 (Permanent Redirect) for this purpose). |
---|
3109 | |
---|
3110 | 7.5. Client Error 4xx |
---|
3111 | |
---|
3112 | The 4xx class of status code is intended for cases in which the |
---|
3113 | client seems to have erred. Except when responding to a HEAD |
---|
3114 | request, the server SHOULD include a representation containing an |
---|
3115 | explanation of the error situation, and whether it is a temporary or |
---|
3116 | permanent condition. These status codes are applicable to any |
---|
3117 | request method. User agents SHOULD display any included |
---|
3118 | representation to the user. |
---|
3119 | |
---|
3120 | 7.5.1. 400 Bad Request |
---|
3121 | |
---|
3122 | The server cannot or will not process the request, due to a client |
---|
3123 | error (e.g., malformed syntax). |
---|
3124 | |
---|
3125 | 7.5.2. 402 Payment Required |
---|
3126 | |
---|
3127 | This code is reserved for future use. |
---|
3128 | |
---|
3129 | |
---|
3130 | |
---|
3131 | |
---|
3132 | |
---|
3133 | |
---|
3134 | |
---|
3135 | Fielding & Reschke Expires April 7, 2013 [Page 56] |
---|
3136 | |
---|
3137 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
3138 | |
---|
3139 | |
---|
3140 | 7.5.3. 403 Forbidden |
---|
3141 | |
---|
3142 | The server understood the request, but refuses to authorize it. |
---|
3143 | Providing different user authentication credentials might be |
---|
3144 | successful, but any credentials that were provided in the request are |
---|
3145 | insufficient. The request SHOULD NOT be repeated with the same |
---|
3146 | credentials. |
---|
3147 | |
---|
3148 | If the request method was not HEAD and the server wishes to make |
---|
3149 | public why the request has not been fulfilled, it SHOULD describe the |
---|
3150 | reason for the refusal in the representation. If the server does not |
---|
3151 | wish to make this information available to the client, the status |
---|
3152 | code 404 (Not Found) MAY be used instead. |
---|
3153 | |
---|
3154 | 7.5.4. 404 Not Found |
---|
3155 | |
---|
3156 | The server has not found anything matching the effective request URI. |
---|
3157 | No indication is given of whether the condition is temporary or |
---|
3158 | permanent. The 410 (Gone) status code SHOULD be used if the server |
---|
3159 | knows, through some internally configurable mechanism, that an old |
---|
3160 | resource is permanently unavailable and has no forwarding address. |
---|
3161 | This status code is commonly used when the server does not wish to |
---|
3162 | reveal exactly why the request has been refused, or when no other |
---|
3163 | response is applicable. |
---|
3164 | |
---|
3165 | 7.5.5. 405 Method Not Allowed |
---|
3166 | |
---|
3167 | The method specified in the request-line is not allowed for the |
---|
3168 | target resource. The response MUST include an Allow header field |
---|
3169 | containing a list of valid methods for the requested resource. |
---|
3170 | |
---|
3171 | 7.5.6. 406 Not Acceptable |
---|
3172 | |
---|
3173 | The resource identified by the request is only capable of generating |
---|
3174 | response representations which have content characteristics not |
---|
3175 | acceptable according to the Accept and Accept-* header fields sent in |
---|
3176 | the request. |
---|
3177 | |
---|
3178 | Unless it was a HEAD request, the response SHOULD include a |
---|
3179 | representation containing a list of available representation |
---|
3180 | characteristics and location(s) from which the user or user agent can |
---|
3181 | choose the one most appropriate. Depending upon the format and the |
---|
3182 | capabilities of the user agent, selection of the most appropriate |
---|
3183 | choice MAY be performed automatically. However, this specification |
---|
3184 | does not define any standard for such automatic selection. |
---|
3185 | |
---|
3186 | |
---|
3187 | |
---|
3188 | |
---|
3189 | |
---|
3190 | |
---|
3191 | Fielding & Reschke Expires April 7, 2013 [Page 57] |
---|
3192 | |
---|
3193 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
3194 | |
---|
3195 | |
---|
3196 | Note: HTTP/1.1 servers are allowed to return responses which are |
---|
3197 | not acceptable according to the accept header fields sent in the |
---|
3198 | request. In some cases, this might even be preferable to sending |
---|
3199 | a 406 response. User agents are encouraged to inspect the header |
---|
3200 | fields of an incoming response to determine if it is acceptable. |
---|
3201 | |
---|
3202 | If the response could be unacceptable, a user agent SHOULD |
---|
3203 | temporarily stop receipt of more data and query the user for a |
---|
3204 | decision on further actions. |
---|
3205 | |
---|
3206 | 7.5.7. 408 Request Timeout |
---|
3207 | |
---|
3208 | The client did not produce a request within the time that the server |
---|
3209 | was prepared to wait. The client MAY repeat the request without |
---|
3210 | modifications at any later time. |
---|
3211 | |
---|
3212 | 7.5.8. 409 Conflict |
---|
3213 | |
---|
3214 | The request could not be completed due to a conflict with the current |
---|
3215 | state of the resource. This code is only allowed in situations where |
---|
3216 | it is expected that the user might be able to resolve the conflict |
---|
3217 | and resubmit the request. The payload SHOULD include enough |
---|
3218 | information for the user to recognize the source of the conflict. |
---|
3219 | Ideally, the response representation would include enough information |
---|
3220 | for the user or user agent to fix the problem; however, that might |
---|
3221 | not be possible and is not required. |
---|
3222 | |
---|
3223 | Conflicts are most likely to occur in response to a PUT request. For |
---|
3224 | example, if versioning were being used and the representation being |
---|
3225 | PUT included changes to a resource which conflict with those made by |
---|
3226 | an earlier (third-party) request, the server might use the 409 |
---|
3227 | response to indicate that it can't complete the request. In this |
---|
3228 | case, the response representation would likely contain a list of the |
---|
3229 | differences between the two versions. |
---|
3230 | |
---|
3231 | 7.5.9. 410 Gone |
---|
3232 | |
---|
3233 | The target resource is no longer available at the server and no |
---|
3234 | forwarding address is known. This condition is expected to be |
---|
3235 | considered permanent. Clients with link editing capabilities SHOULD |
---|
3236 | delete references to the effective request URI after user approval. |
---|
3237 | If the server does not know, or has no facility to determine, whether |
---|
3238 | or not the condition is permanent, the status code 404 (Not Found) |
---|
3239 | SHOULD be used instead. |
---|
3240 | |
---|
3241 | The 410 response is primarily intended to assist the task of web |
---|
3242 | maintenance by notifying the recipient that the resource is |
---|
3243 | intentionally unavailable and that the server owners desire that |
---|
3244 | |
---|
3245 | |
---|
3246 | |
---|
3247 | Fielding & Reschke Expires April 7, 2013 [Page 58] |
---|
3248 | |
---|
3249 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
3250 | |
---|
3251 | |
---|
3252 | remote links to that resource be removed. Such an event is common |
---|
3253 | for limited-time, promotional services and for resources belonging to |
---|
3254 | individuals no longer working at the server's site. It is not |
---|
3255 | necessary to mark all permanently unavailable resources as "gone" or |
---|
3256 | to keep the mark for any length of time -- that is left to the |
---|
3257 | discretion of the server owner. |
---|
3258 | |
---|
3259 | Caches MAY use a heuristic (see Section 4.1.2 of [Part6]) to |
---|
3260 | determine freshness for 410 responses. |
---|
3261 | |
---|
3262 | 7.5.10. 411 Length Required |
---|
3263 | |
---|
3264 | The server refuses to accept the request without a defined Content- |
---|
3265 | Length. The client MAY repeat the request if it adds a valid |
---|
3266 | Content-Length header field containing the length of the message body |
---|
3267 | in the request message. |
---|
3268 | |
---|
3269 | 7.5.11. 413 Request Representation Too Large |
---|
3270 | |
---|
3271 | The server is refusing to process a request because the request |
---|
3272 | representation is larger than the server is willing or able to |
---|
3273 | process. The server MAY close the connection to prevent the client |
---|
3274 | from continuing the request. |
---|
3275 | |
---|
3276 | If the condition is temporary, the server SHOULD include a Retry- |
---|
3277 | After header field to indicate that it is temporary and after what |
---|
3278 | time the client MAY try again. |
---|
3279 | |
---|
3280 | 7.5.12. 414 URI Too Long |
---|
3281 | |
---|
3282 | The server is refusing to service the request because the effective |
---|
3283 | request URI is longer than the server is willing to interpret. This |
---|
3284 | rare condition is only likely to occur when a client has improperly |
---|
3285 | converted a POST request to a GET request with long query |
---|
3286 | information, when the client has descended into a URI "black hole" of |
---|
3287 | redirection (e.g., a redirected URI prefix that points to a suffix of |
---|
3288 | itself), or when the server is under attack by a client attempting to |
---|
3289 | exploit security holes present in some servers using fixed-length |
---|
3290 | buffers for reading or manipulating the request-target. |
---|
3291 | |
---|
3292 | 7.5.13. 415 Unsupported Media Type |
---|
3293 | |
---|
3294 | The server is refusing to service the request because the request |
---|
3295 | payload is in a format not supported by this request method on the |
---|
3296 | target resource. |
---|
3297 | |
---|
3298 | |
---|
3299 | |
---|
3300 | |
---|
3301 | |
---|
3302 | |
---|
3303 | Fielding & Reschke Expires April 7, 2013 [Page 59] |
---|
3304 | |
---|
3305 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
3306 | |
---|
3307 | |
---|
3308 | 7.5.14. 417 Expectation Failed |
---|
3309 | |
---|
3310 | The expectation given in an Expect header field (see Section 6.1.2) |
---|
3311 | could not be met by this server, or, if the server is a proxy, the |
---|
3312 | server has unambiguous evidence that the request could not be met by |
---|
3313 | the next-hop server. |
---|
3314 | |
---|
3315 | 7.5.15. 426 Upgrade Required |
---|
3316 | |
---|
3317 | The request can not be completed without a prior protocol upgrade. |
---|
3318 | This response MUST include an Upgrade header field (Section 6.3 of |
---|
3319 | [Part1]) specifying the required protocols. |
---|
3320 | |
---|
3321 | Example: |
---|
3322 | |
---|
3323 | HTTP/1.1 426 Upgrade Required |
---|
3324 | Upgrade: HTTP/3.0 |
---|
3325 | Connection: Upgrade |
---|
3326 | Content-Length: 53 |
---|
3327 | Content-Type: text/plain |
---|
3328 | |
---|
3329 | This service requires use of the HTTP/3.0 protocol. |
---|
3330 | |
---|
3331 | The server SHOULD include a message body in the 426 response which |
---|
3332 | indicates in human readable form the reason for the error and |
---|
3333 | describes any alternative courses which might be available to the |
---|
3334 | user. |
---|
3335 | |
---|
3336 | 7.6. Server Error 5xx |
---|
3337 | |
---|
3338 | Response status codes beginning with the digit "5" indicate cases in |
---|
3339 | which the server is aware that it has erred or is incapable of |
---|
3340 | performing the request. Except when responding to a HEAD request, |
---|
3341 | the server SHOULD include a representation containing an explanation |
---|
3342 | of the error situation, and whether it is a temporary or permanent |
---|
3343 | condition. User agents SHOULD display any included representation to |
---|
3344 | the user. These response codes are applicable to any request method. |
---|
3345 | |
---|
3346 | 7.6.1. 500 Internal Server Error |
---|
3347 | |
---|
3348 | The server encountered an unexpected condition which prevented it |
---|
3349 | from fulfilling the request. |
---|
3350 | |
---|
3351 | 7.6.2. 501 Not Implemented |
---|
3352 | |
---|
3353 | The server does not support the functionality required to fulfill the |
---|
3354 | request. This is the appropriate response when the server does not |
---|
3355 | recognize the request method and is not capable of supporting it for |
---|
3356 | |
---|
3357 | |
---|
3358 | |
---|
3359 | Fielding & Reschke Expires April 7, 2013 [Page 60] |
---|
3360 | |
---|
3361 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
3362 | |
---|
3363 | |
---|
3364 | any resource. |
---|
3365 | |
---|
3366 | 7.6.3. 502 Bad Gateway |
---|
3367 | |
---|
3368 | The server, while acting as a gateway or proxy, received an invalid |
---|
3369 | response from the upstream server it accessed in attempting to |
---|
3370 | fulfill the request. |
---|
3371 | |
---|
3372 | 7.6.4. 503 Service Unavailable |
---|
3373 | |
---|
3374 | The server is currently unable to handle the request due to a |
---|
3375 | temporary overloading or maintenance of the server. |
---|
3376 | |
---|
3377 | The implication is that this is a temporary condition which will be |
---|
3378 | alleviated after some delay. If known, the length of the delay MAY |
---|
3379 | be indicated in a Retry-After header field (Section 8.1.3). If no |
---|
3380 | Retry-After is given, the client SHOULD handle the response as it |
---|
3381 | would for a 500 (Internal Server Error) response. |
---|
3382 | |
---|
3383 | Note: The existence of the 503 status code does not imply that a |
---|
3384 | server has to use it when becoming overloaded. Some servers might |
---|
3385 | wish to simply refuse the connection. |
---|
3386 | |
---|
3387 | 7.6.5. 504 Gateway Timeout |
---|
3388 | |
---|
3389 | The server, while acting as a gateway or proxy, did not receive a |
---|
3390 | timely response from the upstream server specified by the URI (e.g., |
---|
3391 | HTTP, FTP, LDAP) or some other auxiliary server (e.g., DNS) it needed |
---|
3392 | to access in attempting to complete the request. |
---|
3393 | |
---|
3394 | Note to implementers: some deployed proxies are known to return |
---|
3395 | 400 (Bad Request) or 500 (Internal Server Error) when DNS lookups |
---|
3396 | time out. |
---|
3397 | |
---|
3398 | 7.6.6. 505 HTTP Version Not Supported |
---|
3399 | |
---|
3400 | The server does not support, or refuses to support, the protocol |
---|
3401 | version that was used in the request message. The server is |
---|
3402 | indicating that it is unable or unwilling to complete the request |
---|
3403 | using the same major version as the client, as described in Section |
---|
3404 | 2.6 of [Part1], other than with this error message. The response |
---|
3405 | SHOULD contain a representation describing why that version is not |
---|
3406 | supported and what other protocols are supported by that server. |
---|
3407 | |
---|
3408 | 8. Response Header Fields |
---|
3409 | |
---|
3410 | The response header fields allow the server to pass additional |
---|
3411 | information about the response which cannot be placed in the status- |
---|
3412 | |
---|
3413 | |
---|
3414 | |
---|
3415 | Fielding & Reschke Expires April 7, 2013 [Page 61] |
---|
3416 | |
---|
3417 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
3418 | |
---|
3419 | |
---|
3420 | line. These header fields give information about the server and |
---|
3421 | about further access to the target resource (Section 5.5 of [Part1]). |
---|
3422 | |
---|
3423 | 8.1. Control Data |
---|
3424 | |
---|
3425 | Response header fields can supply control data that supplements the |
---|
3426 | status code or instructs the client where to go next. |
---|
3427 | |
---|
3428 | +-------------------+------------------------+ |
---|
3429 | | Header Field Name | Defined in... | |
---|
3430 | +-------------------+------------------------+ |
---|
3431 | | Age | Section 7.1 of [Part6] | |
---|
3432 | | Date | Section 8.1.1.2 | |
---|
3433 | | Location | Section 8.1.2 | |
---|
3434 | | Retry-After | Section 8.1.3 | |
---|
3435 | +-------------------+------------------------+ |
---|
3436 | |
---|
3437 | 8.1.1. Origination Date |
---|
3438 | |
---|
3439 | 8.1.1.1. Date/Time Formats |
---|
3440 | |
---|
3441 | HTTP applications have historically allowed three different formats |
---|
3442 | for date/time stamps. However, the preferred format is a fixed- |
---|
3443 | length subset of that defined by [RFC1123]: |
---|
3444 | |
---|
3445 | Sun, 06 Nov 1994 08:49:37 GMT ; RFC 1123 |
---|
3446 | |
---|
3447 | The other formats are described here only for compatibility with |
---|
3448 | obsolete implementations. |
---|
3449 | |
---|
3450 | Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format |
---|
3451 | Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format |
---|
3452 | |
---|
3453 | HTTP/1.1 clients and servers that parse a date value MUST accept all |
---|
3454 | three formats (for compatibility with HTTP/1.0), though they MUST |
---|
3455 | only generate the RFC 1123 format for representing HTTP-date values |
---|
3456 | in header fields. |
---|
3457 | |
---|
3458 | All HTTP date/time stamps MUST be represented in Greenwich Mean Time |
---|
3459 | (GMT), without exception. For the purposes of HTTP, GMT is exactly |
---|
3460 | equal to UTC (Coordinated Universal Time). This is indicated in the |
---|
3461 | first two formats by the inclusion of "GMT" as the three-letter |
---|
3462 | abbreviation for time zone, and MUST be assumed when reading the |
---|
3463 | asctime format. HTTP-date is case sensitive and MUST NOT include |
---|
3464 | additional whitespace beyond that specifically included as SP in the |
---|
3465 | grammar. |
---|
3466 | |
---|
3467 | HTTP-date = rfc1123-date / obs-date |
---|
3468 | |
---|
3469 | |
---|
3470 | |
---|
3471 | Fielding & Reschke Expires April 7, 2013 [Page 62] |
---|
3472 | |
---|
3473 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
3474 | |
---|
3475 | |
---|
3476 | Preferred format: |
---|
3477 | |
---|
3478 | rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT |
---|
3479 | ; fixed length subset of the format defined in |
---|
3480 | ; Section 5.2.14 of [RFC1123] |
---|
3481 | |
---|
3482 | day-name = %x4D.6F.6E ; "Mon", case-sensitive |
---|
3483 | / %x54.75.65 ; "Tue", case-sensitive |
---|
3484 | / %x57.65.64 ; "Wed", case-sensitive |
---|
3485 | / %x54.68.75 ; "Thu", case-sensitive |
---|
3486 | / %x46.72.69 ; "Fri", case-sensitive |
---|
3487 | / %x53.61.74 ; "Sat", case-sensitive |
---|
3488 | / %x53.75.6E ; "Sun", case-sensitive |
---|
3489 | |
---|
3490 | date1 = day SP month SP year |
---|
3491 | ; e.g., 02 Jun 1982 |
---|
3492 | |
---|
3493 | day = 2DIGIT |
---|
3494 | month = %x4A.61.6E ; "Jan", case-sensitive |
---|
3495 | / %x46.65.62 ; "Feb", case-sensitive |
---|
3496 | / %x4D.61.72 ; "Mar", case-sensitive |
---|
3497 | / %x41.70.72 ; "Apr", case-sensitive |
---|
3498 | / %x4D.61.79 ; "May", case-sensitive |
---|
3499 | / %x4A.75.6E ; "Jun", case-sensitive |
---|
3500 | / %x4A.75.6C ; "Jul", case-sensitive |
---|
3501 | / %x41.75.67 ; "Aug", case-sensitive |
---|
3502 | / %x53.65.70 ; "Sep", case-sensitive |
---|
3503 | / %x4F.63.74 ; "Oct", case-sensitive |
---|
3504 | / %x4E.6F.76 ; "Nov", case-sensitive |
---|
3505 | / %x44.65.63 ; "Dec", case-sensitive |
---|
3506 | year = 4DIGIT |
---|
3507 | |
---|
3508 | GMT = %x47.4D.54 ; "GMT", case-sensitive |
---|
3509 | |
---|
3510 | time-of-day = hour ":" minute ":" second |
---|
3511 | ; 00:00:00 - 23:59:59 |
---|
3512 | |
---|
3513 | hour = 2DIGIT |
---|
3514 | minute = 2DIGIT |
---|
3515 | second = 2DIGIT |
---|
3516 | |
---|
3517 | The semantics of day-name, day, month, year, and time-of-day are the |
---|
3518 | same as those defined for the RFC 5322 constructs with the |
---|
3519 | corresponding name ([RFC5322], Section 3.3). |
---|
3520 | |
---|
3521 | Obsolete formats: |
---|
3522 | |
---|
3523 | obs-date = rfc850-date / asctime-date |
---|
3524 | |
---|
3525 | |
---|
3526 | |
---|
3527 | Fielding & Reschke Expires April 7, 2013 [Page 63] |
---|
3528 | |
---|
3529 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
3530 | |
---|
3531 | |
---|
3532 | rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT |
---|
3533 | date2 = day "-" month "-" 2DIGIT |
---|
3534 | ; day-month-year (e.g., 02-Jun-82) |
---|
3535 | |
---|
3536 | day-name-l = %x4D.6F.6E.64.61.79 ; "Monday", case-sensitive |
---|
3537 | / %x54.75.65.73.64.61.79 ; "Tuesday", case-sensitive |
---|
3538 | / %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive |
---|
3539 | / %x54.68.75.72.73.64.61.79 ; "Thursday", case-sensitive |
---|
3540 | / %x46.72.69.64.61.79 ; "Friday", case-sensitive |
---|
3541 | / %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive |
---|
3542 | / %x53.75.6E.64.61.79 ; "Sunday", case-sensitive |
---|
3543 | |
---|
3544 | |
---|
3545 | asctime-date = day-name SP date3 SP time-of-day SP year |
---|
3546 | date3 = month SP ( 2DIGIT / ( SP 1DIGIT )) |
---|
3547 | ; month day (e.g., Jun 2) |
---|
3548 | |
---|
3549 | Note: Recipients of date values are encouraged to be robust in |
---|
3550 | accepting date values that might have been sent by non-HTTP |
---|
3551 | applications, as is sometimes the case when retrieving or posting |
---|
3552 | messages via proxies/gateways to SMTP or NNTP. |
---|
3553 | |
---|
3554 | Note: HTTP requirements for the date/time stamp format apply only |
---|
3555 | to their usage within the protocol stream. Clients and servers |
---|
3556 | are not required to use these formats for user presentation, |
---|
3557 | request logging, etc. |
---|
3558 | |
---|
3559 | 8.1.1.2. Date |
---|
3560 | |
---|
3561 | The "Date" header field represents the date and time at which the |
---|
3562 | message was originated, having the same semantics as the Origination |
---|
3563 | Date Field (orig-date) defined in Section 3.6.1 of [RFC5322]. The |
---|
3564 | field value is an HTTP-date, as defined in Section 8.1.1.1; it MUST |
---|
3565 | be sent in rfc1123-date format. |
---|
3566 | |
---|
3567 | Date = HTTP-date |
---|
3568 | |
---|
3569 | An example is |
---|
3570 | |
---|
3571 | Date: Tue, 15 Nov 1994 08:12:31 GMT |
---|
3572 | |
---|
3573 | Origin servers MUST include a Date header field in all responses, |
---|
3574 | except in these cases: |
---|
3575 | |
---|
3576 | 1. If the response status code is 100 (Continue) or 101 (Switching |
---|
3577 | Protocols), the response MAY include a Date header field, at the |
---|
3578 | server's option. |
---|
3579 | |
---|
3580 | |
---|
3581 | |
---|
3582 | |
---|
3583 | Fielding & Reschke Expires April 7, 2013 [Page 64] |
---|
3584 | |
---|
3585 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
3586 | |
---|
3587 | |
---|
3588 | 2. If the response status code conveys a server error, e.g., 500 |
---|
3589 | (Internal Server Error) or 503 (Service Unavailable), and it is |
---|
3590 | inconvenient or impossible to generate a valid Date. |
---|
3591 | |
---|
3592 | 3. If the server does not have a clock that can provide a reasonable |
---|
3593 | approximation of the current time, its responses MUST NOT include |
---|
3594 | a Date header field. |
---|
3595 | |
---|
3596 | A received message that does not have a Date header field MUST be |
---|
3597 | assigned one by the recipient if the message will be cached by that |
---|
3598 | recipient. |
---|
3599 | |
---|
3600 | Clients can use the Date header field as well; in order to keep |
---|
3601 | request messages small, they are advised not to include it when it |
---|
3602 | doesn't convey any useful information (as is usually the case for |
---|
3603 | requests that do not contain a payload). |
---|
3604 | |
---|
3605 | The HTTP-date sent in a Date header field SHOULD NOT represent a date |
---|
3606 | and time subsequent to the generation of the message. It SHOULD |
---|
3607 | represent the best available approximation of the date and time of |
---|
3608 | message generation, unless the implementation has no means of |
---|
3609 | generating a reasonably accurate date and time. In theory, the date |
---|
3610 | ought to represent the moment just before the payload is generated. |
---|
3611 | In practice, the date can be generated at any time during the message |
---|
3612 | origination without affecting its semantic value. |
---|
3613 | |
---|
3614 | 8.1.2. Location |
---|
3615 | |
---|
3616 | The "Location" header field MAY be sent in responses to refer to a |
---|
3617 | specific resource in accordance with the semantics of the status |
---|
3618 | code. |
---|
3619 | |
---|
3620 | Location = URI-reference |
---|
3621 | |
---|
3622 | For 201 (Created) responses, the Location is the URI of the new |
---|
3623 | resource which was created by the request. For 3xx (Redirection) |
---|
3624 | responses, the location SHOULD indicate the server's preferred URI |
---|
3625 | for automatic redirection to the resource. |
---|
3626 | |
---|
3627 | The field value consists of a single URI-reference. When it has the |
---|
3628 | form of a relative reference ([RFC3986], Section 4.2), the final |
---|
3629 | value is computed by resolving it against the effective request URI |
---|
3630 | ([RFC3986], Section 5). If the original URI, as navigated to by the |
---|
3631 | user agent, did contain a fragment identifier, and the final value |
---|
3632 | does not, then the original URI's fragment identifier is added to the |
---|
3633 | final value. |
---|
3634 | |
---|
3635 | |
---|
3636 | |
---|
3637 | |
---|
3638 | |
---|
3639 | Fielding & Reschke Expires April 7, 2013 [Page 65] |
---|
3640 | |
---|
3641 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
3642 | |
---|
3643 | |
---|
3644 | For example, the original URI "http://www.example.org/~tim", combined |
---|
3645 | with a field value given as: |
---|
3646 | |
---|
3647 | Location: /pub/WWW/People.html#tim |
---|
3648 | |
---|
3649 | would result in a final value of |
---|
3650 | "http://www.example.org/pub/WWW/People.html#tim" |
---|
3651 | |
---|
3652 | An original URI "http://www.example.org/index.html#larry", combined |
---|
3653 | with a field value given as: |
---|
3654 | |
---|
3655 | Location: http://www.example.net/index.html |
---|
3656 | |
---|
3657 | would result in a final value of |
---|
3658 | "http://www.example.net/index.html#larry", preserving the original |
---|
3659 | fragment identifier. |
---|
3660 | |
---|
3661 | Note: Some recipients attempt to recover from Location fields that |
---|
3662 | are not valid URI references. This specification does not mandate |
---|
3663 | or define such processing, but does allow it. |
---|
3664 | |
---|
3665 | There are circumstances in which a fragment identifier in a Location |
---|
3666 | URI would not be appropriate. For instance, when it appears in a 201 |
---|
3667 | (Created) response, where the Location header field specifies the URI |
---|
3668 | for the entire created resource. |
---|
3669 | |
---|
3670 | Note: The Content-Location header field (Section 3.1.4.2) differs |
---|
3671 | from Location in that the Content-Location identifies the most |
---|
3672 | specific resource corresponding to the enclosed representation. |
---|
3673 | It is therefore possible for a response to contain header fields |
---|
3674 | for both Location and Content-Location. |
---|
3675 | |
---|
3676 | 8.1.3. Retry-After |
---|
3677 | |
---|
3678 | The header "Retry-After" field can be used with a 503 (Service |
---|
3679 | Unavailable) response to indicate how long the service is expected to |
---|
3680 | be unavailable to the requesting client. This field MAY also be used |
---|
3681 | with any 3xx (Redirection) response to indicate the minimum time the |
---|
3682 | user-agent is asked to wait before issuing the redirected request. |
---|
3683 | |
---|
3684 | The value of this field can be either an HTTP-date or an integer |
---|
3685 | number of seconds (in decimal) after the time of the response. |
---|
3686 | |
---|
3687 | Retry-After = HTTP-date / delta-seconds |
---|
3688 | |
---|
3689 | Time spans are non-negative decimal integers, representing time in |
---|
3690 | seconds. |
---|
3691 | |
---|
3692 | |
---|
3693 | |
---|
3694 | |
---|
3695 | Fielding & Reschke Expires April 7, 2013 [Page 66] |
---|
3696 | |
---|
3697 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
3698 | |
---|
3699 | |
---|
3700 | delta-seconds = 1*DIGIT |
---|
3701 | |
---|
3702 | Two examples of its use are |
---|
3703 | |
---|
3704 | Retry-After: Fri, 31 Dec 1999 23:59:59 GMT |
---|
3705 | Retry-After: 120 |
---|
3706 | |
---|
3707 | In the latter example, the delay is 2 minutes. |
---|
3708 | |
---|
3709 | 8.2. Selected Representation Header Fields |
---|
3710 | |
---|
3711 | We use the term "selected representation" to refer to the the current |
---|
3712 | representation of a target resource that would have been selected in |
---|
3713 | a successful response if the same request had used the method GET and |
---|
3714 | excluded any conditional request header fields. |
---|
3715 | |
---|
3716 | Additional header fields define metadata about the selected |
---|
3717 | representation, which might differ from the representation included |
---|
3718 | in the message for responses to some state-changing methods. The |
---|
3719 | following header fields are defined as selected representation |
---|
3720 | metadata: |
---|
3721 | |
---|
3722 | +-------------------+------------------------+ |
---|
3723 | | Header Field Name | Defined in... | |
---|
3724 | +-------------------+------------------------+ |
---|
3725 | | ETag | Section 2.3 of [Part4] | |
---|
3726 | | Last-Modified | Section 2.2 of [Part4] | |
---|
3727 | | Vary | Section 8.2.1 | |
---|
3728 | +-------------------+------------------------+ |
---|
3729 | |
---|
3730 | 8.2.1. Vary |
---|
3731 | |
---|
3732 | The "Vary" header field conveys the set of header fields that were |
---|
3733 | used to select the representation. |
---|
3734 | |
---|
3735 | Caches use this information as part of determining whether a stored |
---|
3736 | response can be used to satisfy a given request (Section 4.3 of |
---|
3737 | [Part6]). |
---|
3738 | |
---|
3739 | In uncacheable or stale responses, the Vary field value advises the |
---|
3740 | user agent about the criteria that were used to select the |
---|
3741 | representation. |
---|
3742 | |
---|
3743 | Vary = "*" / 1#field-name |
---|
3744 | |
---|
3745 | The set of header fields named by the Vary field value is known as |
---|
3746 | the selecting header fields. |
---|
3747 | |
---|
3748 | |
---|
3749 | |
---|
3750 | |
---|
3751 | Fielding & Reschke Expires April 7, 2013 [Page 67] |
---|
3752 | |
---|
3753 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
3754 | |
---|
3755 | |
---|
3756 | A server SHOULD include a Vary header field with any cacheable |
---|
3757 | response that is subject to proactive negotiation. Doing so allows a |
---|
3758 | cache to properly interpret future requests on that resource and |
---|
3759 | informs the user agent about the presence of negotiation on that |
---|
3760 | resource. A server MAY include a Vary header field with a non- |
---|
3761 | cacheable response that is subject to proactive negotiation, since |
---|
3762 | this might provide the user agent with useful information about the |
---|
3763 | dimensions over which the response varies at the time of the |
---|
3764 | response. |
---|
3765 | |
---|
3766 | A Vary field value of "*" signals that unspecified parameters not |
---|
3767 | limited to the header fields (e.g., the network address of the |
---|
3768 | client), play a role in the selection of the response representation; |
---|
3769 | therefore, a cache cannot determine whether this response is |
---|
3770 | appropriate. A proxy MUST NOT generate the "*" value. |
---|
3771 | |
---|
3772 | The field-names given are not limited to the set of standard header |
---|
3773 | fields defined by this specification. Field names are case- |
---|
3774 | insensitive. |
---|
3775 | |
---|
3776 | 8.3. Authentication Challenges |
---|
3777 | |
---|
3778 | Authentication challenges indicate what mechanisms are available for |
---|
3779 | the client to provide authentication credentials in future requests. |
---|
3780 | |
---|
3781 | +--------------------+------------------------+ |
---|
3782 | | Header Field Name | Defined in... | |
---|
3783 | +--------------------+------------------------+ |
---|
3784 | | WWW-Authenticate | Section 4.4 of [Part7] | |
---|
3785 | | Proxy-Authenticate | Section 4.2 of [Part7] | |
---|
3786 | +--------------------+------------------------+ |
---|
3787 | |
---|
3788 | 8.4. Informative |
---|
3789 | |
---|
3790 | The remaining response header fields provide more information about |
---|
3791 | the target resource for potential use in later requests. |
---|
3792 | |
---|
3793 | +-------------------+------------------------+ |
---|
3794 | | Header Field Name | Defined in... | |
---|
3795 | +-------------------+------------------------+ |
---|
3796 | | Accept-Ranges | Section 5.1 of [Part5] | |
---|
3797 | | Allow | Section 8.4.1 | |
---|
3798 | | Server | Section 8.4.2 | |
---|
3799 | +-------------------+------------------------+ |
---|
3800 | |
---|
3801 | |
---|
3802 | |
---|
3803 | |
---|
3804 | |
---|
3805 | |
---|
3806 | |
---|
3807 | Fielding & Reschke Expires April 7, 2013 [Page 68] |
---|
3808 | |
---|
3809 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
3810 | |
---|
3811 | |
---|
3812 | 8.4.1. Allow |
---|
3813 | |
---|
3814 | The "Allow" header field lists the set of methods advertised as |
---|
3815 | supported by the target resource. The purpose of this field is |
---|
3816 | strictly to inform the recipient of valid request methods associated |
---|
3817 | with the resource. |
---|
3818 | |
---|
3819 | Allow = #method |
---|
3820 | |
---|
3821 | Example of use: |
---|
3822 | |
---|
3823 | Allow: GET, HEAD, PUT |
---|
3824 | |
---|
3825 | The actual set of allowed methods is defined by the origin server at |
---|
3826 | the time of each request. |
---|
3827 | |
---|
3828 | A proxy MUST NOT modify the Allow header field -- it does not need to |
---|
3829 | understand all the methods specified in order to handle them |
---|
3830 | according to the generic message handling rules. |
---|
3831 | |
---|
3832 | 8.4.2. Server |
---|
3833 | |
---|
3834 | The "Server" header field contains information about the software |
---|
3835 | used by the origin server to handle the request. |
---|
3836 | |
---|
3837 | The field can contain multiple product tokens (Section 4) and |
---|
3838 | comments (Section 3.2 of [Part1]) identifying the server and any |
---|
3839 | significant subproducts. The product tokens are listed in order of |
---|
3840 | their significance for identifying the application. |
---|
3841 | |
---|
3842 | Server = product *( RWS ( product / comment ) ) |
---|
3843 | |
---|
3844 | Example: |
---|
3845 | |
---|
3846 | Server: CERN/3.0 libwww/2.17 |
---|
3847 | |
---|
3848 | If the response is being forwarded through a proxy, the proxy |
---|
3849 | application MUST NOT modify the Server header field. Instead, it |
---|
3850 | MUST include a Via field (as described in Section 5.7 of [Part1]). |
---|
3851 | |
---|
3852 | Note: Revealing the specific software version of the server might |
---|
3853 | allow the server machine to become more vulnerable to attacks |
---|
3854 | against software that is known to contain security holes. Server |
---|
3855 | implementers are encouraged to make this field a configurable |
---|
3856 | option. |
---|
3857 | |
---|
3858 | |
---|
3859 | |
---|
3860 | |
---|
3861 | |
---|
3862 | |
---|
3863 | Fielding & Reschke Expires April 7, 2013 [Page 69] |
---|
3864 | |
---|
3865 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
3866 | |
---|
3867 | |
---|
3868 | 9. IANA Considerations |
---|
3869 | |
---|
3870 | 9.1. Method Registry |
---|
3871 | |
---|
3872 | The HTTP Method Registry defines the name space for the request |
---|
3873 | method token (Section 5). The method registry is maintained at |
---|
3874 | <http://www.iana.org/assignments/http-methods>. |
---|
3875 | |
---|
3876 | 9.1.1. Procedure |
---|
3877 | |
---|
3878 | HTTP method registrations MUST include the following fields: |
---|
3879 | |
---|
3880 | o Method Name (see Section 5) |
---|
3881 | |
---|
3882 | o Safe ("yes" or "no", see Section 5.2.1) |
---|
3883 | |
---|
3884 | o Idempotent ("yes" or "no", see Section 5.2.2) |
---|
3885 | |
---|
3886 | o Pointer to specification text |
---|
3887 | |
---|
3888 | Values to be added to this name space require IETF Review (see |
---|
3889 | [RFC5226], Section 4.1). |
---|
3890 | |
---|
3891 | 9.1.2. Considerations for New Methods |
---|
3892 | |
---|
3893 | Standardized methods are generic; that is, they are potentially |
---|
3894 | applicable to any resource, not just one particular media type, kind |
---|
3895 | of resource, or application. As such, it is preferred that new |
---|
3896 | methods be registered in a document that isn't specific to a single |
---|
3897 | application or data format, since orthogonal technologies deserve |
---|
3898 | orthogonal specification. |
---|
3899 | |
---|
3900 | Since message parsing (Section 3.3 of [Part1]) needs to be |
---|
3901 | independent of method semantics (aside from responses to HEAD), |
---|
3902 | definitions of new methods cannot change the parsing algorithm or |
---|
3903 | prohibit the presence of a message body on either the request or the |
---|
3904 | response message. Definitions of new methods can specify that only a |
---|
3905 | zero-length message body is allowed by requiring a Content-Length |
---|
3906 | header field with a value of "0". |
---|
3907 | |
---|
3908 | New method definitions need to indicate whether they are safe |
---|
3909 | (Section 5.2.1), idempotent (Section 5.2.2), cacheable |
---|
3910 | (Section 5.2.3), and what semantics are to be associated with the |
---|
3911 | payload body if any is present in the request. If a method is |
---|
3912 | cacheable, the method definition ought to describe how, and under |
---|
3913 | what conditions, a cache can store a response and use it to satisfy a |
---|
3914 | subsequent request. |
---|
3915 | |
---|
3916 | |
---|
3917 | |
---|
3918 | |
---|
3919 | Fielding & Reschke Expires April 7, 2013 [Page 70] |
---|
3920 | |
---|
3921 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
3922 | |
---|
3923 | |
---|
3924 | 9.1.3. Registrations |
---|
3925 | |
---|
3926 | The HTTP Method Registry shall be populated with the registrations |
---|
3927 | below: |
---|
3928 | |
---|
3929 | +---------+------+------------+---------------+ |
---|
3930 | | Method | Safe | Idempotent | Reference | |
---|
3931 | +---------+------+------------+---------------+ |
---|
3932 | | CONNECT | no | no | Section 5.3.6 | |
---|
3933 | | DELETE | no | yes | Section 5.3.5 | |
---|
3934 | | GET | yes | yes | Section 5.3.1 | |
---|
3935 | | HEAD | yes | yes | Section 5.3.2 | |
---|
3936 | | OPTIONS | yes | yes | Section 5.3.7 | |
---|
3937 | | POST | no | no | Section 5.3.3 | |
---|
3938 | | PUT | no | yes | Section 5.3.4 | |
---|
3939 | | TRACE | yes | yes | Section 5.3.8 | |
---|
3940 | +---------+------+------------+---------------+ |
---|
3941 | |
---|
3942 | 9.2. Status Code Registry |
---|
3943 | |
---|
3944 | The HTTP Status Code Registry defines the name space for the response |
---|
3945 | status-code token (Section 7). The status code registry is |
---|
3946 | maintained at <http://www.iana.org/assignments/http-status-codes>. |
---|
3947 | |
---|
3948 | This section replaces the registration procedure for HTTP Status |
---|
3949 | Codes previously defined in Section 7.1 of [RFC2817]. |
---|
3950 | |
---|
3951 | 9.2.1. Procedure |
---|
3952 | |
---|
3953 | Values to be added to the HTTP status code name space require IETF |
---|
3954 | Review (see [RFC5226], Section 4.1). |
---|
3955 | |
---|
3956 | 9.2.2. Considerations for New Status Codes |
---|
3957 | |
---|
3958 | When it is necessary to express semantics for a response that are not |
---|
3959 | defined by current status codes, a new status code can be registered. |
---|
3960 | HTTP status codes are generic; they are potentially applicable to any |
---|
3961 | resource, not just one particular media type, "type" of resource, or |
---|
3962 | application. As such, it is preferred that new status codes be |
---|
3963 | registered in a document that isn't specific to a single application. |
---|
3964 | |
---|
3965 | New status codes are required to fall under one of the categories |
---|
3966 | defined in Section 7. To allow existing parsers to properly handle |
---|
3967 | them, new status codes cannot disallow a payload, although they can |
---|
3968 | mandate a zero-length payload body. |
---|
3969 | |
---|
3970 | A definition for a new status code ought to explain the request |
---|
3971 | conditions that produce a response containing that status code (e.g., |
---|
3972 | |
---|
3973 | |
---|
3974 | |
---|
3975 | Fielding & Reschke Expires April 7, 2013 [Page 71] |
---|
3976 | |
---|
3977 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
3978 | |
---|
3979 | |
---|
3980 | combinations of request header fields and/or method(s)) along with |
---|
3981 | any dependencies on response header fields (e.g., what fields are |
---|
3982 | required and what fields can modify the semantics). A response that |
---|
3983 | can transfer a payload ought to specify expected cache behavior |
---|
3984 | (e.g., cacheability and freshness criteria, as described in [Part6]) |
---|
3985 | and whether the payload has any implied association with an |
---|
3986 | identified resource (Section 3.1.4.1). |
---|
3987 | |
---|
3988 | 9.2.3. Registrations |
---|
3989 | |
---|
3990 | The HTTP Status Code Registry shall be updated with the registrations |
---|
3991 | below: |
---|
3992 | |
---|
3993 | |
---|
3994 | |
---|
3995 | |
---|
3996 | |
---|
3997 | |
---|
3998 | |
---|
3999 | |
---|
4000 | |
---|
4001 | |
---|
4002 | |
---|
4003 | |
---|
4004 | |
---|
4005 | |
---|
4006 | |
---|
4007 | |
---|
4008 | |
---|
4009 | |
---|
4010 | |
---|
4011 | |
---|
4012 | |
---|
4013 | |
---|
4014 | |
---|
4015 | |
---|
4016 | |
---|
4017 | |
---|
4018 | |
---|
4019 | |
---|
4020 | |
---|
4021 | |
---|
4022 | |
---|
4023 | |
---|
4024 | |
---|
4025 | |
---|
4026 | |
---|
4027 | |
---|
4028 | |
---|
4029 | |
---|
4030 | |
---|
4031 | Fielding & Reschke Expires April 7, 2013 [Page 72] |
---|
4032 | |
---|
4033 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
4034 | |
---|
4035 | |
---|
4036 | +-------+----------------------------------+----------------+ |
---|
4037 | | Value | Description | Reference | |
---|
4038 | +-------+----------------------------------+----------------+ |
---|
4039 | | 100 | Continue | Section 7.2.1 | |
---|
4040 | | 101 | Switching Protocols | Section 7.2.2 | |
---|
4041 | | 200 | OK | Section 7.3.1 | |
---|
4042 | | 201 | Created | Section 7.3.2 | |
---|
4043 | | 202 | Accepted | Section 7.3.3 | |
---|
4044 | | 203 | Non-Authoritative Information | Section 7.3.4 | |
---|
4045 | | 204 | No Content | Section 7.3.5 | |
---|
4046 | | 205 | Reset Content | Section 7.3.6 | |
---|
4047 | | 300 | Multiple Choices | Section 7.4.1 | |
---|
4048 | | 301 | Moved Permanently | Section 7.4.2 | |
---|
4049 | | 302 | Found | Section 7.4.3 | |
---|
4050 | | 303 | See Other | Section 7.4.4 | |
---|
4051 | | 305 | Use Proxy | Section 7.4.5 | |
---|
4052 | | 306 | (Unused) | Section 7.4.6 | |
---|
4053 | | 307 | Temporary Redirect | Section 7.4.7 | |
---|
4054 | | 400 | Bad Request | Section 7.5.1 | |
---|
4055 | | 402 | Payment Required | Section 7.5.2 | |
---|
4056 | | 403 | Forbidden | Section 7.5.3 | |
---|
4057 | | 404 | Not Found | Section 7.5.4 | |
---|
4058 | | 405 | Method Not Allowed | Section 7.5.5 | |
---|
4059 | | 406 | Not Acceptable | Section 7.5.6 | |
---|
4060 | | 408 | Request Timeout | Section 7.5.7 | |
---|
4061 | | 409 | Conflict | Section 7.5.8 | |
---|
4062 | | 410 | Gone | Section 7.5.9 | |
---|
4063 | | 411 | Length Required | Section 7.5.10 | |
---|
4064 | | 413 | Request Representation Too Large | Section 7.5.11 | |
---|
4065 | | 414 | URI Too Long | Section 7.5.12 | |
---|
4066 | | 415 | Unsupported Media Type | Section 7.5.13 | |
---|
4067 | | 417 | Expectation Failed | Section 7.5.14 | |
---|
4068 | | 426 | Upgrade Required | Section 7.5.15 | |
---|
4069 | | 500 | Internal Server Error | Section 7.6.1 | |
---|
4070 | | 501 | Not Implemented | Section 7.6.2 | |
---|
4071 | | 502 | Bad Gateway | Section 7.6.3 | |
---|
4072 | | 503 | Service Unavailable | Section 7.6.4 | |
---|
4073 | | 504 | Gateway Timeout | Section 7.6.5 | |
---|
4074 | | 505 | HTTP Version Not Supported | Section 7.6.6 | |
---|
4075 | +-------+----------------------------------+----------------+ |
---|
4076 | |
---|
4077 | 9.3. Header Field Registry |
---|
4078 | |
---|
4079 | HTTP header fields are registered within the Message Header Field |
---|
4080 | Registry located at <http://www.iana.org/assignments/message-headers/ |
---|
4081 | message-header-index.html>, as defined by [RFC3864]. |
---|
4082 | |
---|
4083 | |
---|
4084 | |
---|
4085 | |
---|
4086 | |
---|
4087 | Fielding & Reschke Expires April 7, 2013 [Page 73] |
---|
4088 | |
---|
4089 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
4090 | |
---|
4091 | |
---|
4092 | 9.3.1. Considerations for New Header Fields |
---|
4093 | |
---|
4094 | Header fields are key:value pairs that can be used to communicate |
---|
4095 | data about the message, its payload, the target resource, or the |
---|
4096 | connection (i.e., control data). See Section 3.2 of [Part1] for a |
---|
4097 | general definition of header field syntax in HTTP messages. |
---|
4098 | |
---|
4099 | The requirements for header field names are defined in Section 4.1 of |
---|
4100 | [RFC3864]. Authors of specifications defining new fields are advised |
---|
4101 | to keep the name as short as practical, and not to prefix them with |
---|
4102 | "X-" if they are to be registered (either immediately or in the |
---|
4103 | future). |
---|
4104 | |
---|
4105 | New header field values typically have their syntax defined using |
---|
4106 | ABNF ([RFC5234]), using the extension defined in Appendix B of |
---|
4107 | [Part1] as necessary, and are usually constrained to the range of |
---|
4108 | ASCII characters. Header fields needing a greater range of |
---|
4109 | characters can use an encoding such as the one defined in [RFC5987]. |
---|
4110 | |
---|
4111 | Because commas (",") are used as a generic delimiter between field- |
---|
4112 | values, they need to be treated with care if they are allowed in the |
---|
4113 | field-value's payload. Typically, components that might contain a |
---|
4114 | comma are protected with double-quotes using the quoted-string ABNF |
---|
4115 | production (Section 3.2.4 of [Part1]). |
---|
4116 | |
---|
4117 | For example, a textual date and a URI (either of which might contain |
---|
4118 | a comma) could be safely carried in field-values like these: |
---|
4119 | |
---|
4120 | Example-URI-Field: "http://example.com/a.html,foo", |
---|
4121 | "http://without-a-comma.example.com/" |
---|
4122 | Example-Date-Field: "Sat, 04 May 1996", "Wed, 14 Sep 2005" |
---|
4123 | |
---|
4124 | Note that double-quote delimiters almost always are used with the |
---|
4125 | quoted-string production; using a different syntax inside double- |
---|
4126 | quotes will likely cause unnecessary confusion. |
---|
4127 | |
---|
4128 | Many header fields use a format including (case-insensitively) named |
---|
4129 | parameters (for instance, Content-Type, defined in Section 3.1.1.5). |
---|
4130 | Allowing both unquoted (token) and quoted (quoted-string) syntax for |
---|
4131 | the parameter value enables recipients to use existing parser |
---|
4132 | components. When allowing both forms, the meaning of a parameter |
---|
4133 | value ought to be independent of the syntax used for it (for an |
---|
4134 | example, see the notes on parameter handling for media types in |
---|
4135 | Section 3.1.1.1). |
---|
4136 | |
---|
4137 | Authors of specifications defining new header fields are advised to |
---|
4138 | consider documenting: |
---|
4139 | |
---|
4140 | |
---|
4141 | |
---|
4142 | |
---|
4143 | Fielding & Reschke Expires April 7, 2013 [Page 74] |
---|
4144 | |
---|
4145 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
4146 | |
---|
4147 | |
---|
4148 | o Whether the field is a single value, or whether it can be a list |
---|
4149 | (delimited by commas; see Section 3.2 of [Part1]). |
---|
4150 | |
---|
4151 | If it does not use the list syntax, document how to treat messages |
---|
4152 | where the header field occurs multiple times (a sensible default |
---|
4153 | would be to ignore the header field, but this might not always be |
---|
4154 | the right choice). |
---|
4155 | |
---|
4156 | Note that intermediaries and software libraries might combine |
---|
4157 | multiple header field instances into a single one, despite the |
---|
4158 | header field not allowing this. A robust format enables |
---|
4159 | recipients to discover these situations (good example: "Content- |
---|
4160 | Type", as the comma can only appear inside quoted strings; bad |
---|
4161 | example: "Location", as a comma can occur inside a URI). |
---|
4162 | |
---|
4163 | o Under what conditions the header field can be used; e.g., only in |
---|
4164 | responses or requests, in all messages, only on responses to a |
---|
4165 | particular request method. |
---|
4166 | |
---|
4167 | o Whether it is appropriate to list the field-name in the Connection |
---|
4168 | header field (i.e., if the header field is to be hop-by-hop, see |
---|
4169 | Section 6.1 of [Part1]). |
---|
4170 | |
---|
4171 | o Under what conditions intermediaries are allowed to modify the |
---|
4172 | header field's value, insert or delete it. |
---|
4173 | |
---|
4174 | o How the header field might interact with caching (see [Part6]). |
---|
4175 | |
---|
4176 | o Whether the header field is useful or allowable in trailers (see |
---|
4177 | Section 4.1 of [Part1]). |
---|
4178 | |
---|
4179 | o Whether the header field ought to be preserved across redirects. |
---|
4180 | |
---|
4181 | 9.3.2. Registrations |
---|
4182 | |
---|
4183 | The Message Header Field Registry shall be updated with the following |
---|
4184 | permanent registrations: |
---|
4185 | |
---|
4186 | |
---|
4187 | |
---|
4188 | |
---|
4189 | |
---|
4190 | |
---|
4191 | |
---|
4192 | |
---|
4193 | |
---|
4194 | |
---|
4195 | |
---|
4196 | |
---|
4197 | |
---|
4198 | |
---|
4199 | Fielding & Reschke Expires April 7, 2013 [Page 75] |
---|
4200 | |
---|
4201 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
4202 | |
---|
4203 | |
---|
4204 | +-------------------+----------+----------+-----------------+ |
---|
4205 | | Header Field Name | Protocol | Status | Reference | |
---|
4206 | +-------------------+----------+----------+-----------------+ |
---|
4207 | | Accept | http | standard | Section 6.3.2 | |
---|
4208 | | Accept-Charset | http | standard | Section 6.3.3 | |
---|
4209 | | Accept-Encoding | http | standard | Section 6.3.4 | |
---|
4210 | | Accept-Language | http | standard | Section 6.3.5 | |
---|
4211 | | Allow | http | standard | Section 8.4.1 | |
---|
4212 | | Content-Encoding | http | standard | Section 3.1.2.2 | |
---|
4213 | | Content-Language | http | standard | Section 3.1.3.2 | |
---|
4214 | | Content-Location | http | standard | Section 3.1.4.2 | |
---|
4215 | | Content-Type | http | standard | Section 3.1.1.5 | |
---|
4216 | | Date | http | standard | Section 8.1.1.2 | |
---|
4217 | | Expect | http | standard | Section 6.1.2 | |
---|
4218 | | From | http | standard | Section 6.5.1 | |
---|
4219 | | Location | http | standard | Section 8.1.2 | |
---|
4220 | | MIME-Version | http | standard | Appendix A.1 | |
---|
4221 | | Max-Forwards | http | standard | Section 6.1.1 | |
---|
4222 | | Referer | http | standard | Section 6.5.2 | |
---|
4223 | | Retry-After | http | standard | Section 8.1.3 | |
---|
4224 | | Server | http | standard | Section 8.4.2 | |
---|
4225 | | User-Agent | http | standard | Section 6.5.3 | |
---|
4226 | | Vary | http | standard | Section 8.2.1 | |
---|
4227 | +-------------------+----------+----------+-----------------+ |
---|
4228 | |
---|
4229 | The change controller for the above registrations is: "IETF |
---|
4230 | (iesg@ietf.org) - Internet Engineering Task Force". |
---|
4231 | |
---|
4232 | 9.4. Content Coding Registry |
---|
4233 | |
---|
4234 | The HTTP Content Coding Registry defines the name space for content |
---|
4235 | coding names (Section 4.2 of [Part1]). The content coding registry |
---|
4236 | is maintained at <http://www.iana.org/assignments/http-parameters>. |
---|
4237 | |
---|
4238 | 9.4.1. Procedure |
---|
4239 | |
---|
4240 | Content Coding registrations MUST include the following fields: |
---|
4241 | |
---|
4242 | o Name |
---|
4243 | |
---|
4244 | o Description |
---|
4245 | |
---|
4246 | o Pointer to specification text |
---|
4247 | |
---|
4248 | Names of content codings MUST NOT overlap with names of transfer |
---|
4249 | codings (Section 4 of [Part1]), unless the encoding transformation is |
---|
4250 | identical (as is the case for the compression codings defined in |
---|
4251 | Section 4.2 of [Part1]). |
---|
4252 | |
---|
4253 | |
---|
4254 | |
---|
4255 | Fielding & Reschke Expires April 7, 2013 [Page 76] |
---|
4256 | |
---|
4257 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
4258 | |
---|
4259 | |
---|
4260 | Values to be added to this name space require IETF Review (see |
---|
4261 | Section 4.1 of [RFC5226]), and MUST conform to the purpose of content |
---|
4262 | coding defined in this section. |
---|
4263 | |
---|
4264 | 9.4.2. Registrations |
---|
4265 | |
---|
4266 | The HTTP Content Codings Registry shall be updated with the |
---|
4267 | registrations below: |
---|
4268 | |
---|
4269 | +----------+----------------------------------------+---------------+ |
---|
4270 | | Name | Description | Reference | |
---|
4271 | +----------+----------------------------------------+---------------+ |
---|
4272 | | compress | UNIX "compress" program method | Section 4.2.1 | |
---|
4273 | | | | of [Part1] | |
---|
4274 | | deflate | "deflate" compression mechanism | Section 4.2.2 | |
---|
4275 | | | ([RFC1951]) used inside the "zlib" | of [Part1] | |
---|
4276 | | | data format ([RFC1950]) | | |
---|
4277 | | gzip | Same as GNU zip [RFC1952] | Section 4.2.3 | |
---|
4278 | | | | of [Part1] | |
---|
4279 | | identity | reserved (synonym for "no encoding" in | Section 6.3.4 | |
---|
4280 | | | Accept-Encoding header field) | | |
---|
4281 | +----------+----------------------------------------+---------------+ |
---|
4282 | |
---|
4283 | 10. Security Considerations |
---|
4284 | |
---|
4285 | This section is meant to inform application developers, information |
---|
4286 | providers, and users of the security limitations in HTTP/1.1 as |
---|
4287 | described by this document. The discussion does not include |
---|
4288 | definitive solutions to the problems revealed, though it does make |
---|
4289 | some suggestions for reducing security risks. |
---|
4290 | |
---|
4291 | 10.1. Transfer of Sensitive Information |
---|
4292 | |
---|
4293 | Like any generic data transfer protocol, HTTP cannot regulate the |
---|
4294 | content of the data that is transferred, nor is there any a priori |
---|
4295 | method of determining the sensitivity of any particular piece of |
---|
4296 | information within the context of any given request. Therefore, |
---|
4297 | applications SHOULD supply as much control over this information as |
---|
4298 | possible to the provider of that information. Four header fields are |
---|
4299 | worth special mention in this context: Server, Via, Referer and From. |
---|
4300 | |
---|
4301 | Revealing the specific software version of the server might allow the |
---|
4302 | server machine to become more vulnerable to attacks against software |
---|
4303 | that is known to contain security holes. Implementers SHOULD make |
---|
4304 | the Server header field a configurable option. |
---|
4305 | |
---|
4306 | Proxies which serve as a portal through a network firewall SHOULD |
---|
4307 | take special precautions regarding the transfer of header information |
---|
4308 | |
---|
4309 | |
---|
4310 | |
---|
4311 | Fielding & Reschke Expires April 7, 2013 [Page 77] |
---|
4312 | |
---|
4313 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
4314 | |
---|
4315 | |
---|
4316 | that identifies the hosts behind the firewall. In particular, they |
---|
4317 | SHOULD remove, or replace with sanitized versions, any Via fields |
---|
4318 | generated behind the firewall. |
---|
4319 | |
---|
4320 | The Referer header field allows reading patterns to be studied and |
---|
4321 | reverse links drawn. Although it can be very useful, its power can |
---|
4322 | be abused if user details are not separated from the information |
---|
4323 | contained in the Referer. Even when the personal information has |
---|
4324 | been removed, the Referer header field might indicate a private |
---|
4325 | document's URI whose publication would be inappropriate. |
---|
4326 | |
---|
4327 | The information sent in the From field might conflict with the user's |
---|
4328 | privacy interests or their site's security policy, and hence it |
---|
4329 | SHOULD NOT be transmitted without the user being able to disable, |
---|
4330 | enable, and modify the contents of the field. The user MUST be able |
---|
4331 | to set the contents of this field within a user preference or |
---|
4332 | application defaults configuration. |
---|
4333 | |
---|
4334 | We suggest, though do not require, that a convenient toggle interface |
---|
4335 | be provided for the user to enable or disable the sending of From and |
---|
4336 | Referer information. |
---|
4337 | |
---|
4338 | The User-Agent (Section 6.5.3) or Server (Section 8.4.2) header |
---|
4339 | fields can sometimes be used to determine that a specific client or |
---|
4340 | server has a particular security hole which might be exploited. |
---|
4341 | Unfortunately, this same information is often used for other valuable |
---|
4342 | purposes for which HTTP currently has no better mechanism. |
---|
4343 | |
---|
4344 | Furthermore, the User-Agent header field might contain enough entropy |
---|
4345 | to be used, possibly in conjunction with other material, to uniquely |
---|
4346 | identify the user. |
---|
4347 | |
---|
4348 | Some request methods, like TRACE (Section 5.3.8), expose information |
---|
4349 | that was sent in request header fields within the body of their |
---|
4350 | response. Clients SHOULD be careful with sensitive information, like |
---|
4351 | Cookies, Authorization credentials, and other header fields that |
---|
4352 | might be used to collect data from the client. |
---|
4353 | |
---|
4354 | 10.2. Encoding Sensitive Information in URIs |
---|
4355 | |
---|
4356 | Because the source of a link might be private information or might |
---|
4357 | reveal an otherwise private information source, it is strongly |
---|
4358 | recommended that the user be able to select whether or not the |
---|
4359 | Referer field is sent. For example, a browser client could have a |
---|
4360 | toggle switch for browsing openly/anonymously, which would |
---|
4361 | respectively enable/disable the sending of Referer and From |
---|
4362 | information. |
---|
4363 | |
---|
4364 | |
---|
4365 | |
---|
4366 | |
---|
4367 | Fielding & Reschke Expires April 7, 2013 [Page 78] |
---|
4368 | |
---|
4369 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
4370 | |
---|
4371 | |
---|
4372 | Clients SHOULD NOT include a Referer header field in a (non-secure) |
---|
4373 | HTTP request if the referring page was transferred with a secure |
---|
4374 | protocol. |
---|
4375 | |
---|
4376 | Authors of services SHOULD NOT use GET-based forms for the submission |
---|
4377 | of sensitive data because that data will be placed in the request- |
---|
4378 | target. Many existing servers, proxies, and user agents log or |
---|
4379 | display the request-target in places where it might be visible to |
---|
4380 | third parties. Such services can use POST-based form submission |
---|
4381 | instead. |
---|
4382 | |
---|
4383 | 10.3. Location Header Fields: Spoofing and Information Leakage |
---|
4384 | |
---|
4385 | If a single server supports multiple organizations that do not trust |
---|
4386 | one another, then it MUST check the values of Location and Content- |
---|
4387 | Location header fields in responses that are generated under control |
---|
4388 | of said organizations to make sure that they do not attempt to |
---|
4389 | invalidate resources over which they have no authority. |
---|
4390 | |
---|
4391 | Furthermore, appending the fragment identifier from one URI to |
---|
4392 | another one obtained from a Location header field might leak |
---|
4393 | confidential information to the target server -- although the |
---|
4394 | fragment identifier is not transmitted in the final request, it might |
---|
4395 | be visible to the user agent through other means, such as scripting. |
---|
4396 | |
---|
4397 | 10.4. Security Considerations for CONNECT |
---|
4398 | |
---|
4399 | Since tunneled data is opaque to the proxy, there are additional |
---|
4400 | risks to tunneling to other well-known or reserved ports. A HTTP |
---|
4401 | client CONNECTing to port 25 could relay spam via SMTP, for example. |
---|
4402 | As such, proxies SHOULD restrict CONNECT access to a small number of |
---|
4403 | known ports. |
---|
4404 | |
---|
4405 | 10.5. Privacy Issues Connected to Accept Header Fields |
---|
4406 | |
---|
4407 | Accept header fields can reveal information about the user to all |
---|
4408 | servers which are accessed. The Accept-Language header field in |
---|
4409 | particular can reveal information the user would consider to be of a |
---|
4410 | private nature, because the understanding of particular languages is |
---|
4411 | often strongly correlated to the membership of a particular ethnic |
---|
4412 | group. User agents which offer the option to configure the contents |
---|
4413 | of an Accept-Language header field to be sent in every request are |
---|
4414 | strongly encouraged to let the configuration process include a |
---|
4415 | message which makes the user aware of the loss of privacy involved. |
---|
4416 | |
---|
4417 | An approach that limits the loss of privacy would be for a user agent |
---|
4418 | to omit the sending of Accept-Language header fields by default, and |
---|
4419 | to ask the user whether or not to start sending Accept-Language |
---|
4420 | |
---|
4421 | |
---|
4422 | |
---|
4423 | Fielding & Reschke Expires April 7, 2013 [Page 79] |
---|
4424 | |
---|
4425 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
4426 | |
---|
4427 | |
---|
4428 | header fields to a server if it detects, by looking for any Vary |
---|
4429 | header fields generated by the server, that such sending could |
---|
4430 | improve the quality of service. |
---|
4431 | |
---|
4432 | Elaborate user-customized accept header fields sent in every request, |
---|
4433 | in particular if these include quality values, can be used by servers |
---|
4434 | as relatively reliable and long-lived user identifiers. Such user |
---|
4435 | identifiers would allow content providers to do click-trail tracking, |
---|
4436 | and would allow collaborating content providers to match cross-server |
---|
4437 | click-trails or form submissions of individual users. Note that for |
---|
4438 | many users not behind a proxy, the network address of the host |
---|
4439 | running the user agent will also serve as a long-lived user |
---|
4440 | identifier. In environments where proxies are used to enhance |
---|
4441 | privacy, user agents ought to be conservative in offering accept |
---|
4442 | header field configuration options to end users. As an extreme |
---|
4443 | privacy measure, proxies could filter the accept header fields in |
---|
4444 | relayed requests. General purpose user agents which provide a high |
---|
4445 | degree of header field configurability SHOULD warn users about the |
---|
4446 | loss of privacy which can be involved. |
---|
4447 | |
---|
4448 | 11. Acknowledgments |
---|
4449 | |
---|
4450 | See Section 9 of [Part1]. |
---|
4451 | |
---|
4452 | 12. References |
---|
4453 | |
---|
4454 | 12.1. Normative References |
---|
4455 | |
---|
4456 | [Part1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext |
---|
4457 | Transfer Protocol (HTTP/1.1): Message Syntax and |
---|
4458 | Routing", draft-ietf-httpbis-p1-messaging-21 (work in |
---|
4459 | progress), October 2012. |
---|
4460 | |
---|
4461 | [Part4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext |
---|
4462 | Transfer Protocol (HTTP/1.1): Conditional Requests", |
---|
4463 | draft-ietf-httpbis-p4-conditional-21 (work in |
---|
4464 | progress), October 2012. |
---|
4465 | |
---|
4466 | [Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., |
---|
4467 | "Hypertext Transfer Protocol (HTTP/1.1): Range |
---|
4468 | Requests", draft-ietf-httpbis-p5-range-21 (work in |
---|
4469 | progress), October 2012. |
---|
4470 | |
---|
4471 | [Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, |
---|
4472 | Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", |
---|
4473 | draft-ietf-httpbis-p6-cache-21 (work in progress), |
---|
4474 | October 2012. |
---|
4475 | |
---|
4476 | |
---|
4477 | |
---|
4478 | |
---|
4479 | Fielding & Reschke Expires April 7, 2013 [Page 80] |
---|
4480 | |
---|
4481 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
4482 | |
---|
4483 | |
---|
4484 | [Part7] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext |
---|
4485 | Transfer Protocol (HTTP/1.1): Authentication", |
---|
4486 | draft-ietf-httpbis-p7-auth-21 (work in progress), |
---|
4487 | October 2012. |
---|
4488 | |
---|
4489 | [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data |
---|
4490 | Format Specification version 3.3", RFC 1950, May 1996. |
---|
4491 | |
---|
4492 | [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format |
---|
4493 | Specification version 1.3", RFC 1951, May 1996. |
---|
4494 | |
---|
4495 | [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and |
---|
4496 | G. Randers-Pehrson, "GZIP file format specification |
---|
4497 | version 4.3", RFC 1952, May 1996. |
---|
4498 | |
---|
4499 | [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet |
---|
4500 | Mail Extensions (MIME) Part One: Format of Internet |
---|
4501 | Message Bodies", RFC 2045, November 1996. |
---|
4502 | |
---|
4503 | [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet |
---|
4504 | Mail Extensions (MIME) Part Two: Media Types", |
---|
4505 | RFC 2046, November 1996. |
---|
4506 | |
---|
4507 | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |
---|
4508 | Requirement Levels", BCP 14, RFC 2119, March 1997. |
---|
4509 | |
---|
4510 | [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, |
---|
4511 | "Uniform Resource Identifier (URI): Generic Syntax", |
---|
4512 | STD 66, RFC 3986, January 2005. |
---|
4513 | |
---|
4514 | [RFC4647] Phillips, A., Ed. and M. Davis, Ed., "Matching of |
---|
4515 | Language Tags", BCP 47, RFC 4647, September 2006. |
---|
4516 | |
---|
4517 | [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for |
---|
4518 | Syntax Specifications: ABNF", STD 68, RFC 5234, |
---|
4519 | January 2008. |
---|
4520 | |
---|
4521 | [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for |
---|
4522 | Identifying Languages", BCP 47, RFC 5646, |
---|
4523 | September 2009. |
---|
4524 | |
---|
4525 | 12.2. Informative References |
---|
4526 | |
---|
4527 | [REST] Fielding, R., "Architectural Styles and the Design of |
---|
4528 | Network-based Software Architectures", Doctoral |
---|
4529 | Dissertation, University of California, Irvine , |
---|
4530 | September 2000, |
---|
4531 | <http://roy.gbiv.com/pubs/dissertation/top.htm>. |
---|
4532 | |
---|
4533 | |
---|
4534 | |
---|
4535 | Fielding & Reschke Expires April 7, 2013 [Page 81] |
---|
4536 | |
---|
4537 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
4538 | |
---|
4539 | |
---|
4540 | [RFC1123] Braden, R., "Requirements for Internet Hosts - |
---|
4541 | Application and Support", STD 3, RFC 1123, |
---|
4542 | October 1989. |
---|
4543 | |
---|
4544 | [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, |
---|
4545 | "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, |
---|
4546 | May 1996. |
---|
4547 | |
---|
4548 | [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet |
---|
4549 | Mail Extensions (MIME) Part Five: Conformance Criteria |
---|
4550 | and Examples", RFC 2049, November 1996. |
---|
4551 | |
---|
4552 | [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and |
---|
4553 | T. Berners-Lee, "Hypertext Transfer Protocol -- |
---|
4554 | HTTP/1.1", RFC 2068, January 1997. |
---|
4555 | |
---|
4556 | [RFC2076] Palme, J., "Common Internet Message Headers", RFC 2076, |
---|
4557 | February 1997. |
---|
4558 | |
---|
4559 | [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and |
---|
4560 | Languages", BCP 18, RFC 2277, January 1998. |
---|
4561 | |
---|
4562 | [RFC2295] Holtman, K. and A. Mutz, "Transparent Content |
---|
4563 | Negotiation in HTTP", RFC 2295, March 1998. |
---|
4564 | |
---|
4565 | [RFC2388] Masinter, L., "Returning Values from Forms: multipart/ |
---|
4566 | form-data", RFC 2388, August 1998. |
---|
4567 | |
---|
4568 | [RFC2557] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud, |
---|
4569 | "MIME Encapsulation of Aggregate Documents, such as |
---|
4570 | HTML (MHTML)", RFC 2557, March 1999. |
---|
4571 | |
---|
4572 | [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., |
---|
4573 | Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext |
---|
4574 | Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. |
---|
4575 | |
---|
4576 | [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within |
---|
4577 | HTTP/1.1", RFC 2817, May 2000. |
---|
4578 | |
---|
4579 | [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO |
---|
4580 | 10646", STD 63, RFC 3629, November 2003. |
---|
4581 | |
---|
4582 | [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration |
---|
4583 | Procedures for Message Header Fields", BCP 90, |
---|
4584 | RFC 3864, September 2004. |
---|
4585 | |
---|
4586 | [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications |
---|
4587 | and Registration Procedures", BCP 13, RFC 4288, |
---|
4588 | |
---|
4589 | |
---|
4590 | |
---|
4591 | Fielding & Reschke Expires April 7, 2013 [Page 82] |
---|
4592 | |
---|
4593 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
4594 | |
---|
4595 | |
---|
4596 | December 2005. |
---|
4597 | |
---|
4598 | [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing |
---|
4599 | an IANA Considerations Section in RFCs", BCP 26, |
---|
4600 | RFC 5226, May 2008. |
---|
4601 | |
---|
4602 | [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, |
---|
4603 | October 2008. |
---|
4604 | |
---|
4605 | [RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP", |
---|
4606 | RFC 5789, March 2010. |
---|
4607 | |
---|
4608 | [RFC5987] Reschke, J., "Character Set and Language Encoding for |
---|
4609 | Hypertext Transfer Protocol (HTTP) Header Field |
---|
4610 | Parameters", RFC 5987, August 2010. |
---|
4611 | |
---|
4612 | [RFC6151] Turner, S. and L. Chen, "Updated Security |
---|
4613 | Considerations for the MD5 Message-Digest and the HMAC- |
---|
4614 | MD5 Algorithms", RFC 6151, March 2011. |
---|
4615 | |
---|
4616 | [RFC6266] Reschke, J., "Use of the Content-Disposition Header |
---|
4617 | Field in the Hypertext Transfer Protocol (HTTP)", |
---|
4618 | RFC 6266, June 2011. |
---|
4619 | |
---|
4620 | [status-308] Reschke, J., "The Hypertext Transfer Protocol (HTTP) |
---|
4621 | Status Code 308 (Permanent Redirect)", |
---|
4622 | draft-reschke-http-status-308-07 (work in progress), |
---|
4623 | March 2012. |
---|
4624 | |
---|
4625 | Appendix A. Differences between HTTP and MIME |
---|
4626 | |
---|
4627 | HTTP/1.1 uses many of the constructs defined for Internet Mail |
---|
4628 | ([RFC5322]) and the Multipurpose Internet Mail Extensions (MIME |
---|
4629 | [RFC2045]) to allow a message body to be transmitted in an open |
---|
4630 | variety of representations and with extensible mechanisms. However, |
---|
4631 | RFC 2045 discusses mail, and HTTP has a few features that are |
---|
4632 | different from those described in MIME. These differences were |
---|
4633 | carefully chosen to optimize performance over binary connections, to |
---|
4634 | allow greater freedom in the use of new media types, to make date |
---|
4635 | comparisons easier, and to acknowledge the practice of some early |
---|
4636 | HTTP servers and clients. |
---|
4637 | |
---|
4638 | This appendix describes specific areas where HTTP differs from MIME. |
---|
4639 | Proxies and gateways to strict MIME environments SHOULD be aware of |
---|
4640 | these differences and provide the appropriate conversions where |
---|
4641 | necessary. Proxies and gateways from MIME environments to HTTP also |
---|
4642 | need to be aware of the differences because some conversions might be |
---|
4643 | required. |
---|
4644 | |
---|
4645 | |
---|
4646 | |
---|
4647 | Fielding & Reschke Expires April 7, 2013 [Page 83] |
---|
4648 | |
---|
4649 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
4650 | |
---|
4651 | |
---|
4652 | A.1. MIME-Version |
---|
4653 | |
---|
4654 | HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages |
---|
4655 | MAY include a single MIME-Version header field to indicate what |
---|
4656 | version of the MIME protocol was used to construct the message. Use |
---|
4657 | of the MIME-Version header field indicates that the message is in |
---|
4658 | full conformance with the MIME protocol (as defined in [RFC2045]). |
---|
4659 | Proxies/gateways are responsible for ensuring full conformance (where |
---|
4660 | possible) when exporting HTTP messages to strict MIME environments. |
---|
4661 | |
---|
4662 | MIME-Version = 1*DIGIT "." 1*DIGIT |
---|
4663 | |
---|
4664 | MIME version "1.0" is the default for use in HTTP/1.1. However, |
---|
4665 | HTTP/1.1 message parsing and semantics are defined by this document |
---|
4666 | and not the MIME specification. |
---|
4667 | |
---|
4668 | A.2. Conversion to Canonical Form |
---|
4669 | |
---|
4670 | MIME requires that an Internet mail body-part be converted to |
---|
4671 | canonical form prior to being transferred, as described in Section 4 |
---|
4672 | of [RFC2049]. Section 3.1.1.3 of this document describes the forms |
---|
4673 | allowed for subtypes of the "text" media type when transmitted over |
---|
4674 | HTTP. [RFC2046] requires that content with a type of "text" |
---|
4675 | represent line breaks as CRLF and forbids the use of CR or LF outside |
---|
4676 | of line break sequences. HTTP allows CRLF, bare CR, and bare LF to |
---|
4677 | indicate a line break within text content when a message is |
---|
4678 | transmitted over HTTP. |
---|
4679 | |
---|
4680 | Where it is possible, a proxy or gateway from HTTP to a strict MIME |
---|
4681 | environment SHOULD translate all line breaks within the text media |
---|
4682 | types described in Section 3.1.1.3 of this document to the RFC 2049 |
---|
4683 | canonical form of CRLF. Note, however, that this might be |
---|
4684 | complicated by the presence of a Content-Encoding and by the fact |
---|
4685 | that HTTP allows the use of some character encodings which do not use |
---|
4686 | octets 13 and 10 to represent CR and LF, respectively, as is the case |
---|
4687 | for some multi-byte character encodings. |
---|
4688 | |
---|
4689 | Conversion will break any cryptographic checksums applied to the |
---|
4690 | original content unless the original content is already in canonical |
---|
4691 | form. Therefore, the canonical form is recommended for any content |
---|
4692 | that uses such checksums in HTTP. |
---|
4693 | |
---|
4694 | A.3. Conversion of Date Formats |
---|
4695 | |
---|
4696 | HTTP/1.1 uses a restricted set of date formats (Section 8.1.1.1) to |
---|
4697 | simplify the process of date comparison. Proxies and gateways from |
---|
4698 | other protocols SHOULD ensure that any Date header field present in a |
---|
4699 | message conforms to one of the HTTP/1.1 formats and rewrite the date |
---|
4700 | |
---|
4701 | |
---|
4702 | |
---|
4703 | Fielding & Reschke Expires April 7, 2013 [Page 84] |
---|
4704 | |
---|
4705 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
4706 | |
---|
4707 | |
---|
4708 | if necessary. |
---|
4709 | |
---|
4710 | A.4. Introduction of Content-Encoding |
---|
4711 | |
---|
4712 | MIME does not include any concept equivalent to HTTP/1.1's Content- |
---|
4713 | Encoding header field. Since this acts as a modifier on the media |
---|
4714 | type, proxies and gateways from HTTP to MIME-compliant protocols MUST |
---|
4715 | either change the value of the Content-Type header field or decode |
---|
4716 | the representation before forwarding the message. (Some experimental |
---|
4717 | applications of Content-Type for Internet mail have used a media-type |
---|
4718 | parameter of ";conversions=<content-coding>" to perform a function |
---|
4719 | equivalent to Content-Encoding. However, this parameter is not part |
---|
4720 | of the MIME standards). |
---|
4721 | |
---|
4722 | A.5. No Content-Transfer-Encoding |
---|
4723 | |
---|
4724 | HTTP does not use the Content-Transfer-Encoding field of MIME. |
---|
4725 | Proxies and gateways from MIME-compliant protocols to HTTP MUST |
---|
4726 | remove any Content-Transfer-Encoding prior to delivering the response |
---|
4727 | message to an HTTP client. |
---|
4728 | |
---|
4729 | Proxies and gateways from HTTP to MIME-compliant protocols are |
---|
4730 | responsible for ensuring that the message is in the correct format |
---|
4731 | and encoding for safe transport on that protocol, where "safe |
---|
4732 | transport" is defined by the limitations of the protocol being used. |
---|
4733 | Such a proxy or gateway SHOULD label the data with an appropriate |
---|
4734 | Content-Transfer-Encoding if doing so will improve the likelihood of |
---|
4735 | safe transport over the destination protocol. |
---|
4736 | |
---|
4737 | A.6. MHTML and Line Length Limitations |
---|
4738 | |
---|
4739 | HTTP implementations which share code with MHTML [RFC2557] |
---|
4740 | implementations need to be aware of MIME line length limitations. |
---|
4741 | Since HTTP does not have this limitation, HTTP does not fold long |
---|
4742 | lines. MHTML messages being transported by HTTP follow all |
---|
4743 | conventions of MHTML, including line length limitations and folding, |
---|
4744 | canonicalization, etc., since HTTP transports all message-bodies as |
---|
4745 | payload (see Section 3.1.1.4) and does not interpret the content or |
---|
4746 | any MIME header lines that might be contained therein. |
---|
4747 | |
---|
4748 | Appendix B. Additional Features |
---|
4749 | |
---|
4750 | [RFC1945] and [RFC2068] document protocol elements used by some |
---|
4751 | existing HTTP implementations, but not consistently and correctly |
---|
4752 | across most HTTP/1.1 applications. Implementers are advised to be |
---|
4753 | aware of these features, but cannot rely upon their presence in, or |
---|
4754 | interoperability with, other HTTP/1.1 applications. Some of these |
---|
4755 | describe proposed experimental features, and some describe features |
---|
4756 | |
---|
4757 | |
---|
4758 | |
---|
4759 | Fielding & Reschke Expires April 7, 2013 [Page 85] |
---|
4760 | |
---|
4761 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
4762 | |
---|
4763 | |
---|
4764 | that experimental deployment found lacking that are now addressed in |
---|
4765 | the base HTTP/1.1 specification. |
---|
4766 | |
---|
4767 | A number of other header fields, such as Content-Disposition and |
---|
4768 | Title, from SMTP and MIME are also often implemented (see [RFC6266] |
---|
4769 | and [RFC2076]). |
---|
4770 | |
---|
4771 | Appendix C. Changes from RFC 2616 |
---|
4772 | |
---|
4773 | Remove base URI setting semantics for "Content-Location" due to poor |
---|
4774 | implementation support, which was caused by too many broken servers |
---|
4775 | emitting bogus Content-Location header fields, and also the |
---|
4776 | potentially undesirable effect of potentially breaking relative links |
---|
4777 | in content-negotiated resources. (Section 3.1.4.2) |
---|
4778 | |
---|
4779 | Clarify definition of POST. (Section 5.3.3) |
---|
4780 | |
---|
4781 | Remove requirement to handle all Content-* header fields; ban use of |
---|
4782 | Content-Range with PUT. (Section 5.3.4) |
---|
4783 | |
---|
4784 | Take over definition of CONNECT method from [RFC2817]. |
---|
4785 | (Section 5.3.6) |
---|
4786 | |
---|
4787 | Restrict "Max-Forwards" header field to OPTIONS and TRACE |
---|
4788 | (previously, extension methods could have used it as well). |
---|
4789 | (Section 6.1.1) |
---|
4790 | |
---|
4791 | The ABNF for the "Expect" header field has been both fixed (allowing |
---|
4792 | parameters for value-less expectations as well) and simplified |
---|
4793 | (allowing trailing semicolons after "100-continue" when they were |
---|
4794 | invalid before). (Section 6.1.2) |
---|
4795 | |
---|
4796 | Remove ISO-8859-1 special-casing in Accept-Charset. (Section 6.3.3) |
---|
4797 | |
---|
4798 | Allow "Referer" field value of "about:blank" as alternative to not |
---|
4799 | specifying it. (Section 6.5.2) |
---|
4800 | |
---|
4801 | Broadened the definition of 203 (Non-Authoritative Information) to |
---|
4802 | include cases of payload transformations as well. (Section 7.3.4) |
---|
4803 | |
---|
4804 | Status codes 301, 302, and 307: removed the normative requirements on |
---|
4805 | both response payloads and user interaction. (Section 7.4) |
---|
4806 | |
---|
4807 | Failed to consider that there are many other request methods that are |
---|
4808 | safe to automatically redirect, and further that the user agent is |
---|
4809 | able to make that determination based on the request method |
---|
4810 | semantics. Furthermore, allow user agents to rewrite the method from |
---|
4811 | POST to GET for status codes 301 and 302. (Sections 7.4.2, 7.4.3 and |
---|
4812 | |
---|
4813 | |
---|
4814 | |
---|
4815 | Fielding & Reschke Expires April 7, 2013 [Page 86] |
---|
4816 | |
---|
4817 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
4818 | |
---|
4819 | |
---|
4820 | 7.4.7) |
---|
4821 | |
---|
4822 | Deprecate 305 (Use Proxy) status code, because user agents did not |
---|
4823 | implement it. It used to indicate that the target resource needs to |
---|
4824 | be accessed through the proxy given by the Location field. The |
---|
4825 | Location field gave the URI of the proxy. The recipient was expected |
---|
4826 | to repeat this single request via the proxy. (Section 7.4.5) |
---|
4827 | |
---|
4828 | Define status 426 (Upgrade Required) (this was incorporated from |
---|
4829 | [RFC2817]). (Section 7.5.15) |
---|
4830 | |
---|
4831 | Correct syntax of "Location" header field to allow URI references |
---|
4832 | (including relative references and fragments), as referred symbol |
---|
4833 | "absoluteURI" wasn't what was expected, and add some clarifications |
---|
4834 | as to when use of fragments would not be appropriate. |
---|
4835 | (Section 8.1.2) |
---|
4836 | |
---|
4837 | Reclassify "Allow" as response header field, removing the option to |
---|
4838 | specify it in a PUT request. Relax the server requirement on the |
---|
4839 | contents of the Allow header field and remove requirement on clients |
---|
4840 | to always trust the header field value. (Section 8.4.1) |
---|
4841 | |
---|
4842 | In the description of the "Server" header field, the "Via" field was |
---|
4843 | described as a SHOULD. The requirement was and is stated correctly |
---|
4844 | in the description of the Via header field in Section 5.7 of [Part1]. |
---|
4845 | (Section 8.4.2) |
---|
4846 | |
---|
4847 | Clarify contexts that charset is used in. (Section 3.1.1.2) |
---|
4848 | |
---|
4849 | Remove the default character encoding of "ISO-8859-1" for text media |
---|
4850 | types; the default now is whatever the media type definition says. |
---|
4851 | (Section 3.1.1.3) |
---|
4852 | |
---|
4853 | Registration of Content Codings now requires IETF Review |
---|
4854 | (Section 9.4) |
---|
4855 | |
---|
4856 | Remove definition of "Content-MD5 header" field because it was |
---|
4857 | inconsistently implemented with respect to partial responses, and |
---|
4858 | also because of known deficiencies in the hash algorithm itself (see |
---|
4859 | [RFC6151] for details). |
---|
4860 | |
---|
4861 | Introduce Method Registry. (Section 9.1) |
---|
4862 | |
---|
4863 | Take over the Status Code Registry, previously defined in Section 7.1 |
---|
4864 | of [RFC2817]. (Section 9.2) |
---|
4865 | |
---|
4866 | Remove reference to non-existant identity transfer-coding value |
---|
4867 | tokens. (Appendix A.5) |
---|
4868 | |
---|
4869 | |
---|
4870 | |
---|
4871 | Fielding & Reschke Expires April 7, 2013 [Page 87] |
---|
4872 | |
---|
4873 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
4874 | |
---|
4875 | |
---|
4876 | Remove discussion of Content-Disposition header field, it is now |
---|
4877 | defined by [RFC6266]. (Appendix B) |
---|
4878 | |
---|
4879 | Appendix D. Imported ABNF |
---|
4880 | |
---|
4881 | The following core rules are included by reference, as defined in |
---|
4882 | Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return), |
---|
4883 | CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double |
---|
4884 | quote), HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF |
---|
4885 | (line feed), OCTET (any 8-bit sequence of data), SP (space), and |
---|
4886 | VCHAR (any visible US-ASCII character). |
---|
4887 | |
---|
4888 | The rules below are defined in [Part1]: |
---|
4889 | |
---|
4890 | BWS = <BWS, defined in [Part1], Section 3.2.1> |
---|
4891 | OWS = <OWS, defined in [Part1], Section 3.2.1> |
---|
4892 | RWS = <RWS, defined in [Part1], Section 3.2.1> |
---|
4893 | URI-reference = <URI-reference, defined in [Part1], Section 2.7> |
---|
4894 | absolute-URI = <absolute-URI, defined in [Part1], Section 2.7> |
---|
4895 | comment = <comment, defined in [Part1], Section 3.2.4> |
---|
4896 | field-name = <comment, defined in [Part1], Section 3.2> |
---|
4897 | partial-URI = <partial-URI, defined in [Part1], Section 2.7> |
---|
4898 | quoted-string = <quoted-string, defined in [Part1], Section 3.2.4> |
---|
4899 | token = <token, defined in [Part1], Section 3.2.4> |
---|
4900 | word = <word, defined in [Part1], Section 3.2.4> |
---|
4901 | |
---|
4902 | Appendix E. Collected ABNF |
---|
4903 | |
---|
4904 | Accept = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [ |
---|
4905 | OWS ( media-range [ accept-params ] ) ] ) ] |
---|
4906 | Accept-Charset = *( "," OWS ) ( ( charset / "*" ) [ weight ] ) *( OWS |
---|
4907 | "," [ OWS ( ( charset / "*" ) [ weight ] ) ] ) |
---|
4908 | Accept-Encoding = [ ( "," / ( codings [ weight ] ) ) *( OWS "," [ OWS |
---|
4909 | ( codings [ weight ] ) ] ) ] |
---|
4910 | Accept-Language = *( "," OWS ) ( language-range [ weight ] ) *( OWS |
---|
4911 | "," [ OWS ( language-range [ weight ] ) ] ) |
---|
4912 | Allow = [ ( "," / method ) *( OWS "," [ OWS method ] ) ] |
---|
4913 | |
---|
4914 | BWS = <BWS, defined in [Part1], Section 3.2.1> |
---|
4915 | |
---|
4916 | Content-Encoding = *( "," OWS ) content-coding *( OWS "," [ OWS |
---|
4917 | content-coding ] ) |
---|
4918 | Content-Language = *( "," OWS ) language-tag *( OWS "," [ OWS |
---|
4919 | language-tag ] ) |
---|
4920 | Content-Location = absolute-URI / partial-URI |
---|
4921 | Content-Type = media-type |
---|
4922 | |
---|
4923 | Date = HTTP-date |
---|
4924 | |
---|
4925 | |
---|
4926 | |
---|
4927 | Fielding & Reschke Expires April 7, 2013 [Page 88] |
---|
4928 | |
---|
4929 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
4930 | |
---|
4931 | |
---|
4932 | Expect = *( "," OWS ) expectation *( OWS "," [ OWS expectation ] ) |
---|
4933 | |
---|
4934 | From = mailbox |
---|
4935 | |
---|
4936 | GMT = %x47.4D.54 ; GMT |
---|
4937 | |
---|
4938 | HTTP-date = rfc1123-date / obs-date |
---|
4939 | |
---|
4940 | Location = URI-reference |
---|
4941 | |
---|
4942 | MIME-Version = 1*DIGIT "." 1*DIGIT |
---|
4943 | Max-Forwards = 1*DIGIT |
---|
4944 | |
---|
4945 | OWS = <OWS, defined in [Part1], Section 3.2.1> |
---|
4946 | |
---|
4947 | RWS = <RWS, defined in [Part1], Section 3.2.1> |
---|
4948 | Referer = absolute-URI / partial-URI |
---|
4949 | Retry-After = HTTP-date / delta-seconds |
---|
4950 | |
---|
4951 | Server = product *( RWS ( product / comment ) ) |
---|
4952 | |
---|
4953 | URI-reference = <URI-reference, defined in [Part1], Section 2.7> |
---|
4954 | User-Agent = product *( RWS ( product / comment ) ) |
---|
4955 | |
---|
4956 | Vary = "*" / ( *( "," OWS ) field-name *( OWS "," [ OWS field-name ] |
---|
4957 | ) ) |
---|
4958 | |
---|
4959 | absolute-URI = <absolute-URI, defined in [Part1], Section 2.7> |
---|
4960 | accept-ext = OWS ";" OWS token [ "=" word ] |
---|
4961 | accept-params = weight *accept-ext |
---|
4962 | asctime-date = day-name SP date3 SP time-of-day SP year |
---|
4963 | attribute = token |
---|
4964 | |
---|
4965 | charset = token |
---|
4966 | codings = content-coding / "identity" / "*" |
---|
4967 | comment = <comment, defined in [Part1], Section 3.2.4> |
---|
4968 | content-coding = token |
---|
4969 | |
---|
4970 | date1 = day SP month SP year |
---|
4971 | date2 = day "-" month "-" 2DIGIT |
---|
4972 | date3 = month SP ( 2DIGIT / ( SP DIGIT ) ) |
---|
4973 | day = 2DIGIT |
---|
4974 | |
---|
4975 | |
---|
4976 | |
---|
4977 | |
---|
4978 | |
---|
4979 | |
---|
4980 | |
---|
4981 | |
---|
4982 | |
---|
4983 | Fielding & Reschke Expires April 7, 2013 [Page 89] |
---|
4984 | |
---|
4985 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
4986 | |
---|
4987 | |
---|
4988 | day-name = %x4D.6F.6E ; Mon |
---|
4989 | / %x54.75.65 ; Tue |
---|
4990 | / %x57.65.64 ; Wed |
---|
4991 | / %x54.68.75 ; Thu |
---|
4992 | / %x46.72.69 ; Fri |
---|
4993 | / %x53.61.74 ; Sat |
---|
4994 | / %x53.75.6E ; Sun |
---|
4995 | day-name-l = %x4D.6F.6E.64.61.79 ; Monday |
---|
4996 | / %x54.75.65.73.64.61.79 ; Tuesday |
---|
4997 | / %x57.65.64.6E.65.73.64.61.79 ; Wednesday |
---|
4998 | / %x54.68.75.72.73.64.61.79 ; Thursday |
---|
4999 | / %x46.72.69.64.61.79 ; Friday |
---|
5000 | / %x53.61.74.75.72.64.61.79 ; Saturday |
---|
5001 | / %x53.75.6E.64.61.79 ; Sunday |
---|
5002 | delta-seconds = 1*DIGIT |
---|
5003 | |
---|
5004 | expect-name = token |
---|
5005 | expect-param = expect-name [ BWS "=" BWS expect-value ] |
---|
5006 | expect-value = token / quoted-string |
---|
5007 | expectation = expect-name [ BWS "=" BWS expect-value ] *( OWS ";" [ |
---|
5008 | OWS expect-param ] ) |
---|
5009 | |
---|
5010 | field-name = <comment, defined in [Part1], Section 3.2> |
---|
5011 | |
---|
5012 | hour = 2DIGIT |
---|
5013 | |
---|
5014 | language-range = <language-range, defined in [RFC4647], Section 2.1> |
---|
5015 | language-tag = <Language-Tag, defined in [RFC5646], Section 2.1> |
---|
5016 | |
---|
5017 | mailbox = <mailbox, defined in [RFC5322], Section 3.4> |
---|
5018 | media-range = ( "*/*" / ( type "/*" ) / ( type "/" subtype ) ) *( OWS |
---|
5019 | ";" OWS parameter ) |
---|
5020 | media-type = type "/" subtype *( OWS ";" OWS parameter ) |
---|
5021 | method = token |
---|
5022 | minute = 2DIGIT |
---|
5023 | month = %x4A.61.6E ; Jan |
---|
5024 | / %x46.65.62 ; Feb |
---|
5025 | / %x4D.61.72 ; Mar |
---|
5026 | / %x41.70.72 ; Apr |
---|
5027 | / %x4D.61.79 ; May |
---|
5028 | / %x4A.75.6E ; Jun |
---|
5029 | / %x4A.75.6C ; Jul |
---|
5030 | / %x41.75.67 ; Aug |
---|
5031 | / %x53.65.70 ; Sep |
---|
5032 | / %x4F.63.74 ; Oct |
---|
5033 | / %x4E.6F.76 ; Nov |
---|
5034 | / %x44.65.63 ; Dec |
---|
5035 | |
---|
5036 | |
---|
5037 | |
---|
5038 | |
---|
5039 | Fielding & Reschke Expires April 7, 2013 [Page 90] |
---|
5040 | |
---|
5041 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
5042 | |
---|
5043 | |
---|
5044 | obs-date = rfc850-date / asctime-date |
---|
5045 | |
---|
5046 | parameter = attribute "=" value |
---|
5047 | partial-URI = <partial-URI, defined in [Part1], Section 2.7> |
---|
5048 | product = token [ "/" product-version ] |
---|
5049 | product-version = token |
---|
5050 | |
---|
5051 | quoted-string = <quoted-string, defined in [Part1], Section 3.2.4> |
---|
5052 | qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] ) |
---|
5053 | |
---|
5054 | rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT |
---|
5055 | rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT |
---|
5056 | |
---|
5057 | second = 2DIGIT |
---|
5058 | subtype = token |
---|
5059 | |
---|
5060 | time-of-day = hour ":" minute ":" second |
---|
5061 | token = <token, defined in [Part1], Section 3.2.4> |
---|
5062 | type = token |
---|
5063 | |
---|
5064 | value = word |
---|
5065 | |
---|
5066 | weight = OWS ";" OWS "q=" qvalue |
---|
5067 | word = <word, defined in [Part1], Section 3.2.4> |
---|
5068 | |
---|
5069 | year = 4DIGIT |
---|
5070 | |
---|
5071 | Appendix F. Change Log (to be removed by RFC Editor before publication) |
---|
5072 | |
---|
5073 | F.1. Since RFC 2616 |
---|
5074 | |
---|
5075 | Extracted relevant partitions from [RFC2616]. |
---|
5076 | |
---|
5077 | F.2. Since draft-ietf-httpbis-p2-semantics-00 |
---|
5078 | |
---|
5079 | Closed issues: |
---|
5080 | |
---|
5081 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/5>: "Via is a MUST" |
---|
5082 | (<http://purl.org/NET/http-errata#via-must>) |
---|
5083 | |
---|
5084 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/6>: "Fragments |
---|
5085 | allowed in Location" |
---|
5086 | (<http://purl.org/NET/http-errata#location-fragments>) |
---|
5087 | |
---|
5088 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/10>: "Safe Methods |
---|
5089 | vs Redirection" (<http://purl.org/NET/http-errata#saferedirect>) |
---|
5090 | |
---|
5091 | |
---|
5092 | |
---|
5093 | |
---|
5094 | |
---|
5095 | Fielding & Reschke Expires April 7, 2013 [Page 91] |
---|
5096 | |
---|
5097 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
5098 | |
---|
5099 | |
---|
5100 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/17>: "Revise |
---|
5101 | description of the POST method" |
---|
5102 | (<http://purl.org/NET/http-errata#post>) |
---|
5103 | |
---|
5104 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and |
---|
5105 | Informative references" |
---|
5106 | |
---|
5107 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/42>: "RFC2606 |
---|
5108 | Compliance" |
---|
5109 | |
---|
5110 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/65>: "Informative |
---|
5111 | references" |
---|
5112 | |
---|
5113 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/84>: "Redundant |
---|
5114 | cross-references" |
---|
5115 | |
---|
5116 | Other changes: |
---|
5117 | |
---|
5118 | o Move definitions of 304 and 412 condition codes to [Part4] |
---|
5119 | |
---|
5120 | F.3. Since draft-ietf-httpbis-p3-payload-00 |
---|
5121 | |
---|
5122 | Closed issues: |
---|
5123 | |
---|
5124 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/8>: "Media Type |
---|
5125 | Registrations" (<http://purl.org/NET/http-errata#media-reg>) |
---|
5126 | |
---|
5127 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/14>: "Clarification |
---|
5128 | regarding quoting of charset values" |
---|
5129 | (<http://purl.org/NET/http-errata#charactersets>) |
---|
5130 | |
---|
5131 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/16>: "Remove |
---|
5132 | 'identity' token references" |
---|
5133 | (<http://purl.org/NET/http-errata#identity>) |
---|
5134 | |
---|
5135 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/25>: "Accept- |
---|
5136 | Encoding BNF" |
---|
5137 | |
---|
5138 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and |
---|
5139 | Informative references" |
---|
5140 | |
---|
5141 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/46>: "RFC1700 |
---|
5142 | references" |
---|
5143 | |
---|
5144 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/55>: "Updating to |
---|
5145 | RFC4288" |
---|
5146 | |
---|
5147 | |
---|
5148 | |
---|
5149 | |
---|
5150 | |
---|
5151 | Fielding & Reschke Expires April 7, 2013 [Page 92] |
---|
5152 | |
---|
5153 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
5154 | |
---|
5155 | |
---|
5156 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/65>: "Informative |
---|
5157 | references" |
---|
5158 | |
---|
5159 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/66>: "ISO-8859-1 |
---|
5160 | Reference" |
---|
5161 | |
---|
5162 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/68>: "Encoding |
---|
5163 | References Normative" |
---|
5164 | |
---|
5165 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/86>: "Normative up- |
---|
5166 | to-date references" |
---|
5167 | |
---|
5168 | F.4. Since draft-ietf-httpbis-p2-semantics-01 |
---|
5169 | |
---|
5170 | Closed issues: |
---|
5171 | |
---|
5172 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/21>: "PUT side |
---|
5173 | effects" |
---|
5174 | |
---|
5175 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/91>: "Duplicate Host |
---|
5176 | header requirements" |
---|
5177 | |
---|
5178 | Ongoing work on ABNF conversion |
---|
5179 | (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |
---|
5180 | |
---|
5181 | o Move "Product Tokens" section (back) into Part 1, as "token" is |
---|
5182 | used in the definition of the Upgrade header field. |
---|
5183 | |
---|
5184 | o Add explicit references to BNF syntax and rules imported from |
---|
5185 | other parts of the specification. |
---|
5186 | |
---|
5187 | o Copy definition of delta-seconds from Part6 instead of referencing |
---|
5188 | it. |
---|
5189 | |
---|
5190 | F.5. Since draft-ietf-httpbis-p3-payload-01 |
---|
5191 | |
---|
5192 | Ongoing work on ABNF conversion |
---|
5193 | (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |
---|
5194 | |
---|
5195 | o Add explicit references to BNF syntax and rules imported from |
---|
5196 | other parts of the specification. |
---|
5197 | |
---|
5198 | F.6. Since draft-ietf-httpbis-p2-semantics-02 |
---|
5199 | |
---|
5200 | Closed issues: |
---|
5201 | |
---|
5202 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/24>: "Requiring |
---|
5203 | Allow in 405 responses" |
---|
5204 | |
---|
5205 | |
---|
5206 | |
---|
5207 | Fielding & Reschke Expires April 7, 2013 [Page 93] |
---|
5208 | |
---|
5209 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
5210 | |
---|
5211 | |
---|
5212 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/59>: "Status Code |
---|
5213 | Registry" |
---|
5214 | |
---|
5215 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/61>: "Redirection |
---|
5216 | vs. Location" |
---|
5217 | |
---|
5218 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/70>: "Cacheability |
---|
5219 | of 303 response" |
---|
5220 | |
---|
5221 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/76>: "305 Use Proxy" |
---|
5222 | |
---|
5223 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/105>: |
---|
5224 | "Classification for Allow header field" |
---|
5225 | |
---|
5226 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/112>: "PUT - 'store |
---|
5227 | under' vs 'store at'" |
---|
5228 | |
---|
5229 | Ongoing work on IANA Message Header Field Registration |
---|
5230 | (<http://tools.ietf.org/wg/httpbis/trac/ticket/40>): |
---|
5231 | |
---|
5232 | o Reference RFC 3984, and update header field registrations for |
---|
5233 | header fields defined in this document. |
---|
5234 | |
---|
5235 | Ongoing work on ABNF conversion |
---|
5236 | (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |
---|
5237 | |
---|
5238 | o Replace string literals when the string really is case-sensitive |
---|
5239 | (method). |
---|
5240 | |
---|
5241 | F.7. Since draft-ietf-httpbis-p3-payload-02 |
---|
5242 | |
---|
5243 | Closed issues: |
---|
5244 | |
---|
5245 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/67>: "Quoting |
---|
5246 | Charsets" |
---|
5247 | |
---|
5248 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/105>: |
---|
5249 | "Classification for Allow header field" |
---|
5250 | |
---|
5251 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/115>: "missing |
---|
5252 | default for qvalue in description of Accept-Encoding" |
---|
5253 | |
---|
5254 | Ongoing work on IANA Message Header Field Registration |
---|
5255 | (<http://tools.ietf.org/wg/httpbis/trac/ticket/40>): |
---|
5256 | |
---|
5257 | o Reference RFC 3984, and update header field registrations for |
---|
5258 | header fields defined in this document. |
---|
5259 | |
---|
5260 | |
---|
5261 | |
---|
5262 | |
---|
5263 | Fielding & Reschke Expires April 7, 2013 [Page 94] |
---|
5264 | |
---|
5265 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
5266 | |
---|
5267 | |
---|
5268 | F.8. Since draft-ietf-httpbis-p2-semantics-03 |
---|
5269 | |
---|
5270 | Closed issues: |
---|
5271 | |
---|
5272 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/98>: "OPTIONS |
---|
5273 | payload bodies" |
---|
5274 | |
---|
5275 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/119>: "Description |
---|
5276 | of CONNECT should refer to RFC2817" |
---|
5277 | |
---|
5278 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/125>: "Location |
---|
5279 | Content-Location reference request/response mixup" |
---|
5280 | |
---|
5281 | Ongoing work on Method Registry |
---|
5282 | (<http://tools.ietf.org/wg/httpbis/trac/ticket/72>): |
---|
5283 | |
---|
5284 | o Added initial proposal for registration process, plus initial |
---|
5285 | content (non-HTTP/1.1 methods to be added by a separate |
---|
5286 | specification). |
---|
5287 | |
---|
5288 | F.9. Since draft-ietf-httpbis-p3-payload-03 |
---|
5289 | |
---|
5290 | Closed issues: |
---|
5291 | |
---|
5292 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/67>: "Quoting |
---|
5293 | Charsets" |
---|
5294 | |
---|
5295 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/113>: "language tag |
---|
5296 | matching (Accept-Language) vs RFC4647" |
---|
5297 | |
---|
5298 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/121>: "RFC 1806 has |
---|
5299 | been replaced by RFC2183" |
---|
5300 | |
---|
5301 | Other changes: |
---|
5302 | |
---|
5303 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/68>: "Encoding |
---|
5304 | References Normative" -- rephrase the annotation and reference |
---|
5305 | BCP97. |
---|
5306 | |
---|
5307 | F.10. Since draft-ietf-httpbis-p2-semantics-04 |
---|
5308 | |
---|
5309 | Closed issues: |
---|
5310 | |
---|
5311 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/103>: "Content-*" |
---|
5312 | |
---|
5313 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/132>: "RFC 2822 is |
---|
5314 | updated by RFC 5322" |
---|
5315 | |
---|
5316 | |
---|
5317 | |
---|
5318 | |
---|
5319 | Fielding & Reschke Expires April 7, 2013 [Page 95] |
---|
5320 | |
---|
5321 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
5322 | |
---|
5323 | |
---|
5324 | Ongoing work on ABNF conversion |
---|
5325 | (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |
---|
5326 | |
---|
5327 | o Use "/" instead of "|" for alternatives. |
---|
5328 | |
---|
5329 | o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional |
---|
5330 | whitespace ("OWS") and required whitespace ("RWS"). |
---|
5331 | |
---|
5332 | o Rewrite ABNFs to spell out whitespace rules, factor out header |
---|
5333 | field value format definitions. |
---|
5334 | |
---|
5335 | F.11. Since draft-ietf-httpbis-p3-payload-04 |
---|
5336 | |
---|
5337 | Closed issues: |
---|
5338 | |
---|
5339 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/132>: "RFC 2822 is |
---|
5340 | updated by RFC 5322" |
---|
5341 | |
---|
5342 | Ongoing work on ABNF conversion |
---|
5343 | (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |
---|
5344 | |
---|
5345 | o Use "/" instead of "|" for alternatives. |
---|
5346 | |
---|
5347 | o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional |
---|
5348 | whitespace ("OWS") and required whitespace ("RWS"). |
---|
5349 | |
---|
5350 | o Rewrite ABNFs to spell out whitespace rules, factor out header |
---|
5351 | field value format definitions. |
---|
5352 | |
---|
5353 | F.12. Since draft-ietf-httpbis-p2-semantics-05 |
---|
5354 | |
---|
5355 | Closed issues: |
---|
5356 | |
---|
5357 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/94>: "reason-phrase |
---|
5358 | BNF" |
---|
5359 | |
---|
5360 | Final work on ABNF conversion |
---|
5361 | (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |
---|
5362 | |
---|
5363 | o Add appendix containing collected and expanded ABNF, reorganize |
---|
5364 | ABNF introduction. |
---|
5365 | |
---|
5366 | F.13. Since draft-ietf-httpbis-p3-payload-05 |
---|
5367 | |
---|
5368 | Closed issues: |
---|
5369 | |
---|
5370 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/118>: "Join |
---|
5371 | "Differences Between HTTP Entities and RFC 2045 Entities"?" |
---|
5372 | |
---|
5373 | |
---|
5374 | |
---|
5375 | Fielding & Reschke Expires April 7, 2013 [Page 96] |
---|
5376 | |
---|
5377 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
5378 | |
---|
5379 | |
---|
5380 | Final work on ABNF conversion |
---|
5381 | (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |
---|
5382 | |
---|
5383 | o Add appendix containing collected and expanded ABNF, reorganize |
---|
5384 | ABNF introduction. |
---|
5385 | |
---|
5386 | Other changes: |
---|
5387 | |
---|
5388 | o Move definition of quality values into Part 1. |
---|
5389 | |
---|
5390 | F.14. Since draft-ietf-httpbis-p2-semantics-06 |
---|
5391 | |
---|
5392 | Closed issues: |
---|
5393 | |
---|
5394 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/144>: "Clarify when |
---|
5395 | Referer is sent" |
---|
5396 | |
---|
5397 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/164>: "status codes |
---|
5398 | vs methods" |
---|
5399 | |
---|
5400 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/170>: "Do not |
---|
5401 | require "updates" relation for specs that register status codes or |
---|
5402 | method names" |
---|
5403 | |
---|
5404 | F.15. Since draft-ietf-httpbis-p3-payload-06 |
---|
5405 | |
---|
5406 | Closed issues: |
---|
5407 | |
---|
5408 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/80>: "Content- |
---|
5409 | Location isn't special" |
---|
5410 | |
---|
5411 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/155>: "Content |
---|
5412 | Sniffing" |
---|
5413 | |
---|
5414 | F.16. Since draft-ietf-httpbis-p2-semantics-07 |
---|
5415 | |
---|
5416 | Closed issues: |
---|
5417 | |
---|
5418 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/27>: "Idempotency" |
---|
5419 | |
---|
5420 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/33>: "TRACE security |
---|
5421 | considerations" |
---|
5422 | |
---|
5423 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/110>: "Clarify rules |
---|
5424 | for determining what entities a response carries" |
---|
5425 | |
---|
5426 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/140>: "update note |
---|
5427 | citing RFC 1945 and 2068" |
---|
5428 | |
---|
5429 | |
---|
5430 | |
---|
5431 | Fielding & Reschke Expires April 7, 2013 [Page 97] |
---|
5432 | |
---|
5433 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
5434 | |
---|
5435 | |
---|
5436 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/182>: "update note |
---|
5437 | about redirect limit" |
---|
5438 | |
---|
5439 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/191>: "Location |
---|
5440 | header field ABNF should use 'URI'" |
---|
5441 | |
---|
5442 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/192>: "fragments in |
---|
5443 | Location vs status 303" |
---|
5444 | |
---|
5445 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/198>: "move IANA |
---|
5446 | registrations for optional status codes" |
---|
5447 | |
---|
5448 | Partly resolved issues: |
---|
5449 | |
---|
5450 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/171>: "Are OPTIONS |
---|
5451 | and TRACE safe?" |
---|
5452 | |
---|
5453 | F.17. Since draft-ietf-httpbis-p3-payload-07 |
---|
5454 | |
---|
5455 | Closed issues: |
---|
5456 | |
---|
5457 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/13>: "Updated |
---|
5458 | reference for language tags" |
---|
5459 | |
---|
5460 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/110>: "Clarify rules |
---|
5461 | for determining what entities a response carries" |
---|
5462 | |
---|
5463 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/154>: "Content- |
---|
5464 | Location base-setting problems" |
---|
5465 | |
---|
5466 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/155>: "Content |
---|
5467 | Sniffing" |
---|
5468 | |
---|
5469 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/188>: "pick IANA |
---|
5470 | policy (RFC5226) for Transfer Coding / Content Coding" |
---|
5471 | |
---|
5472 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/189>: "move |
---|
5473 | definitions of gzip/deflate/compress to part 1" |
---|
5474 | |
---|
5475 | Partly resolved issues: |
---|
5476 | |
---|
5477 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/148>: "update IANA |
---|
5478 | requirements wrt Transfer-Coding values" (add the IANA |
---|
5479 | Considerations subsection) |
---|
5480 | |
---|
5481 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/149>: "update IANA |
---|
5482 | requirements wrt Content-Coding values" (add the IANA |
---|
5483 | Considerations subsection) |
---|
5484 | |
---|
5485 | |
---|
5486 | |
---|
5487 | Fielding & Reschke Expires April 7, 2013 [Page 98] |
---|
5488 | |
---|
5489 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
5490 | |
---|
5491 | |
---|
5492 | F.18. Since draft-ietf-httpbis-p2-semantics-08 |
---|
5493 | |
---|
5494 | Closed issues: |
---|
5495 | |
---|
5496 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/10>: "Safe Methods |
---|
5497 | vs Redirection" (we missed the introduction to the 3xx status |
---|
5498 | codes when fixing this previously) |
---|
5499 | |
---|
5500 | F.19. Since draft-ietf-httpbis-p3-payload-08 |
---|
5501 | |
---|
5502 | Closed issues: |
---|
5503 | |
---|
5504 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/81>: "Content |
---|
5505 | Negotiation for media types" |
---|
5506 | |
---|
5507 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/181>: "Accept- |
---|
5508 | Language: which RFC4647 filtering?" |
---|
5509 | |
---|
5510 | F.20. Since draft-ietf-httpbis-p2-semantics-09 |
---|
5511 | |
---|
5512 | Closed issues: |
---|
5513 | |
---|
5514 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/43>: "Fragment |
---|
5515 | combination / precedence during redirects" |
---|
5516 | |
---|
5517 | Partly resolved issues: |
---|
5518 | |
---|
5519 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/185>: "Location |
---|
5520 | header field payload handling" |
---|
5521 | |
---|
5522 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/196>: "Term for the |
---|
5523 | requested resource's URI" |
---|
5524 | |
---|
5525 | F.21. Since draft-ietf-httpbis-p3-payload-09 |
---|
5526 | |
---|
5527 | Closed issues: |
---|
5528 | |
---|
5529 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/122>: "MIME-Version |
---|
5530 | not listed in P1, general header fields" |
---|
5531 | |
---|
5532 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/143>: "IANA registry |
---|
5533 | for content/transfer encodings" |
---|
5534 | |
---|
5535 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/155>: "Content |
---|
5536 | Sniffing" |
---|
5537 | |
---|
5538 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/200>: "use of term |
---|
5539 | "word" when talking about header field structure" |
---|
5540 | |
---|
5541 | |
---|
5542 | |
---|
5543 | Fielding & Reschke Expires April 7, 2013 [Page 99] |
---|
5544 | |
---|
5545 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
5546 | |
---|
5547 | |
---|
5548 | Partly resolved issues: |
---|
5549 | |
---|
5550 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/196>: "Term for the |
---|
5551 | requested resource's URI" |
---|
5552 | |
---|
5553 | F.22. Since draft-ietf-httpbis-p2-semantics-10 |
---|
5554 | |
---|
5555 | Closed issues: |
---|
5556 | |
---|
5557 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/69>: "Clarify |
---|
5558 | 'Requested Variant'" |
---|
5559 | |
---|
5560 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/109>: "Clarify |
---|
5561 | entity / representation / variant terminology" |
---|
5562 | |
---|
5563 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/139>: "Methods and |
---|
5564 | Caching" |
---|
5565 | |
---|
5566 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/190>: "OPTIONS vs |
---|
5567 | Max-Forwards" |
---|
5568 | |
---|
5569 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/199>: "Status codes |
---|
5570 | and caching" |
---|
5571 | |
---|
5572 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/220>: "consider |
---|
5573 | removing the 'changes from 2068' sections" |
---|
5574 | |
---|
5575 | F.23. Since draft-ietf-httpbis-p3-payload-10 |
---|
5576 | |
---|
5577 | Closed issues: |
---|
5578 | |
---|
5579 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/69>: "Clarify |
---|
5580 | 'Requested Variant'" |
---|
5581 | |
---|
5582 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/80>: "Content- |
---|
5583 | Location isn't special" |
---|
5584 | |
---|
5585 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/90>: "Delimiting |
---|
5586 | messages with multipart/byteranges" |
---|
5587 | |
---|
5588 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/109>: "Clarify |
---|
5589 | entity / representation / variant terminology" |
---|
5590 | |
---|
5591 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/136>: "confusing |
---|
5592 | req. language for Content-Location" |
---|
5593 | |
---|
5594 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/167>: "Content- |
---|
5595 | Location on 304 responses" |
---|
5596 | |
---|
5597 | |
---|
5598 | |
---|
5599 | Fielding & Reschke Expires April 7, 2013 [Page 100] |
---|
5600 | |
---|
5601 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
5602 | |
---|
5603 | |
---|
5604 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/183>: "'requested |
---|
5605 | resource' in content-encoding definition" |
---|
5606 | |
---|
5607 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/220>: "consider |
---|
5608 | removing the 'changes from 2068' sections" |
---|
5609 | |
---|
5610 | Partly resolved issues: |
---|
5611 | |
---|
5612 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/178>: "Content-MD5 |
---|
5613 | and partial responses" |
---|
5614 | |
---|
5615 | F.24. Since draft-ietf-httpbis-p2-semantics-11 |
---|
5616 | |
---|
5617 | Closed issues: |
---|
5618 | |
---|
5619 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/229>: |
---|
5620 | "Considerations for new status codes" |
---|
5621 | |
---|
5622 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/230>: |
---|
5623 | "Considerations for new methods" |
---|
5624 | |
---|
5625 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/232>: "User-Agent |
---|
5626 | guidelines" (relating to the 'User-Agent' header field) |
---|
5627 | |
---|
5628 | F.25. Since draft-ietf-httpbis-p3-payload-11 |
---|
5629 | |
---|
5630 | Closed issues: |
---|
5631 | |
---|
5632 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/123>: "Factor out |
---|
5633 | Content-Disposition" |
---|
5634 | |
---|
5635 | F.26. Since draft-ietf-httpbis-p2-semantics-12 |
---|
5636 | |
---|
5637 | Closed issues: |
---|
5638 | |
---|
5639 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/43>: "Fragment |
---|
5640 | combination / precedence during redirects" (added warning about |
---|
5641 | having a fragid on the redirect might cause inconvenience in some |
---|
5642 | cases) |
---|
5643 | |
---|
5644 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/79>: "Content-* vs. |
---|
5645 | PUT" |
---|
5646 | |
---|
5647 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/88>: "205 Bodies" |
---|
5648 | |
---|
5649 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/102>: "Understanding |
---|
5650 | Content-* on non-PUT requests" |
---|
5651 | |
---|
5652 | |
---|
5653 | |
---|
5654 | |
---|
5655 | Fielding & Reschke Expires April 7, 2013 [Page 101] |
---|
5656 | |
---|
5657 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
5658 | |
---|
5659 | |
---|
5660 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/103>: "Content-*" |
---|
5661 | |
---|
5662 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/104>: "Header field |
---|
5663 | type defaulting" |
---|
5664 | |
---|
5665 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/112>: "PUT - 'store |
---|
5666 | under' vs 'store at'" |
---|
5667 | |
---|
5668 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/137>: "duplicate |
---|
5669 | ABNF for reason-phrase" |
---|
5670 | |
---|
5671 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/180>: "Note special |
---|
5672 | status of Content-* prefix in header field registration |
---|
5673 | procedures" |
---|
5674 | |
---|
5675 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/203>: "Max-Forwards |
---|
5676 | vs extension methods" |
---|
5677 | |
---|
5678 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/213>: "What is the |
---|
5679 | value space of HTTP status codes?" (actually fixed in |
---|
5680 | draft-ietf-httpbis-p2-semantics-11) |
---|
5681 | |
---|
5682 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/224>: "Header Field |
---|
5683 | Classification" |
---|
5684 | |
---|
5685 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/225>: "PUT side |
---|
5686 | effect: invalidation or just stale?" |
---|
5687 | |
---|
5688 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/226>: "proxies not |
---|
5689 | supporting certain methods" |
---|
5690 | |
---|
5691 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/239>: "Migrate |
---|
5692 | CONNECT from RFC2817 to p2" |
---|
5693 | |
---|
5694 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/240>: "Migrate |
---|
5695 | Upgrade details from RFC2817" |
---|
5696 | |
---|
5697 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/267>: "clarify PUT |
---|
5698 | semantics'" |
---|
5699 | |
---|
5700 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/275>: "duplicate |
---|
5701 | ABNF for 'Method'" |
---|
5702 | |
---|
5703 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle |
---|
5704 | ABNFs for header fields" |
---|
5705 | |
---|
5706 | |
---|
5707 | |
---|
5708 | |
---|
5709 | |
---|
5710 | |
---|
5711 | Fielding & Reschke Expires April 7, 2013 [Page 102] |
---|
5712 | |
---|
5713 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
5714 | |
---|
5715 | |
---|
5716 | F.27. Since draft-ietf-httpbis-p3-payload-12 |
---|
5717 | |
---|
5718 | Closed issues: |
---|
5719 | |
---|
5720 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/224>: "Header Field |
---|
5721 | Classification" |
---|
5722 | |
---|
5723 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle |
---|
5724 | ABNFs for header fields" |
---|
5725 | |
---|
5726 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/277>: "potentially |
---|
5727 | misleading MAY in media-type def" |
---|
5728 | |
---|
5729 | F.28. Since draft-ietf-httpbis-p2-semantics-13 |
---|
5730 | |
---|
5731 | Closed issues: |
---|
5732 | |
---|
5733 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle |
---|
5734 | ABNFs for header fields" |
---|
5735 | |
---|
5736 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/251>: "message body |
---|
5737 | in CONNECT request" |
---|
5738 | |
---|
5739 | F.29. Since draft-ietf-httpbis-p3-payload-13 |
---|
5740 | |
---|
5741 | Closed issues: |
---|
5742 | |
---|
5743 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/20>: "Default |
---|
5744 | charsets for text media types" |
---|
5745 | |
---|
5746 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/178>: "Content-MD5 |
---|
5747 | and partial responses" |
---|
5748 | |
---|
5749 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle |
---|
5750 | ABNFs for header fields" |
---|
5751 | |
---|
5752 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/281>: "confusing |
---|
5753 | undefined parameter in media range example" |
---|
5754 | |
---|
5755 | F.30. Since draft-ietf-httpbis-p2-semantics-14 |
---|
5756 | |
---|
5757 | Closed issues: |
---|
5758 | |
---|
5759 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/255>: "Clarify |
---|
5760 | status code for rate limiting" |
---|
5761 | |
---|
5762 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/294>: "clarify 403 |
---|
5763 | forbidden" |
---|
5764 | |
---|
5765 | |
---|
5766 | |
---|
5767 | Fielding & Reschke Expires April 7, 2013 [Page 103] |
---|
5768 | |
---|
5769 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
5770 | |
---|
5771 | |
---|
5772 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/296>: "Clarify 203 |
---|
5773 | Non-Authoritative Information" |
---|
5774 | |
---|
5775 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/298>: "update |
---|
5776 | default reason phrase for 413" |
---|
5777 | |
---|
5778 | F.31. Since draft-ietf-httpbis-p3-payload-14 |
---|
5779 | |
---|
5780 | None. |
---|
5781 | |
---|
5782 | F.32. Since draft-ietf-httpbis-p2-semantics-15 |
---|
5783 | |
---|
5784 | Closed issues: |
---|
5785 | |
---|
5786 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/285>: "Strength of |
---|
5787 | requirements on Accept re: 406" |
---|
5788 | |
---|
5789 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/303>: "400 response |
---|
5790 | isn't generic" |
---|
5791 | |
---|
5792 | F.33. Since draft-ietf-httpbis-p3-payload-15 |
---|
5793 | |
---|
5794 | Closed issues: |
---|
5795 | |
---|
5796 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/285>: "Strength of |
---|
5797 | requirements on Accept re: 406" |
---|
5798 | |
---|
5799 | F.34. Since draft-ietf-httpbis-p2-semantics-16 |
---|
5800 | |
---|
5801 | Closed issues: |
---|
5802 | |
---|
5803 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/160>: "Redirects and |
---|
5804 | non-GET methods" |
---|
5805 | |
---|
5806 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/186>: "Document |
---|
5807 | HTTP's error-handling philosophy" |
---|
5808 | |
---|
5809 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/231>: |
---|
5810 | "Considerations for new header fields" |
---|
5811 | |
---|
5812 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/310>: "clarify 303 |
---|
5813 | redirect on HEAD" |
---|
5814 | |
---|
5815 | F.35. Since draft-ietf-httpbis-p3-payload-16 |
---|
5816 | |
---|
5817 | Closed issues: |
---|
5818 | |
---|
5819 | |
---|
5820 | |
---|
5821 | |
---|
5822 | |
---|
5823 | Fielding & Reschke Expires April 7, 2013 [Page 104] |
---|
5824 | |
---|
5825 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
5826 | |
---|
5827 | |
---|
5828 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/186>: "Document |
---|
5829 | HTTP's error-handling philosophy" |
---|
5830 | |
---|
5831 | F.36. Since draft-ietf-httpbis-p2-semantics-17 |
---|
5832 | |
---|
5833 | Closed issues: |
---|
5834 | |
---|
5835 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/185>: "Location |
---|
5836 | header field payload handling" |
---|
5837 | |
---|
5838 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/255>: "Clarify |
---|
5839 | status code for rate limiting" (change backed out because a new |
---|
5840 | status code is being defined for this purpose) |
---|
5841 | |
---|
5842 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/312>: "should there |
---|
5843 | be a permanent variant of 307" |
---|
5844 | |
---|
5845 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/325>: "When are |
---|
5846 | Location's semantics triggered?" |
---|
5847 | |
---|
5848 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/327>: "'expect' |
---|
5849 | grammar missing OWS" |
---|
5850 | |
---|
5851 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/329>: "header field |
---|
5852 | considerations: quoted-string vs use of double quotes" |
---|
5853 | |
---|
5854 | F.37. Since draft-ietf-httpbis-p3-payload-17 |
---|
5855 | |
---|
5856 | Closed issues: |
---|
5857 | |
---|
5858 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/323>: "intended |
---|
5859 | maturity level vs normative references" |
---|
5860 | |
---|
5861 | F.38. Since draft-ietf-httpbis-p2-semantics-18 |
---|
5862 | |
---|
5863 | Closed issues: |
---|
5864 | |
---|
5865 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/227>: "Combining |
---|
5866 | HEAD responses" |
---|
5867 | |
---|
5868 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/238>: "Requirements |
---|
5869 | for user intervention during redirects" |
---|
5870 | |
---|
5871 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/250>: "message-body |
---|
5872 | in CONNECT response" |
---|
5873 | |
---|
5874 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/295>: "Applying |
---|
5875 | original fragment to 'plain' redirected URI" |
---|
5876 | |
---|
5877 | |
---|
5878 | |
---|
5879 | Fielding & Reschke Expires April 7, 2013 [Page 105] |
---|
5880 | |
---|
5881 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
5882 | |
---|
5883 | |
---|
5884 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/302>: "Misplaced |
---|
5885 | text on connection handling in p2" |
---|
5886 | |
---|
5887 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/331>: "clarify that |
---|
5888 | 201 doesn't require Location header fields" |
---|
5889 | |
---|
5890 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/332>: "relax |
---|
5891 | requirements on hypertext in 3/4/5xx error responses" |
---|
5892 | |
---|
5893 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/333>: "example for |
---|
5894 | 426 response should have a payload" |
---|
5895 | |
---|
5896 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/336>: "drop |
---|
5897 | indirection entries for status codes" |
---|
5898 | |
---|
5899 | F.39. Since draft-ietf-httpbis-p3-payload-18 |
---|
5900 | |
---|
5901 | Closed issues: |
---|
5902 | |
---|
5903 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/330>: "is ETag a |
---|
5904 | representation header field?" |
---|
5905 | |
---|
5906 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/338>: "Content- |
---|
5907 | Location doesn't constrain the cardinality of representations" |
---|
5908 | |
---|
5909 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/346>: "make IANA |
---|
5910 | policy definitions consistent" |
---|
5911 | |
---|
5912 | F.40. Since draft-ietf-httpbis-p2-semantics-19 and |
---|
5913 | draft-ietf-httpbis-p3-payload-19 |
---|
5914 | |
---|
5915 | Closed issues: |
---|
5916 | |
---|
5917 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/312>: "should there |
---|
5918 | be a permanent variant of 307" |
---|
5919 | |
---|
5920 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/347>: "clarify that |
---|
5921 | 201 can imply *multiple* resources were created" |
---|
5922 | |
---|
5923 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/351>: "merge P2 and |
---|
5924 | P3" |
---|
5925 | |
---|
5926 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/361>: "ABNF |
---|
5927 | requirements for recipients" |
---|
5928 | |
---|
5929 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/364>: "Capturing |
---|
5930 | more information in the method registry" |
---|
5931 | |
---|
5932 | |
---|
5933 | |
---|
5934 | |
---|
5935 | Fielding & Reschke Expires April 7, 2013 [Page 106] |
---|
5936 | |
---|
5937 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
5938 | |
---|
5939 | |
---|
5940 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/368>: "note |
---|
5941 | introduction of new IANA registries as normative changes" |
---|
5942 | |
---|
5943 | F.41. Since draft-ietf-httpbis-p2-semantics-20 |
---|
5944 | |
---|
5945 | Closed issues: |
---|
5946 | |
---|
5947 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/378>: "is 'q=' case- |
---|
5948 | sensitive?" |
---|
5949 | |
---|
5950 | Other changes: |
---|
5951 | |
---|
5952 | o Conformance criteria and considerations regarding error handling |
---|
5953 | are now defined in Part 1. |
---|
5954 | |
---|
5955 | o Properly explain what HTTP semantics are and why. Rewrite |
---|
5956 | introductory description of methods. Rewrite definition of "safe" |
---|
5957 | to be more operable and weaken the original same-origin |
---|
5958 | restrictions to be more consistent with modern UAs. Rewrite |
---|
5959 | definition of "idempotent", add definition of "cacheable". |
---|
5960 | |
---|
5961 | o Conneg terminology change: "server-driven" => "proactive" (UA |
---|
5962 | sends Accept* fields), "agent-driven" => "reactive" (UA waits for |
---|
5963 | 300/Alternatives) |
---|
5964 | |
---|
5965 | o Move description of "100-continue" from Part 1 over here. |
---|
5966 | |
---|
5967 | o Move definition of "Vary" header field from Part 6 over here. |
---|
5968 | |
---|
5969 | o Rewrite definition of "representation". |
---|
5970 | |
---|
5971 | Index |
---|
5972 | |
---|
5973 | 1 |
---|
5974 | 1xx Informational (status code class) 49 |
---|
5975 | |
---|
5976 | 2 |
---|
5977 | 2xx Successful (status code class) 50 |
---|
5978 | |
---|
5979 | 3 |
---|
5980 | 3xx Redirection (status code class) 52 |
---|
5981 | |
---|
5982 | 4 |
---|
5983 | 4xx Client Error (status code class) 56 |
---|
5984 | |
---|
5985 | 5 |
---|
5986 | 5xx Server Error (status code class) 60 |
---|
5987 | |
---|
5988 | |
---|
5989 | |
---|
5990 | |
---|
5991 | Fielding & Reschke Expires April 7, 2013 [Page 107] |
---|
5992 | |
---|
5993 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
5994 | |
---|
5995 | |
---|
5996 | 1 |
---|
5997 | 100 Continue (status code) 49 |
---|
5998 | 100-continue (expect value) 35 |
---|
5999 | 101 Switching Protocols (status code) 49 |
---|
6000 | |
---|
6001 | 2 |
---|
6002 | 200 OK (status code) 50 |
---|
6003 | 201 Created (status code) 50 |
---|
6004 | 202 Accepted (status code) 51 |
---|
6005 | 203 Non-Authoritative Information (status code) 51 |
---|
6006 | 204 No Content (status code) 51 |
---|
6007 | 205 Reset Content (status code) 52 |
---|
6008 | |
---|
6009 | 3 |
---|
6010 | 300 Multiple Choices (status code) 54 |
---|
6011 | 301 Moved Permanently (status code) 54 |
---|
6012 | 302 Found (status code) 55 |
---|
6013 | 303 See Other (status code) 55 |
---|
6014 | 305 Use Proxy (status code) 56 |
---|
6015 | 306 (Unused) (status code) 56 |
---|
6016 | 307 Temporary Redirect (status code) 56 |
---|
6017 | |
---|
6018 | 4 |
---|
6019 | 400 Bad Request (status code) 56 |
---|
6020 | 402 Payment Required (status code) 56 |
---|
6021 | 403 Forbidden (status code) 57 |
---|
6022 | 404 Not Found (status code) 57 |
---|
6023 | 405 Method Not Allowed (status code) 57 |
---|
6024 | 406 Not Acceptable (status code) 57 |
---|
6025 | 408 Request Timeout (status code) 58 |
---|
6026 | 409 Conflict (status code) 58 |
---|
6027 | 410 Gone (status code) 58 |
---|
6028 | 411 Length Required (status code) 59 |
---|
6029 | 413 Request Representation Too Large (status code) 59 |
---|
6030 | 414 URI Too Long (status code) 59 |
---|
6031 | 415 Unsupported Media Type (status code) 59 |
---|
6032 | 417 Expectation Failed (status code) 60 |
---|
6033 | 426 Upgrade Required (status code) 60 |
---|
6034 | |
---|
6035 | 5 |
---|
6036 | 500 Internal Server Error (status code) 60 |
---|
6037 | 501 Not Implemented (status code) 60 |
---|
6038 | 502 Bad Gateway (status code) 61 |
---|
6039 | 503 Service Unavailable (status code) 61 |
---|
6040 | 504 Gateway Timeout (status code) 61 |
---|
6041 | 505 HTTP Version Not Supported (status code) 61 |
---|
6042 | |
---|
6043 | A |
---|
6044 | |
---|
6045 | |
---|
6046 | |
---|
6047 | Fielding & Reschke Expires April 7, 2013 [Page 108] |
---|
6048 | |
---|
6049 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
6050 | |
---|
6051 | |
---|
6052 | Accept header field 38 |
---|
6053 | Accept-Charset header field 41 |
---|
6054 | Accept-Encoding header field 41 |
---|
6055 | Accept-Language header field 42 |
---|
6056 | Allow header field 69 |
---|
6057 | |
---|
6058 | C |
---|
6059 | cacheable 25 |
---|
6060 | compress (content coding) 12 |
---|
6061 | CONNECT method 30 |
---|
6062 | content coding 12 |
---|
6063 | content negotiation 7 |
---|
6064 | Content-Encoding header field 12 |
---|
6065 | Content-Language header field 14 |
---|
6066 | Content-Location header field 16 |
---|
6067 | Content-Transfer-Encoding header field 85 |
---|
6068 | Content-Type header field 11 |
---|
6069 | |
---|
6070 | D |
---|
6071 | Date header field 64 |
---|
6072 | deflate (content coding) 12 |
---|
6073 | DELETE method 30 |
---|
6074 | |
---|
6075 | E |
---|
6076 | Expect header field 34 |
---|
6077 | Expect Values |
---|
6078 | 100-continue 35 |
---|
6079 | |
---|
6080 | F |
---|
6081 | From header field 44 |
---|
6082 | |
---|
6083 | G |
---|
6084 | GET method 25 |
---|
6085 | Grammar |
---|
6086 | Accept 39 |
---|
6087 | Accept-Charset 41 |
---|
6088 | Accept-Encoding 41 |
---|
6089 | accept-ext 39 |
---|
6090 | Accept-Language 43 |
---|
6091 | accept-params 39 |
---|
6092 | Allow 69 |
---|
6093 | asctime-date 64 |
---|
6094 | attribute 9 |
---|
6095 | charset 10 |
---|
6096 | codings 41 |
---|
6097 | content-coding 12 |
---|
6098 | Content-Encoding 13 |
---|
6099 | Content-Language 14 |
---|
6100 | |
---|
6101 | |
---|
6102 | |
---|
6103 | Fielding & Reschke Expires April 7, 2013 [Page 109] |
---|
6104 | |
---|
6105 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
6106 | |
---|
6107 | |
---|
6108 | Content-Location 16 |
---|
6109 | Content-Type 11 |
---|
6110 | Date 64 |
---|
6111 | date1 63 |
---|
6112 | day 63 |
---|
6113 | day-name 63 |
---|
6114 | day-name-l 63 |
---|
6115 | delta-seconds 66 |
---|
6116 | Expect 34 |
---|
6117 | expect-name 34 |
---|
6118 | expect-param 34 |
---|
6119 | expect-value 34 |
---|
6120 | expectation 34 |
---|
6121 | From 44 |
---|
6122 | GMT 63 |
---|
6123 | hour 63 |
---|
6124 | HTTP-date 62 |
---|
6125 | language-range 43 |
---|
6126 | language-tag 14 |
---|
6127 | Location 65 |
---|
6128 | Max-Forwards 34 |
---|
6129 | media-range 39 |
---|
6130 | media-type 9 |
---|
6131 | method 22 |
---|
6132 | MIME-Version 84 |
---|
6133 | minute 63 |
---|
6134 | month 63 |
---|
6135 | obs-date 63 |
---|
6136 | parameter 9 |
---|
6137 | product 22 |
---|
6138 | product-version 22 |
---|
6139 | qvalue 38 |
---|
6140 | Referer 45 |
---|
6141 | Retry-After 66 |
---|
6142 | rfc850-date 64 |
---|
6143 | rfc1123-date 63 |
---|
6144 | second 63 |
---|
6145 | Server 69 |
---|
6146 | subtype 9 |
---|
6147 | time-of-day 63 |
---|
6148 | type 9 |
---|
6149 | User-Agent 46 |
---|
6150 | value 9 |
---|
6151 | Vary 67 |
---|
6152 | weight 38 |
---|
6153 | year 63 |
---|
6154 | gzip (content coding) 12 |
---|
6155 | |
---|
6156 | |
---|
6157 | |
---|
6158 | |
---|
6159 | Fielding & Reschke Expires April 7, 2013 [Page 110] |
---|
6160 | |
---|
6161 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
6162 | |
---|
6163 | |
---|
6164 | H |
---|
6165 | HEAD method 26 |
---|
6166 | |
---|
6167 | I |
---|
6168 | idempotent 25 |
---|
6169 | |
---|
6170 | L |
---|
6171 | Location header field 65 |
---|
6172 | |
---|
6173 | M |
---|
6174 | Max-Forwards header field 34 |
---|
6175 | MIME-Version header field 84 |
---|
6176 | |
---|
6177 | O |
---|
6178 | OPTIONS method 32 |
---|
6179 | |
---|
6180 | P |
---|
6181 | payload 18 |
---|
6182 | POST method 27 |
---|
6183 | PUT method 28 |
---|
6184 | |
---|
6185 | R |
---|
6186 | Referer header field 45 |
---|
6187 | representation 8 |
---|
6188 | Retry-After header field 66 |
---|
6189 | |
---|
6190 | S |
---|
6191 | safe 24 |
---|
6192 | selected representation 67 |
---|
6193 | Server header field 69 |
---|
6194 | Status Codes Classes |
---|
6195 | 1xx Informational 49 |
---|
6196 | 2xx Successful 50 |
---|
6197 | 3xx Redirection 52 |
---|
6198 | 4xx Client Error 56 |
---|
6199 | 5xx Server Error 60 |
---|
6200 | |
---|
6201 | T |
---|
6202 | TRACE method 33 |
---|
6203 | |
---|
6204 | U |
---|
6205 | User-Agent header field 45 |
---|
6206 | |
---|
6207 | V |
---|
6208 | Vary header field 67 |
---|
6209 | |
---|
6210 | X |
---|
6211 | x-compress (content coding) 12 |
---|
6212 | |
---|
6213 | |
---|
6214 | |
---|
6215 | Fielding & Reschke Expires April 7, 2013 [Page 111] |
---|
6216 | |
---|
6217 | Internet-Draft HTTP/1.1 Semantics and Content October 2012 |
---|
6218 | |
---|
6219 | |
---|
6220 | x-gzip (content coding) 12 |
---|
6221 | |
---|
6222 | Authors' Addresses |
---|
6223 | |
---|
6224 | Roy T. Fielding (editor) |
---|
6225 | Adobe Systems Incorporated |
---|
6226 | 345 Park Ave |
---|
6227 | San Jose, CA 95110 |
---|
6228 | USA |
---|
6229 | |
---|
6230 | EMail: fielding@gbiv.com |
---|
6231 | URI: http://roy.gbiv.com/ |
---|
6232 | |
---|
6233 | |
---|
6234 | Julian F. Reschke (editor) |
---|
6235 | greenbytes GmbH |
---|
6236 | Hafenweg 16 |
---|
6237 | Muenster, NW 48155 |
---|
6238 | Germany |
---|
6239 | |
---|
6240 | EMail: julian.reschke@greenbytes.de |
---|
6241 | URI: http://greenbytes.de/tech/webdav/ |
---|
6242 | |
---|
6243 | |
---|
6244 | |
---|
6245 | |
---|
6246 | |
---|
6247 | |
---|
6248 | |
---|
6249 | |
---|
6250 | |
---|
6251 | |
---|
6252 | |
---|
6253 | |
---|
6254 | |
---|
6255 | |
---|
6256 | |
---|
6257 | |
---|
6258 | |
---|
6259 | |
---|
6260 | |
---|
6261 | |
---|
6262 | |
---|
6263 | |
---|
6264 | |
---|
6265 | |
---|
6266 | |
---|
6267 | |
---|
6268 | |
---|
6269 | |
---|
6270 | |
---|
6271 | Fielding & Reschke Expires April 7, 2013 [Page 112] |
---|
6272 | |
---|