1 | |
---|
2 | INTRODUCTION, paragraph 1: |
---|
3 | OLD: |
---|
4 | |
---|
5 | HTTPbis Working Group R. Fielding, Ed. |
---|
6 | Internet-Draft Adobe |
---|
7 | Obsoletes: 2616 (if approved) J. Reschke, Ed. |
---|
8 | Updates: 2817 (if approved) greenbytes |
---|
9 | Intended status: Standards Track May 7, 2014 |
---|
10 | Expires: November 8, 2014 |
---|
11 | |
---|
12 | NEW: |
---|
13 | |
---|
14 | Internet Engineering Task Force (IETF) R. Fielding, Ed. |
---|
15 | Request for Comments: 7231 Adobe |
---|
16 | Obsoletes: 2616 J. Reschke, Ed. |
---|
17 | Updates: 2817 greenbytes |
---|
18 | Category: Standards Track May 2014 |
---|
19 | ISSN: 2070-1721 |
---|
20 | |
---|
21 | |
---|
22 | INTRODUCTION, paragraph 2: |
---|
23 | OLD: |
---|
24 | |
---|
25 | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content |
---|
26 | draft-ietf-httpbis-p2-semantics-latest |
---|
27 | |
---|
28 | NEW: |
---|
29 | |
---|
30 | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content |
---|
31 | |
---|
32 | |
---|
33 | INTRODUCTION, paragraph 5: |
---|
34 | OLD: |
---|
35 | |
---|
36 | Editorial Note (To be removed by RFC Editor) |
---|
37 | |
---|
38 | Discussion of this draft takes place on the HTTPBIS working group |
---|
39 | mailing list (ietf-http-wg@w3.org), which is archived at |
---|
40 | <http://lists.w3.org/Archives/Public/ietf-http-wg/>. |
---|
41 | |
---|
42 | The current issues list is at |
---|
43 | <http://tools.ietf.org/wg/httpbis/trac/report/3> and related |
---|
44 | documents (including fancy diffs) can be found at |
---|
45 | <http://tools.ietf.org/wg/httpbis/>. |
---|
46 | |
---|
47 | _This is a temporary document for the purpose of tracking the |
---|
48 | editorial changes made during the AUTH48 (RFC publication) phase._ |
---|
49 | |
---|
50 | Status of This Memo |
---|
51 | |
---|
52 | NEW: |
---|
53 | |
---|
54 | Status of This Memo |
---|
55 | |
---|
56 | |
---|
57 | INTRODUCTION, paragraph 6: |
---|
58 | OLD: |
---|
59 | |
---|
60 | This Internet-Draft is submitted in full conformance with the |
---|
61 | provisions of BCP 78 and BCP 79. |
---|
62 | |
---|
63 | Internet-Drafts are working documents of the Internet Engineering |
---|
64 | Task Force (IETF). Note that other groups may also distribute |
---|
65 | working documents as Internet-Drafts. The list of current Internet- |
---|
66 | Drafts is at http://datatracker.ietf.org/drafts/current/. |
---|
67 | |
---|
68 | NEW: |
---|
69 | |
---|
70 | This is an Internet Standards Track document. |
---|
71 | |
---|
72 | |
---|
73 | INTRODUCTION, paragraph 7: |
---|
74 | OLD: |
---|
75 | |
---|
76 | Internet-Drafts are draft documents valid for a maximum of six months |
---|
77 | and may be updated, replaced, or obsoleted by other documents at any |
---|
78 | time. It is inappropriate to use Internet-Drafts as reference |
---|
79 | material or to cite them other than as "work in progress." |
---|
80 | |
---|
81 | NEW: |
---|
82 | |
---|
83 | This document is a product of the Internet Engineering Task Force |
---|
84 | (IETF). It represents the consensus of the IETF community. It has |
---|
85 | received public review and has been approved for publication by the |
---|
86 | Internet Engineering Steering Group (IESG). Further information on |
---|
87 | Internet Standards is available in Section 2 of RFC 5741. |
---|
88 | |
---|
89 | |
---|
90 | INTRODUCTION, paragraph 8: |
---|
91 | OLD: |
---|
92 | |
---|
93 | This Internet-Draft will expire on November 8, 2014. |
---|
94 | |
---|
95 | NEW: |
---|
96 | |
---|
97 | Information about the current status of this document, any errata, |
---|
98 | and how to provide feedback on it may be obtained at |
---|
99 | http://www.rfc-editor.org/info/rfc7231. |
---|
100 | |
---|
101 | |
---|
102 | Section 11., paragraph 0: |
---|
103 | OLD: |
---|
104 | |
---|
105 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 |
---|
106 | 1.1. Conformance and Error Handling . . . . . . . . . . . . . . 6 |
---|
107 | 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 |
---|
108 | 2. Resources . . . . . . . . . . . . . . . . . . . . . . . . . . 7 |
---|
109 | 3. Representations . . . . . . . . . . . . . . . . . . . . . . . 7 |
---|
110 | 3.1. Representation Metadata . . . . . . . . . . . . . . . . . 8 |
---|
111 | 3.1.1. Processing Representation Data . . . . . . . . . . . . 8 |
---|
112 | 3.1.2. Encoding for Compression or Integrity . . . . . . . . 11 |
---|
113 | 3.1.3. Audience Language . . . . . . . . . . . . . . . . . . 13 |
---|
114 | 3.1.4. Identification . . . . . . . . . . . . . . . . . . . . 14 |
---|
115 | 3.2. Representation Data . . . . . . . . . . . . . . . . . . . 17 |
---|
116 | 3.3. Payload Semantics . . . . . . . . . . . . . . . . . . . . 17 |
---|
117 | 3.4. Content Negotiation . . . . . . . . . . . . . . . . . . . 18 |
---|
118 | 3.4.1. Proactive Negotiation . . . . . . . . . . . . . . . . 19 |
---|
119 | 3.4.2. Reactive Negotiation . . . . . . . . . . . . . . . . . 20 |
---|
120 | |
---|
121 | 4. Request Methods . . . . . . . . . . . . . . . . . . . . . . . 21 |
---|
122 | 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 21 |
---|
123 | 4.2. Common Method Properties . . . . . . . . . . . . . . . . . 22 |
---|
124 | 4.2.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . 22 |
---|
125 | 4.2.2. Idempotent Methods . . . . . . . . . . . . . . . . . . 23 |
---|
126 | 4.2.3. Cacheable Methods . . . . . . . . . . . . . . . . . . 24 |
---|
127 | 4.3. Method Definitions . . . . . . . . . . . . . . . . . . . . 24 |
---|
128 | 4.3.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 24 |
---|
129 | 4.3.2. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . 25 |
---|
130 | 4.3.3. POST . . . . . . . . . . . . . . . . . . . . . . . . . 25 |
---|
131 | 4.3.4. PUT . . . . . . . . . . . . . . . . . . . . . . . . . 26 |
---|
132 | 4.3.5. DELETE . . . . . . . . . . . . . . . . . . . . . . . . 29 |
---|
133 | 4.3.6. CONNECT . . . . . . . . . . . . . . . . . . . . . . . 30 |
---|
134 | 4.3.7. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . 31 |
---|
135 | 4.3.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . 32 |
---|
136 | 5. Request Header Fields . . . . . . . . . . . . . . . . . . . . 33 |
---|
137 | 5.1. Controls . . . . . . . . . . . . . . . . . . . . . . . . . 33 |
---|
138 | 5.1.1. Expect . . . . . . . . . . . . . . . . . . . . . . . . 34 |
---|
139 | 5.1.2. Max-Forwards . . . . . . . . . . . . . . . . . . . . . 36 |
---|
140 | 5.2. Conditionals . . . . . . . . . . . . . . . . . . . . . . . 36 |
---|
141 | 5.3. Content Negotiation . . . . . . . . . . . . . . . . . . . 37 |
---|
142 | 5.3.1. Quality Values . . . . . . . . . . . . . . . . . . . . 37 |
---|
143 | 5.3.2. Accept . . . . . . . . . . . . . . . . . . . . . . . . 38 |
---|
144 | 5.3.3. Accept-Charset . . . . . . . . . . . . . . . . . . . . 40 |
---|
145 | 5.3.4. Accept-Encoding . . . . . . . . . . . . . . . . . . . 41 |
---|
146 | 5.3.5. Accept-Language . . . . . . . . . . . . . . . . . . . 42 |
---|
147 | 5.4. Authentication Credentials . . . . . . . . . . . . . . . . 43 |
---|
148 | 5.5. Request Context . . . . . . . . . . . . . . . . . . . . . 44 |
---|
149 | 5.5.1. From . . . . . . . . . . . . . . . . . . . . . . . . . 44 |
---|
150 | 5.5.2. Referer . . . . . . . . . . . . . . . . . . . . . . . 45 |
---|
151 | 5.5.3. User-Agent . . . . . . . . . . . . . . . . . . . . . . 46 |
---|
152 | 6. Response Status Codes . . . . . . . . . . . . . . . . . . . . 47 |
---|
153 | 6.1. Overview of Status Codes . . . . . . . . . . . . . . . . . 48 |
---|
154 | 6.2. Informational 1xx . . . . . . . . . . . . . . . . . . . . 50 |
---|
155 | 6.2.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 50 |
---|
156 | 6.2.2. 101 Switching Protocols . . . . . . . . . . . . . . . 50 |
---|
157 | 6.3. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 51 |
---|
158 | 6.3.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 51 |
---|
159 | 6.3.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 52 |
---|
160 | 6.3.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 52 |
---|
161 | 6.3.4. 203 Non-Authoritative Information . . . . . . . . . . 52 |
---|
162 | 6.3.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 53 |
---|
163 | 6.3.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 53 |
---|
164 | 6.4. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 54 |
---|
165 | 6.4.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 55 |
---|
166 | 6.4.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 56 |
---|
167 | 6.4.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 56 |
---|
168 | 6.4.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 57 |
---|
169 | 6.4.5. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 57 |
---|
170 | 6.4.6. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 57 |
---|
171 | 6.4.7. 307 Temporary Redirect . . . . . . . . . . . . . . . . 58 |
---|
172 | 6.5. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 58 |
---|
173 | 6.5.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 58 |
---|
174 | 6.5.2. 402 Payment Required . . . . . . . . . . . . . . . . . 58 |
---|
175 | 6.5.3. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 58 |
---|
176 | 6.5.4. 404 Not Found . . . . . . . . . . . . . . . . . . . . 59 |
---|
177 | 6.5.5. 405 Method Not Allowed . . . . . . . . . . . . . . . . 59 |
---|
178 | 6.5.6. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 59 |
---|
179 | 6.5.7. 408 Request Timeout . . . . . . . . . . . . . . . . . 60 |
---|
180 | 6.5.8. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 60 |
---|
181 | 6.5.9. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 60 |
---|
182 | 6.5.10. 411 Length Required . . . . . . . . . . . . . . . . . 61 |
---|
183 | 6.5.11. 413 Payload Too Large . . . . . . . . . . . . . . . . 61 |
---|
184 | 6.5.12. 414 URI Too Long . . . . . . . . . . . . . . . . . . . 61 |
---|
185 | 6.5.13. 415 Unsupported Media Type . . . . . . . . . . . . . . 61 |
---|
186 | 6.5.14. 417 Expectation Failed . . . . . . . . . . . . . . . . 62 |
---|
187 | 6.5.15. 426 Upgrade Required . . . . . . . . . . . . . . . . . 62 |
---|
188 | 6.6. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 62 |
---|
189 | 6.6.1. 500 Internal Server Error . . . . . . . . . . . . . . 62 |
---|
190 | 6.6.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 63 |
---|
191 | 6.6.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 63 |
---|
192 | 6.6.4. 503 Service Unavailable . . . . . . . . . . . . . . . 63 |
---|
193 | 6.6.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 63 |
---|
194 | 6.6.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 63 |
---|
195 | 7. Response Header Fields . . . . . . . . . . . . . . . . . . . . 64 |
---|
196 | 7.1. Control Data . . . . . . . . . . . . . . . . . . . . . . . 64 |
---|
197 | 7.1.1. Origination Date . . . . . . . . . . . . . . . . . . . 64 |
---|
198 | 7.1.2. Location . . . . . . . . . . . . . . . . . . . . . . . 68 |
---|
199 | 7.1.3. Retry-After . . . . . . . . . . . . . . . . . . . . . 69 |
---|
200 | 7.1.4. Vary . . . . . . . . . . . . . . . . . . . . . . . . . 70 |
---|
201 | 7.2. Validator Header Fields . . . . . . . . . . . . . . . . . 71 |
---|
202 | 7.3. Authentication Challenges . . . . . . . . . . . . . . . . 72 |
---|
203 | 7.4. Response Context . . . . . . . . . . . . . . . . . . . . . 72 |
---|
204 | 7.4.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . 72 |
---|
205 | 7.4.2. Server . . . . . . . . . . . . . . . . . . . . . . . . 73 |
---|
206 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 73 |
---|
207 | 8.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 74 |
---|
208 | 8.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 74 |
---|
209 | 8.1.2. Considerations for New Methods . . . . . . . . . . . . 74 |
---|
210 | 8.1.3. Registrations . . . . . . . . . . . . . . . . . . . . 75 |
---|
211 | 8.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 75 |
---|
212 | 8.2.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 75 |
---|
213 | 8.2.2. Considerations for New Status Codes . . . . . . . . . 76 |
---|
214 | 8.2.3. Registrations . . . . . . . . . . . . . . . . . . . . 76 |
---|
215 | 8.3. Header Field Registry . . . . . . . . . . . . . . . . . . 77 |
---|
216 | 8.3.1. Considerations for New Header Fields . . . . . . . . . 78 |
---|
217 | 8.3.2. Registrations . . . . . . . . . . . . . . . . . . . . 80 |
---|
218 | 8.4. Content Coding Registry . . . . . . . . . . . . . . . . . 80 |
---|
219 | 8.4.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 81 |
---|
220 | 8.4.2. Registrations . . . . . . . . . . . . . . . . . . . . 81 |
---|
221 | 9. Security Considerations . . . . . . . . . . . . . . . . . . . 81 |
---|
222 | 9.1. Attacks Based on File and Path Names . . . . . . . . . . . 82 |
---|
223 | 9.2. Attacks Based on Command, Code, or Query Injection . . . . 82 |
---|
224 | 9.3. Disclosure of Personal Information . . . . . . . . . . . . 83 |
---|
225 | 9.4. Disclosure of Sensitive Information in URIs . . . . . . . 83 |
---|
226 | 9.5. Disclosure of Fragment after Redirects . . . . . . . . . . 83 |
---|
227 | 9.6. Disclosure of Product Information . . . . . . . . . . . . 84 |
---|
228 | 9.7. Browser Fingerprinting . . . . . . . . . . . . . . . . . . 84 |
---|
229 | 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 85 |
---|
230 | 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 85 |
---|
231 | 11.1. Normative References . . . . . . . . . . . . . . . . . . . 85 |
---|
232 | 11.2. Informative References . . . . . . . . . . . . . . . . . . 86 |
---|
233 | Appendix A. Differences between HTTP and MIME . . . . . . . . . . 88 |
---|
234 | A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 89 |
---|
235 | A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 89 |
---|
236 | A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 89 |
---|
237 | A.4. Conversion of Content-Encoding . . . . . . . . . . . . . . 89 |
---|
238 | A.5. Conversion of Content-Transfer-Encoding . . . . . . . . . 90 |
---|
239 | A.6. MHTML and Line Length Limitations . . . . . . . . . . . . 90 |
---|
240 | Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 90 |
---|
241 | Appendix C. Imported ABNF . . . . . . . . . . . . . . . . . . . . 93 |
---|
242 | Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 93 |
---|
243 | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 |
---|
244 | |
---|
245 | NEW: |
---|
246 | |
---|
247 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 |
---|
248 | 1.1. Conformance and Error Handling . . . . . . . . . . . . . . 6 |
---|
249 | 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 |
---|
250 | 2. Resources . . . . . . . . . . . . . . . . . . . . . . . . . . 7 |
---|
251 | 3. Representations . . . . . . . . . . . . . . . . . . . . . . . 7 |
---|
252 | 3.1. Representation Metadata . . . . . . . . . . . . . . . . . 8 |
---|
253 | 3.1.1. Processing Representation Data . . . . . . . . . . . . 8 |
---|
254 | 3.1.2. Encoding for Compression or Integrity . . . . . . . . 11 |
---|
255 | 3.1.3. Audience Language . . . . . . . . . . . . . . . . . . 13 |
---|
256 | 3.1.4. Identification . . . . . . . . . . . . . . . . . . . . 14 |
---|
257 | 3.2. Representation Data . . . . . . . . . . . . . . . . . . . 17 |
---|
258 | 3.3. Payload Semantics . . . . . . . . . . . . . . . . . . . . 17 |
---|
259 | 3.4. Content Negotiation . . . . . . . . . . . . . . . . . . . 18 |
---|
260 | 3.4.1. Proactive Negotiation . . . . . . . . . . . . . . . . 19 |
---|
261 | 3.4.2. Reactive Negotiation . . . . . . . . . . . . . . . . . 20 |
---|
262 | 4. Request Methods . . . . . . . . . . . . . . . . . . . . . . . 21 |
---|
263 | 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 21 |
---|
264 | 4.2. Common Method Properties . . . . . . . . . . . . . . . . . 22 |
---|
265 | 4.2.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . 22 |
---|
266 | 4.2.2. Idempotent Methods . . . . . . . . . . . . . . . . . . 23 |
---|
267 | 4.2.3. Cacheable Methods . . . . . . . . . . . . . . . . . . 24 |
---|
268 | 4.3. Method Definitions . . . . . . . . . . . . . . . . . . . . 24 |
---|
269 | 4.3.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 24 |
---|
270 | 4.3.2. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . 25 |
---|
271 | 4.3.3. POST . . . . . . . . . . . . . . . . . . . . . . . . . 25 |
---|
272 | 4.3.4. PUT . . . . . . . . . . . . . . . . . . . . . . . . . 26 |
---|
273 | 4.3.5. DELETE . . . . . . . . . . . . . . . . . . . . . . . . 29 |
---|
274 | 4.3.6. CONNECT . . . . . . . . . . . . . . . . . . . . . . . 30 |
---|
275 | 4.3.7. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . 31 |
---|
276 | 4.3.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . 32 |
---|
277 | 5. Request Header Fields . . . . . . . . . . . . . . . . . . . . 33 |
---|
278 | 5.1. Controls . . . . . . . . . . . . . . . . . . . . . . . . . 33 |
---|
279 | 5.1.1. Expect . . . . . . . . . . . . . . . . . . . . . . . . 34 |
---|
280 | 5.1.2. Max-Forwards . . . . . . . . . . . . . . . . . . . . . 36 |
---|
281 | |
---|
282 | 5.2. Conditionals . . . . . . . . . . . . . . . . . . . . . . . 36 |
---|
283 | 5.3. Content Negotiation . . . . . . . . . . . . . . . . . . . 37 |
---|
284 | 5.3.1. Quality Values . . . . . . . . . . . . . . . . . . . . 37 |
---|
285 | 5.3.2. Accept . . . . . . . . . . . . . . . . . . . . . . . . 38 |
---|
286 | 5.3.3. Accept-Charset . . . . . . . . . . . . . . . . . . . . 40 |
---|
287 | 5.3.4. Accept-Encoding . . . . . . . . . . . . . . . . . . . 41 |
---|
288 | 5.3.5. Accept-Language . . . . . . . . . . . . . . . . . . . 42 |
---|
289 | 5.4. Authentication Credentials . . . . . . . . . . . . . . . . 43 |
---|
290 | 5.5. Request Context . . . . . . . . . . . . . . . . . . . . . 44 |
---|
291 | 5.5.1. From . . . . . . . . . . . . . . . . . . . . . . . . . 44 |
---|
292 | 5.5.2. Referer . . . . . . . . . . . . . . . . . . . . . . . 45 |
---|
293 | 5.5.3. User-Agent . . . . . . . . . . . . . . . . . . . . . . 46 |
---|
294 | 6. Response Status Codes . . . . . . . . . . . . . . . . . . . . 47 |
---|
295 | 6.1. Overview of Status Codes . . . . . . . . . . . . . . . . . 48 |
---|
296 | 6.2. Informational 1xx . . . . . . . . . . . . . . . . . . . . 50 |
---|
297 | 6.2.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 50 |
---|
298 | 6.2.2. 101 Switching Protocols . . . . . . . . . . . . . . . 50 |
---|
299 | 6.3. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 51 |
---|
300 | 6.3.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 51 |
---|
301 | 6.3.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 52 |
---|
302 | 6.3.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 52 |
---|
303 | 6.3.4. 203 Non-Authoritative Information . . . . . . . . . . 52 |
---|
304 | 6.3.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 53 |
---|
305 | 6.3.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 53 |
---|
306 | 6.4. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 54 |
---|
307 | 6.4.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 55 |
---|
308 | 6.4.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 56 |
---|
309 | 6.4.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 56 |
---|
310 | 6.4.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 57 |
---|
311 | 6.4.5. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 57 |
---|
312 | 6.4.6. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 57 |
---|
313 | 6.4.7. 307 Temporary Redirect . . . . . . . . . . . . . . . . 58 |
---|
314 | 6.5. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 58 |
---|
315 | 6.5.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 58 |
---|
316 | 6.5.2. 402 Payment Required . . . . . . . . . . . . . . . . . 58 |
---|
317 | 6.5.3. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 58 |
---|
318 | 6.5.4. 404 Not Found . . . . . . . . . . . . . . . . . . . . 59 |
---|
319 | 6.5.5. 405 Method Not Allowed . . . . . . . . . . . . . . . . 59 |
---|
320 | 6.5.6. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 59 |
---|
321 | 6.5.7. 408 Request Timeout . . . . . . . . . . . . . . . . . 60 |
---|
322 | 6.5.8. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 60 |
---|
323 | 6.5.9. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 60 |
---|
324 | 6.5.10. 411 Length Required . . . . . . . . . . . . . . . . . 61 |
---|
325 | 6.5.11. 413 Payload Too Large . . . . . . . . . . . . . . . . 61 |
---|
326 | 6.5.12. 414 URI Too Long . . . . . . . . . . . . . . . . . . . 61 |
---|
327 | 6.5.13. 415 Unsupported Media Type . . . . . . . . . . . . . . 61 |
---|
328 | 6.5.14. 417 Expectation Failed . . . . . . . . . . . . . . . . 62 |
---|
329 | 6.5.15. 426 Upgrade Required . . . . . . . . . . . . . . . . . 62 |
---|
330 | |
---|
331 | 6.6. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 62 |
---|
332 | 6.6.1. 500 Internal Server Error . . . . . . . . . . . . . . 62 |
---|
333 | 6.6.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 63 |
---|
334 | 6.6.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 63 |
---|
335 | 6.6.4. 503 Service Unavailable . . . . . . . . . . . . . . . 63 |
---|
336 | 6.6.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 63 |
---|
337 | 6.6.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 63 |
---|
338 | 7. Response Header Fields . . . . . . . . . . . . . . . . . . . . 64 |
---|
339 | 7.1. Control Data . . . . . . . . . . . . . . . . . . . . . . . 64 |
---|
340 | 7.1.1. Origination Date . . . . . . . . . . . . . . . . . . . 64 |
---|
341 | 7.1.2. Location . . . . . . . . . . . . . . . . . . . . . . . 68 |
---|
342 | 7.1.3. Retry-After . . . . . . . . . . . . . . . . . . . . . 69 |
---|
343 | 7.1.4. Vary . . . . . . . . . . . . . . . . . . . . . . . . . 70 |
---|
344 | 7.2. Validator Header Fields . . . . . . . . . . . . . . . . . 71 |
---|
345 | 7.3. Authentication Challenges . . . . . . . . . . . . . . . . 72 |
---|
346 | 7.4. Response Context . . . . . . . . . . . . . . . . . . . . . 72 |
---|
347 | 7.4.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . 72 |
---|
348 | 7.4.2. Server . . . . . . . . . . . . . . . . . . . . . . . . 73 |
---|
349 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 73 |
---|
350 | 8.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 74 |
---|
351 | 8.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 74 |
---|
352 | 8.1.2. Considerations for New Methods . . . . . . . . . . . . 74 |
---|
353 | 8.1.3. Registrations . . . . . . . . . . . . . . . . . . . . 75 |
---|
354 | 8.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 75 |
---|
355 | 8.2.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 75 |
---|
356 | 8.2.2. Considerations for New Status Codes . . . . . . . . . 76 |
---|
357 | 8.2.3. Registrations . . . . . . . . . . . . . . . . . . . . 76 |
---|
358 | 8.3. Header Field Registry . . . . . . . . . . . . . . . . . . 77 |
---|
359 | 8.3.1. Considerations for New Header Fields . . . . . . . . . 78 |
---|
360 | 8.3.2. Registrations . . . . . . . . . . . . . . . . . . . . 80 |
---|
361 | 8.4. Content Coding Registry . . . . . . . . . . . . . . . . . 80 |
---|
362 | 8.4.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 81 |
---|
363 | 8.4.2. Registrations . . . . . . . . . . . . . . . . . . . . 81 |
---|
364 | 9. Security Considerations . . . . . . . . . . . . . . . . . . . 81 |
---|
365 | 9.1. Attacks Based on File and Path Names . . . . . . . . . . . 82 |
---|
366 | 9.2. Attacks Based on Command, Code, or Query Injection . . . . 82 |
---|
367 | 9.3. Disclosure of Personal Information . . . . . . . . . . . . 83 |
---|
368 | 9.4. Disclosure of Sensitive Information in URIs . . . . . . . 83 |
---|
369 | 9.5. Disclosure of Fragment after Redirects . . . . . . . . . . 83 |
---|
370 | 9.6. Disclosure of Product Information . . . . . . . . . . . . 84 |
---|
371 | 9.7. Browser Fingerprinting . . . . . . . . . . . . . . . . . . 84 |
---|
372 | 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 85 |
---|
373 | 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 85 |
---|
374 | 11.1. Normative References . . . . . . . . . . . . . . . . . . . 85 |
---|
375 | 11.2. Informative References . . . . . . . . . . . . . . . . . . 86 |
---|
376 | Appendix A. Differences between HTTP and MIME . . . . . . . . . . 88 |
---|
377 | A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 88 |
---|
378 | A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 89 |
---|
379 | A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 89 |
---|
380 | A.4. Conversion of Content-Encoding . . . . . . . . . . . . . . 89 |
---|
381 | A.5. Conversion of Content-Transfer-Encoding . . . . . . . . . 90 |
---|
382 | A.6. MHTML and Line-Length Limitations . . . . . . . . . . . . 90 |
---|
383 | Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 90 |
---|
384 | Appendix C. Imported ABNF . . . . . . . . . . . . . . . . . . . . 93 |
---|
385 | Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 93 |
---|
386 | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 |
---|
387 | |
---|
388 | |
---|
389 | Section 2., paragraph 1: |
---|
390 | OLD: |
---|
391 | |
---|
392 | The target of an HTTP request is called a resource. HTTP does not |
---|
393 | limit the nature of a resource; it merely defines an interface that |
---|
394 | might be used to interact with resources. Each resource is |
---|
395 | identified by a Uniform Resource Identifier (URI), as described in |
---|
396 | Section 2.7 of [RFC7230]. |
---|
397 | |
---|
398 | NEW: |
---|
399 | |
---|
400 | The target of an HTTP request is called a "resource". HTTP does not |
---|
401 | limit the nature of a resource; it merely defines an interface that |
---|
402 | might be used to interact with resources. Each resource is |
---|
403 | identified by a Uniform Resource Identifier (URI), as described in |
---|
404 | Section 2.7 of [RFC7230]. |
---|
405 | |
---|
406 | |
---|
407 | Section 3.1.1.1., paragraph 1: |
---|
408 | OLD: |
---|
409 | |
---|
410 | HTTP uses Internet Media Types [RFC2046] in the Content-Type |
---|
411 | (Section 3.1.1.5) and Accept (Section 5.3.2) header fields in order |
---|
412 | to provide open and extensible data typing and type negotiation. |
---|
413 | Media types define both a data format and various processing models: |
---|
414 | how to process that data in accordance with each context in which it |
---|
415 | is received. |
---|
416 | |
---|
417 | NEW: |
---|
418 | |
---|
419 | HTTP uses Internet media types [RFC2046] in the Content-Type |
---|
420 | (Section 3.1.1.5) and Accept (Section 5.3.2) header fields in order |
---|
421 | to provide open and extensible data typing and type negotiation. |
---|
422 | Media types define both a data format and various processing models: |
---|
423 | how to process that data in accordance with each context in which it |
---|
424 | is received. |
---|
425 | |
---|
426 | |
---|
427 | Section 3.1.1.1., paragraph 5: |
---|
428 | OLD: |
---|
429 | |
---|
430 | The type, subtype, and parameter name tokens are case-insensitive. |
---|
431 | Parameter values might or might not be case-sensitive, depending on |
---|
432 | the semantics of the parameter name. The presence or absence of a |
---|
433 | parameter might be significant to the processing of a media-type, |
---|
434 | depending on its definition within the media type registry. |
---|
435 | |
---|
436 | NEW: |
---|
437 | |
---|
438 | The type, subtype, and parameter name tokens are case insensitive. |
---|
439 | Parameter values might or might not be case sensitive, depending on |
---|
440 | the semantics of the parameter name. The presence or absence of a |
---|
441 | parameter might be significant to the processing of a media-type, |
---|
442 | depending on its definition within the media type registry. |
---|
443 | |
---|
444 | |
---|
445 | Section 3.1.1.2., paragraph 3: |
---|
446 | OLD: |
---|
447 | |
---|
448 | Charset names ought to be registered in the IANA Character Set |
---|
449 | registry (<http://www.iana.org/assignments/character-sets>) according |
---|
450 | to the procedures defined in [RFC2978]. |
---|
451 | |
---|
452 | NEW: |
---|
453 | |
---|
454 | Charset names ought to be registered in the IANA "Character Sets" |
---|
455 | registry <http://www.iana.org/assignments/character-sets> according |
---|
456 | to the procedures defined in [RFC2978]. |
---|
457 | |
---|
458 | |
---|
459 | Section 3.1.1.3., paragraph 2: |
---|
460 | OLD: |
---|
461 | |
---|
462 | MIME's canonical form requires that media subtypes of the "text" type |
---|
463 | use CRLF as the text line break. HTTP allows the transfer of text |
---|
464 | media with plain CR or LF alone representing a line break, when such |
---|
465 | line breaks are consistent for an entire representation. An HTTP |
---|
466 | sender MAY generate, and a recipient MUST be able to parse, line |
---|
467 | breaks in text media that consist of CRLF, bare CR, or bare LF. In |
---|
468 | addition, text media in HTTP is not limited to charsets that use |
---|
469 | octets 13 and 10 for CR and LF, respectively. This flexibility |
---|
470 | regarding line breaks applies only to text within a representation |
---|
471 | that has been assigned a "text" media type; it does not apply to |
---|
472 | "multipart" types or HTTP elements outside the payload body (e.g., |
---|
473 | header fields). |
---|
474 | |
---|
475 | NEW: |
---|
476 | |
---|
477 | MIME's canonical form requires that media subtypes of the "text" type |
---|
478 | use CRLF as the text line break. HTTP allows the transfer of text |
---|
479 | media with plain carriage return (CR) or line feed (LF) alone |
---|
480 | representing a line break, when such line breaks are consistent for |
---|
481 | an entire representation. An HTTP sender MAY generate, and a |
---|
482 | recipient MUST be able to parse, line breaks in text media that |
---|
483 | consist of CRLF, bare CR, or bare LF. In addition, text media in |
---|
484 | HTTP is not limited to charsets that use octets 13 and 10 for CR and |
---|
485 | LF, respectively. This flexibility regarding line breaks applies |
---|
486 | only to text within a representation that has been assigned a "text" |
---|
487 | media type; it does not apply to "multipart" types or HTTP elements |
---|
488 | outside the payload body (e.g., header fields). |
---|
489 | |
---|
490 | |
---|
491 | Section 3.1.2.1., paragraph 3: |
---|
492 | OLD: |
---|
493 | |
---|
494 | All content-coding values are case-insensitive and ought to be |
---|
495 | registered within the HTTP Content Coding registry, as defined in |
---|
496 | Section 8.4. They are used in the Accept-Encoding (Section 5.3.4) |
---|
497 | and Content-Encoding (Section 3.1.2.2) header fields. |
---|
498 | |
---|
499 | NEW: |
---|
500 | |
---|
501 | All content-coding values are case insensitive and ought to be |
---|
502 | registered within the "HTTP Content Coding Registry", as defined in |
---|
503 | Section 8.4. They are used in the Accept-Encoding (Section 5.3.4) |
---|
504 | and Content-Encoding (Section 3.1.2.2) header fields. |
---|
505 | |
---|
506 | |
---|
507 | Section 3.1.3.2., paragraph 5: |
---|
508 | OLD: |
---|
509 | |
---|
510 | If no Content-Language is specified, the default is that the content |
---|
511 | is intended for all language audiences. This might mean that the |
---|
512 | sender does not consider it to be specific to any natural language, |
---|
513 | or that the sender does not know for which language it is intended. |
---|
514 | |
---|
515 | NEW: |
---|
516 | |
---|
517 | If no Content-Language is specified, the default is that the content |
---|
518 | is intended for all language audiences. This might mean that the |
---|
519 | sender does not consider it to be specific to any natural language, |
---|
520 | or that the sender does not know which language is being used. |
---|
521 | |
---|
522 | |
---|
523 | Section 3.4.1., paragraph 2: |
---|
524 | OLD: |
---|
525 | |
---|
526 | Proactive negotiation is advantageous when the algorithm for |
---|
527 | selecting from among the available representations is difficult to |
---|
528 | describe to a user agent, or when the server desires to send its |
---|
529 | "best guess" to the user agent along with the first response (hoping |
---|
530 | to avoid the round trip delay of a subsequent request if the "best |
---|
531 | guess" is good enough for the user). In order to improve the |
---|
532 | server's guess, a user agent MAY send request header fields that |
---|
533 | describe its preferences. |
---|
534 | |
---|
535 | NEW: |
---|
536 | |
---|
537 | Proactive negotiation is advantageous when the algorithm for |
---|
538 | selecting from among the available representations is difficult to |
---|
539 | describe to a user agent, or when the server desires to send its |
---|
540 | "best guess" to the user agent along with the first response (hoping |
---|
541 | to avoid the round-trip delay of a subsequent request if the "best |
---|
542 | guess" is good enough for the user). In order to improve the |
---|
543 | server's guess, a user agent MAY send request header fields that |
---|
544 | describe its preferences. |
---|
545 | |
---|
546 | |
---|
547 | Section 4.1., paragraph 4: |
---|
548 | OLD: |
---|
549 | |
---|
550 | HTTP was originally designed to be usable as an interface to |
---|
551 | distributed object systems. The request method was envisioned as |
---|
552 | applying semantics to a target resource in much the same way as |
---|
553 | invoking a defined method on an identified object would apply |
---|
554 | semantics. The method token is case-sensitive because it might be |
---|
555 | used as a gateway to object-based systems with case-sensitive method |
---|
556 | names. |
---|
557 | |
---|
558 | NEW: |
---|
559 | |
---|
560 | HTTP was originally designed to be usable as an interface to |
---|
561 | distributed object systems. The request method was envisioned as |
---|
562 | applying semantics to a target resource in much the same way as |
---|
563 | invoking a defined method on an identified object would apply |
---|
564 | semantics. The method token is case sensitive because it might be |
---|
565 | used as a gateway to object-based systems with case-sensitive method |
---|
566 | names. |
---|
567 | |
---|
568 | |
---|
569 | Section 4.1., paragraph 5: |
---|
570 | OLD: |
---|
571 | |
---|
572 | Unlike distributed objects, the standardized request methods in HTTP |
---|
573 | are not resource-specific, since uniform interfaces provide for |
---|
574 | better visibility and reuse in network-based systems [REST]. Once |
---|
575 | defined, a standardized method ought to have the same semantics when |
---|
576 | applied to any resource, though each resource determines for itself |
---|
577 | whether those semantics are implemented or allowed. |
---|
578 | |
---|
579 | NEW: |
---|
580 | |
---|
581 | Unlike distributed objects, the standardized request methods in HTTP |
---|
582 | are not resource specific, since uniform interfaces provide for |
---|
583 | better visibility and reuse in network-based systems [REST]. Once |
---|
584 | defined, a standardized method ought to have the same semantics when |
---|
585 | applied to any resource, though each resource determines for itself |
---|
586 | whether those semantics are implemented or allowed. |
---|
587 | |
---|
588 | |
---|
589 | Section 4.1., paragraph 9: |
---|
590 | OLD: |
---|
591 | |
---|
592 | Additional methods, outside the scope of this specification, have |
---|
593 | been standardized for use in HTTP. All such methods ought to be |
---|
594 | registered within the HTTP Method Registry maintained by IANA, as |
---|
595 | defined in Section 8.1. |
---|
596 | |
---|
597 | NEW: |
---|
598 | |
---|
599 | Additional methods, outside the scope of this specification, have |
---|
600 | been standardized for use in HTTP. All such methods ought to be |
---|
601 | registered within the "Hypertext Transfer Protocol (HTTP) Method" |
---|
602 | registry maintained by IANA, as defined in Section 8.1. |
---|
603 | |
---|
604 | |
---|
605 | Section 4.2.1., paragraph 2: |
---|
606 | OLD: |
---|
607 | |
---|
608 | This definition of safe methods does not prevent an implementation |
---|
609 | from including behavior that is potentially harmful, not entirely |
---|
610 | read-only, or which causes side effects while invoking a safe method. |
---|
611 | What is important, however, is that the client did not request that |
---|
612 | additional behavior and cannot be held accountable for it. For |
---|
613 | example, most servers append request information to access log files |
---|
614 | at the completion of every response, regardless of the method, and |
---|
615 | that is considered safe even though the log storage might become full |
---|
616 | and crash the server. Likewise, a safe request initiated by |
---|
617 | selecting an advertisement on the Web will often have the side effect |
---|
618 | of charging an advertising account. |
---|
619 | |
---|
620 | NEW: |
---|
621 | |
---|
622 | This definition of safe method does not prevent an implementation |
---|
623 | from including behavior that is potentially harmful, that is not |
---|
624 | entirely read-only, or that causes side effects while invoking a safe |
---|
625 | method. What is important, however, is that the client did not |
---|
626 | request that additional behavior and cannot be held accountable for |
---|
627 | it. For example, most servers append request information to access |
---|
628 | log files at the completion of every response, regardless of the |
---|
629 | method, and that is considered safe even though the log storage might |
---|
630 | become full and crash the server. Likewise, a safe request initiated |
---|
631 | by selecting an advertisement on the Web will often have the side |
---|
632 | effect of charging an advertising account. |
---|
633 | |
---|
634 | |
---|
635 | Section 4.3.3., paragraph 6: |
---|
636 | OLD: |
---|
637 | |
---|
638 | An origin server indicates response semantics by choosing an |
---|
639 | appropriate status code depending on the result of processing the |
---|
640 | POST request; almost all of the status codes defined by this |
---|
641 | specification might be received in a response to POST (the exceptions |
---|
642 | being 206, 304, and 416). |
---|
643 | |
---|
644 | NEW: |
---|
645 | |
---|
646 | An origin server indicates response semantics by choosing an |
---|
647 | appropriate status code depending on the result of processing the |
---|
648 | POST request; almost all of the status codes defined by this |
---|
649 | specification might be received in a response to POST (the exceptions |
---|
650 | being 206 (Partial Content), 304 (Not Modified), and 416 (Range Not |
---|
651 | Satisfiable)). |
---|
652 | |
---|
653 | |
---|
654 | Section 4.3.6., paragraph 2: |
---|
655 | OLD: |
---|
656 | |
---|
657 | CONNECT is intended only for use in requests to a proxy. An origin |
---|
658 | server that receives a CONNECT request for itself MAY respond with a |
---|
659 | 2xx status code to indicate that a connection is established. |
---|
660 | However, most origin servers do not implement CONNECT. |
---|
661 | |
---|
662 | NEW: |
---|
663 | |
---|
664 | CONNECT is intended only for use in requests to a proxy. An origin |
---|
665 | server that receives a CONNECT request for itself MAY respond with a |
---|
666 | 2xx (Successful) status code to indicate that a connection is |
---|
667 | established. However, most origin servers do not implement CONNECT. |
---|
668 | |
---|
669 | |
---|
670 | Section 4.3.8., paragraph 2: |
---|
671 | OLD: |
---|
672 | |
---|
673 | A client MUST NOT generate header fields in a TRACE request |
---|
674 | containing sensitive data that might be disclosed by the response. |
---|
675 | |
---|
676 | For example, it would be foolish for a user agent to send stored user |
---|
677 | credentials [RFC7235] or cookies [RFC6265] in a TRACE request. The |
---|
678 | final recipient of the request SHOULD exclude any request header |
---|
679 | fields that are likely to contain sensitive data when that recipient |
---|
680 | generates the response body. |
---|
681 | |
---|
682 | NEW: |
---|
683 | |
---|
684 | A client MUST NOT generate header fields in a TRACE request |
---|
685 | containing sensitive data that might be disclosed by the response. |
---|
686 | For example, it would be foolish for a user agent to send stored user |
---|
687 | credentials [RFC7235] or cookies [RFC6265] in a TRACE request. The |
---|
688 | final recipient of the request SHOULD exclude any request header |
---|
689 | fields that are likely to contain sensitive data when that recipient |
---|
690 | generates the response body. |
---|
691 | |
---|
692 | |
---|
693 | Section 5.1.1., paragraph 3: |
---|
694 | OLD: |
---|
695 | |
---|
696 | The Expect field-value is case-insensitive. |
---|
697 | |
---|
698 | NEW: |
---|
699 | |
---|
700 | The Expect field-value is case insensitive. |
---|
701 | |
---|
702 | |
---|
703 | Section 5.1.1., paragraph 21: |
---|
704 | OLD: |
---|
705 | |
---|
706 | Note: The Expect header field was added after the original |
---|
707 | publication of HTTP/1.1 [RFC2068] as both the means to request an |
---|
708 | interim 100 response and the general mechanism for indicating |
---|
709 | must-understand extensions. However, the extension mechanism has |
---|
710 | not been used by clients and the must-understand requirements have |
---|
711 | not been implemented by many servers, rendering the extension |
---|
712 | mechanism useless. This specification has removed the extension |
---|
713 | mechanism in order to simplify the definition and processing of |
---|
714 | 100-continue. |
---|
715 | |
---|
716 | NEW: |
---|
717 | |
---|
718 | Note: The Expect header field was added after the original |
---|
719 | publication of HTTP/1.1 [RFC2068] as both the means to request an |
---|
720 | interim 100 (Continue) response and the general mechanism for |
---|
721 | indicating must-understand extensions. However, the extension |
---|
722 | mechanism has not been used by clients and the must-understand |
---|
723 | requirements have not been implemented by many servers, rendering |
---|
724 | the extension mechanism useless. This specification has removed |
---|
725 | the extension mechanism in order to simplify the definition and |
---|
726 | processing of 100-continue. |
---|
727 | |
---|
728 | |
---|
729 | Section 5.5.1., paragraph 1: |
---|
730 | OLD: |
---|
731 | |
---|
732 | The "From" header field contains an Internet email address for a |
---|
733 | human user who controls the requesting user agent. The address ought |
---|
734 | to be machine-usable, as defined by "mailbox" in Section 3.4 of |
---|
735 | [RFC5322]: |
---|
736 | |
---|
737 | NEW: |
---|
738 | |
---|
739 | The "From" header field contains an Internet email address for a |
---|
740 | human user who controls the requesting user agent. The address ought |
---|
741 | to be machine usable, as defined by "mailbox" in Section 3.4 of |
---|
742 | [RFC5322]: |
---|
743 | |
---|
744 | |
---|
745 | Section 5.5.2., paragraph 6: |
---|
746 | OLD: |
---|
747 | |
---|
748 | If the target URI was obtained from a source that does not have its |
---|
749 | own URI (e.g., input from the user keyboard, or an entry within the |
---|
750 | user's bookmarks/favorites), the user agent MUST either exclude |
---|
751 | Referer or send it with a value of "about:blank". |
---|
752 | |
---|
753 | NEW: |
---|
754 | |
---|
755 | If the target URI was obtained from a source that does not have its |
---|
756 | own URI (e.g., input from the user keyboard, or an entry within the |
---|
757 | user's bookmarks/favorites), the user agent MUST either exclude the |
---|
758 | Referer or send it with a value of "about:blank". |
---|
759 | |
---|
760 | |
---|
761 | Section 5.5.3., paragraph 1: |
---|
762 | OLD: |
---|
763 | |
---|
764 | The "User-Agent" header field contains information about the user |
---|
765 | agent originating the request, which is often used by servers to help |
---|
766 | identify the scope of reported interoperability problems, to work |
---|
767 | around or tailor responses to avoid particular user agent |
---|
768 | limitations, and for analytics regarding browser or operating system |
---|
769 | use. A user agent SHOULD send a User-Agent field in each request |
---|
770 | unless specifically configured not to do so. |
---|
771 | |
---|
772 | NEW: |
---|
773 | |
---|
774 | The "User-Agent" header field contains information about the user |
---|
775 | agent originating the request, which is often used by servers to help |
---|
776 | identify the scope of reported interoperability problems, to work |
---|
777 | around or tailor responses to avoid particular user-agent |
---|
778 | limitations, and for analytics regarding browser or operating system |
---|
779 | use. A user agent SHOULD send a User-Agent field in each request |
---|
780 | unless specifically configured not to do so. |
---|
781 | |
---|
782 | |
---|
783 | Section 5.5.3., paragraph 3: |
---|
784 | OLD: |
---|
785 | |
---|
786 | The User-Agent field-value consists of one or more product |
---|
787 | identifiers, each followed by zero or more comments (Section 3.2 of |
---|
788 | [RFC7230]), which together identify the user agent software and its |
---|
789 | significant subproducts. By convention, the product identifiers are |
---|
790 | listed in decreasing order of their significance for identifying the |
---|
791 | user agent software. Each product identifier consists of a name and |
---|
792 | optional version. |
---|
793 | |
---|
794 | NEW: |
---|
795 | |
---|
796 | The User-Agent field-value consists of one or more product |
---|
797 | identifiers, each followed by zero or more comments (Section 3.2 of |
---|
798 | [RFC7230]), which together identify the user-agent software and its |
---|
799 | significant subproducts. By convention, the product identifiers are |
---|
800 | listed in decreasing order of their significance for identifying the |
---|
801 | user-agent software. Each product identifier consists of a name and |
---|
802 | optional version. |
---|
803 | |
---|
804 | |
---|
805 | Section 5.5.3., paragraph 9: |
---|
806 | OLD: |
---|
807 | |
---|
808 | Likewise, implementations are encouraged not to use the product |
---|
809 | tokens of other implementations in order to declare compatibility |
---|
810 | with them, as this circumvents the purpose of the field. If a user |
---|
811 | agent masquerades as a different user agent, recipients can assume |
---|
812 | that the user intentionally desires to see responses tailored for |
---|
813 | that identified user agent, even if they might not work as well for |
---|
814 | the actual user agent being used. |
---|
815 | |
---|
816 | NEW: |
---|
817 | |
---|
818 | Likewise, implementations are encouraged not to use the product |
---|
819 | tokens of other implementations in order to declare compatibility |
---|
820 | with them, as this circumvents the purpose of the field. If a user |
---|
821 | agent masquerades as a different user agent, recipients can assume |
---|
822 | that the user intentionally desires to see responses tailored for |
---|
823 | that identified user agent, even if they might not work as well for |
---|
824 | the actual user agent being implemented. |
---|
825 | |
---|
826 | |
---|
827 | Section 6., paragraph 3: |
---|
828 | OLD: |
---|
829 | |
---|
830 | For example, if an unrecognized status code of 471 is received by a |
---|
831 | client, the client can assume that there was something wrong with its |
---|
832 | request and treat the response as if it had received a 400 status |
---|
833 | code. The response message will usually contain a representation |
---|
834 | that explains the status. |
---|
835 | |
---|
836 | NEW: |
---|
837 | |
---|
838 | For example, if an unrecognized status code of 471 is received by a |
---|
839 | client, the client can assume that there was something wrong with its |
---|
840 | request and treat the response as if it had received a 400 (Bad |
---|
841 | Request) status code. The response message will usually contain a |
---|
842 | representation that explains the status. |
---|
843 | |
---|
844 | |
---|
845 | Section 6.1., paragraph 2: |
---|
846 | OLD: |
---|
847 | |
---|
848 | Responses with status codes that are defined as cacheable by default |
---|
849 | (e.g., 200, 203, 204, 206, 300, 301, 404, 405, 410, 414, 501 in this |
---|
850 | specification) can be reused by a cache with heuristic expiration |
---|
851 | unless otherwise indicated by the method definition or explicit cache |
---|
852 | controls [RFC7234]; all other status codes are not cacheable by |
---|
853 | default. |
---|
854 | |
---|
855 | NEW: |
---|
856 | |
---|
857 | Responses with status codes that are defined as cacheable by default |
---|
858 | (e.g., 200, 203, 204, 206, 300, 301, 404, 405, 410, 414, and 501 in |
---|
859 | this specification) can be reused by a cache with heuristic |
---|
860 | expiration unless otherwise indicated by the method definition or |
---|
861 | explicit cache controls [RFC7234]; all other status codes are not |
---|
862 | cacheable by default. |
---|
863 | |
---|
864 | |
---|
865 | Section 6.4.1., paragraph 5: |
---|
866 | OLD: |
---|
867 | |
---|
868 | Note: The original proposal for 300 defined the URI header field |
---|
869 | as providing a list of alternative representations, such that it |
---|
870 | would be usable for 200, 300, and 406 responses and be transferred |
---|
871 | in responses to the HEAD method. However, lack of deployment and |
---|
872 | disagreement over syntax led to both URI and Alternates (a |
---|
873 | subsequent proposal) being dropped from this specification. It is |
---|
874 | possible to communicate the list using a set of Link header fields |
---|
875 | [RFC5988], each with a relationship of "alternate", though |
---|
876 | deployment is a chicken-and-egg problem. |
---|
877 | |
---|
878 | NEW: |
---|
879 | |
---|
880 | Note: The original proposal for the 300 response defined the URI |
---|
881 | header field as providing a list of alternative representations, |
---|
882 | such that it would be usable for 200, 300, and 406 responses and |
---|
883 | be transferred in responses to the HEAD method. However, lack of |
---|
884 | deployment and disagreement over syntax led to both URI and |
---|
885 | Alternates (a subsequent proposal) being dropped from this |
---|
886 | specification. It is possible to communicate the list using a set |
---|
887 | of Link header fields [RFC5988], each with a relationship of |
---|
888 | "alternate", though deployment is a chicken-and-egg problem. |
---|
889 | |
---|
890 | |
---|
891 | Section 6.4.7., paragraph 3: |
---|
892 | OLD: |
---|
893 | |
---|
894 | Note: This status code is similar to 302 (Found), except that it |
---|
895 | does not allow changing the request method from POST to GET. This |
---|
896 | specification defines no equivalent counterpart for 301 (Moved |
---|
897 | Permanently) ([RFC7238], however, defines the status code 308 |
---|
898 | (Permanent Redirect) for this purpose). |
---|
899 | |
---|
900 | NEW: |
---|
901 | |
---|
902 | Note: This status code is similar to 302 (Found), except that it |
---|
903 | does not allow changing the request method from POST to GET. This |
---|
904 | specification defines no equivalent counterpart for 301 (Moved |
---|
905 | Permanently) ([RFC7238]; however, it defines the status code 308 |
---|
906 | (Permanent Redirect) for this purpose). |
---|
907 | |
---|
908 | |
---|
909 | Section 7.1.1.1., paragraph 11: |
---|
910 | OLD: |
---|
911 | |
---|
912 | day-name = %x4D.6F.6E ; "Mon", case-sensitive |
---|
913 | / %x54.75.65 ; "Tue", case-sensitive |
---|
914 | / %x57.65.64 ; "Wed", case-sensitive |
---|
915 | / %x54.68.75 ; "Thu", case-sensitive |
---|
916 | / %x46.72.69 ; "Fri", case-sensitive |
---|
917 | / %x53.61.74 ; "Sat", case-sensitive |
---|
918 | / %x53.75.6E ; "Sun", case-sensitive |
---|
919 | |
---|
920 | NEW: |
---|
921 | |
---|
922 | day-name = %x4D.6F.6E ; "Mon", case sensitive |
---|
923 | / %x54.75.65 ; "Tue", case sensitive |
---|
924 | / %x57.65.64 ; "Wed", case sensitive |
---|
925 | / %x54.68.75 ; "Thu", case sensitive |
---|
926 | / %x46.72.69 ; "Fri", case sensitive |
---|
927 | / %x53.61.74 ; "Sat", case sensitive |
---|
928 | / %x53.75.6E ; "Sun", case sensitive |
---|
929 | |
---|
930 | |
---|
931 | Section 7.1.1.1., paragraph 13: |
---|
932 | OLD: |
---|
933 | |
---|
934 | day = 2DIGIT |
---|
935 | month = %x4A.61.6E ; "Jan", case-sensitive |
---|
936 | / %x46.65.62 ; "Feb", case-sensitive |
---|
937 | / %x4D.61.72 ; "Mar", case-sensitive |
---|
938 | / %x41.70.72 ; "Apr", case-sensitive |
---|
939 | / %x4D.61.79 ; "May", case-sensitive |
---|
940 | / %x4A.75.6E ; "Jun", case-sensitive |
---|
941 | / %x4A.75.6C ; "Jul", case-sensitive |
---|
942 | / %x41.75.67 ; "Aug", case-sensitive |
---|
943 | / %x53.65.70 ; "Sep", case-sensitive |
---|
944 | / %x4F.63.74 ; "Oct", case-sensitive |
---|
945 | / %x4E.6F.76 ; "Nov", case-sensitive |
---|
946 | / %x44.65.63 ; "Dec", case-sensitive |
---|
947 | year = 4DIGIT |
---|
948 | |
---|
949 | NEW: |
---|
950 | |
---|
951 | day = 2DIGIT |
---|
952 | month = %x4A.61.6E ; "Jan", case sensitive |
---|
953 | / %x46.65.62 ; "Feb", case sensitive |
---|
954 | / %x4D.61.72 ; "Mar", case sensitive |
---|
955 | / %x41.70.72 ; "Apr", case sensitive |
---|
956 | / %x4D.61.79 ; "May", case sensitive |
---|
957 | / %x4A.75.6E ; "Jun", case sensitive |
---|
958 | / %x4A.75.6C ; "Jul", case sensitive |
---|
959 | / %x41.75.67 ; "Aug", case sensitive |
---|
960 | / %x53.65.70 ; "Sep", case sensitive |
---|
961 | / %x4F.63.74 ; "Oct", case sensitive |
---|
962 | / %x4E.6F.76 ; "Nov", case sensitive |
---|
963 | / %x44.65.63 ; "Dec", case sensitive |
---|
964 | year = 4DIGIT |
---|
965 | |
---|
966 | |
---|
967 | Section 7.1.1.1., paragraph 14: |
---|
968 | OLD: |
---|
969 | |
---|
970 | GMT = %x47.4D.54 ; "GMT", case-sensitive |
---|
971 | |
---|
972 | NEW: |
---|
973 | |
---|
974 | GMT = %x47.4D.54 ; "GMT", case sensitive |
---|
975 | |
---|
976 | |
---|
977 | Section 7.1.1.1., paragraph 19: |
---|
978 | OLD: |
---|
979 | |
---|
980 | day-name-l = %x4D.6F.6E.64.61.79 ; "Monday", case-sensitive |
---|
981 | / %x54.75.65.73.64.61.79 ; "Tuesday", case-sensitive |
---|
982 | / %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive |
---|
983 | / %x54.68.75.72.73.64.61.79 ; "Thursday", case-sensitive |
---|
984 | / %x46.72.69.64.61.79 ; "Friday", case-sensitive |
---|
985 | / %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive |
---|
986 | / %x53.75.6E.64.61.79 ; "Sunday", case-sensitive |
---|
987 | |
---|
988 | NEW: |
---|
989 | |
---|
990 | day-name-l = %x4D.6F.6E.64.61.79 ; "Monday", case sensitive |
---|
991 | / %x54.75.65.73.64.61.79 ; "Tuesday", case sensitive |
---|
992 | / %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case sensitive |
---|
993 | / %x54.68.75.72.73.64.61.79 ; "Thursday", case sensitive |
---|
994 | / %x46.72.69.64.61.79 ; "Friday", case sensitive |
---|
995 | / %x53.61.74.75.72.64.61.79 ; "Saturday", case sensitive |
---|
996 | / %x53.75.6E.64.61.79 ; "Sunday", case sensitive |
---|
997 | |
---|
998 | |
---|
999 | Section 7.1.4., paragraph 1: |
---|
1000 | OLD: |
---|
1001 | |
---|
1002 | The "Vary" header field in a response describes what parts of a |
---|
1003 | request message, aside from the method, Host header field, and |
---|
1004 | request target, might influence the origin server's process for |
---|
1005 | selecting and representing this response. The value consists of |
---|
1006 | either a single asterisk ("*") or a list of header field names (case- |
---|
1007 | insensitive). |
---|
1008 | |
---|
1009 | NEW: |
---|
1010 | |
---|
1011 | The "Vary" header field in a response describes what parts of a |
---|
1012 | request message, aside from the method, Host header field, and |
---|
1013 | request target, might influence the origin server's process for |
---|
1014 | selecting and representing this response. The value consists of |
---|
1015 | either a single asterisk ("*") or a list of header field names (case |
---|
1016 | insensitive). |
---|
1017 | |
---|
1018 | |
---|
1019 | Section 1., paragraph 1: |
---|
1020 | OLD: |
---|
1021 | |
---|
1022 | 2. To inform user agent recipients that this response is subject to |
---|
1023 | content negotiation (Section 5.3) and that a different |
---|
1024 | representation might be sent in a subsequent request if |
---|
1025 | additional parameters are provided in the listed header fields |
---|
1026 | (proactive negotiation). |
---|
1027 | |
---|
1028 | NEW: |
---|
1029 | |
---|
1030 | 2. To inform user-agent recipients that this response is subject to |
---|
1031 | content negotiation (Section 5.3) and that a different |
---|
1032 | representation might be sent in a subsequent request if |
---|
1033 | additional parameters are provided in the listed header fields |
---|
1034 | (proactive negotiation). |
---|
1035 | |
---|
1036 | |
---|
1037 | Section 7.2., paragraph 3: |
---|
1038 | OLD: |
---|
1039 | |
---|
1040 | For example, an ETag header field in a 201 response communicates the |
---|
1041 | entity-tag of the newly created resource's representation, so that it |
---|
1042 | can be used in later conditional requests to prevent the "lost |
---|
1043 | update" problem [RFC7232]. |
---|
1044 | |
---|
1045 | NEW: |
---|
1046 | |
---|
1047 | For example, an ETag header field in a 201 (Created) response |
---|
1048 | communicates the entity-tag of the newly created resource's |
---|
1049 | representation, so that it can be used in later conditional requests |
---|
1050 | to prevent the "lost update" problem [RFC7232]. |
---|
1051 | |
---|
1052 | |
---|
1053 | Section 8.1., paragraph 1: |
---|
1054 | OLD: |
---|
1055 | |
---|
1056 | The HTTP Method Registry defines the namespace for the request method |
---|
1057 | token (Section 4). The method registry has been created and is now |
---|
1058 | maintained at <http://www.iana.org/assignments/http-methods>. |
---|
1059 | |
---|
1060 | NEW: |
---|
1061 | |
---|
1062 | The "Hypertext Transfer Protocol (HTTP) Method Registry" defines the |
---|
1063 | namespace for the request method token (Section 4). The "HTTP Method |
---|
1064 | Registry" has been created and is now maintained at |
---|
1065 | <http://www.iana.org/assignments/http-methods>. |
---|
1066 | |
---|
1067 | |
---|
1068 | Section 8.1.2., paragraph 3: |
---|
1069 | OLD: |
---|
1070 | |
---|
1071 | A new method definition needs to indicate whether it is safe |
---|
1072 | (Section 4.2.1), idempotent (Section 4.2.2), cacheable |
---|
1073 | (Section 4.2.3), what semantics are to be associated with the payload |
---|
1074 | body if any is present in the request, and what refinements the |
---|
1075 | method makes to header field or status code semantics. If the new |
---|
1076 | method is cacheable, its definition ought to describe how, and under |
---|
1077 | what conditions, a cache can store a response and use it to satisfy a |
---|
1078 | subsequent request. The new method ought to describe whether it can |
---|
1079 | be made conditional (Section 5.2) and, if so, how a server responds |
---|
1080 | when the condition is false. Likewise, if the new method might have |
---|
1081 | some use for partial response semantics ([RFC7233]), it ought to |
---|
1082 | document this, too. |
---|
1083 | |
---|
1084 | NEW: |
---|
1085 | |
---|
1086 | A new method definition needs to indicate whether it is safe |
---|
1087 | (Section 4.2.1), idempotent (Section 4.2.2), or cacheable |
---|
1088 | (Section 4.2.3). It needs to indicate what semantics are to be |
---|
1089 | associated with the payload body if any is present in the request and |
---|
1090 | what refinements the method makes to header field or status code |
---|
1091 | semantics. If the new method is cacheable, its definition ought to |
---|
1092 | describe how, and under what conditions, a cache can store a response |
---|
1093 | and use it to satisfy a subsequent request. The new method ought to |
---|
1094 | describe whether it can be made conditional (Section 5.2) and, if so, |
---|
1095 | how a server responds when the condition is false. Likewise, if the |
---|
1096 | new method might have some use for partial response semantics |
---|
1097 | ([RFC7233]), it ought to document this, too. |
---|
1098 | |
---|
1099 | |
---|
1100 | Section 8.1.3., paragraph 1: |
---|
1101 | OLD: |
---|
1102 | |
---|
1103 | The HTTP Method Registry has been populated with the registrations |
---|
1104 | below: |
---|
1105 | |
---|
1106 | NEW: |
---|
1107 | |
---|
1108 | The "Hypertext Transfer Protocol (HTTP) Method Registry" has been |
---|
1109 | populated with the registrations below: |
---|
1110 | |
---|
1111 | |
---|
1112 | Section 8.2., paragraph 1: |
---|
1113 | OLD: |
---|
1114 | |
---|
1115 | The HTTP Status Code Registry defines the namespace for the response |
---|
1116 | status-code token (Section 6). The status code registry is |
---|
1117 | maintained at <http://www.iana.org/assignments/http-status-codes>. |
---|
1118 | |
---|
1119 | NEW: |
---|
1120 | |
---|
1121 | The "Hypertext Transfer Protocol (HTTP) Status Code Registry" defines |
---|
1122 | the namespace for the response status-code token (Section 6). The |
---|
1123 | "HTTP Status Codes" registry is maintained at |
---|
1124 | <http://www.iana.org/assignments/http-status-codes>. |
---|
1125 | |
---|
1126 | |
---|
1127 | Section 8.2.3., paragraph 1: |
---|
1128 | OLD: |
---|
1129 | |
---|
1130 | The HTTP Status Code Registry has been updated with the registrations |
---|
1131 | below: |
---|
1132 | |
---|
1133 | NEW: |
---|
1134 | |
---|
1135 | The "HTTP Status Codes" registry has been updated with the |
---|
1136 | registrations below: |
---|
1137 | |
---|
1138 | |
---|
1139 | Section 8.3., paragraph 1: |
---|
1140 | OLD: |
---|
1141 | |
---|
1142 | HTTP header fields are registered within the Message Header Field |
---|
1143 | Registry located at <http://www.iana.org/assignments/message-headers/ |
---|
1144 | message-header-index.html>, as defined by [BCP90]. |
---|
1145 | |
---|
1146 | NEW: |
---|
1147 | |
---|
1148 | HTTP header fields are registered within the "Message Headers" |
---|
1149 | registry located at <http://www.iana.org/assignments/message-headers> |
---|
1150 | as defined by [BCP90]. |
---|
1151 | |
---|
1152 | |
---|
1153 | Section 8.3.1., paragraph 4: |
---|
1154 | OLD: |
---|
1155 | |
---|
1156 | New header field values typically have their syntax defined using |
---|
1157 | ABNF ([RFC5234]), using the extension defined in Section 7 of |
---|
1158 | [RFC7230] as necessary, and are usually constrained to the range of |
---|
1159 | ASCII characters. Header fields needing a greater range of |
---|
1160 | characters can use an encoding such as the one defined in [RFC5987]. |
---|
1161 | |
---|
1162 | NEW: |
---|
1163 | |
---|
1164 | New header field values typically have their syntax defined using |
---|
1165 | ABNF ([RFC5234]) (implementing the extension defined in Section 7 of |
---|
1166 | [RFC7230] as necessary), and they are usually constrained to the |
---|
1167 | range of ASCII characters. Header fields needing a greater range of |
---|
1168 | characters can use an encoding such as the one defined in [RFC5987]. |
---|
1169 | |
---|
1170 | |
---|
1171 | Section 8.3.2., paragraph 1: |
---|
1172 | OLD: |
---|
1173 | |
---|
1174 | The Message Header Field Registry has been updated with the following |
---|
1175 | permanent registrations: |
---|
1176 | |
---|
1177 | NEW: |
---|
1178 | |
---|
1179 | The "Message Headers" registry has been updated with the following |
---|
1180 | permanent registrations: |
---|
1181 | |
---|
1182 | |
---|
1183 | Section 8.4., paragraph 1: |
---|
1184 | OLD: |
---|
1185 | |
---|
1186 | The HTTP Content Coding Registry defines the namespace for content |
---|
1187 | coding names (Section 4.2 of [RFC7230]). The content coding registry |
---|
1188 | is maintained at <http://www.iana.org/assignments/http-parameters>. |
---|
1189 | |
---|
1190 | NEW: |
---|
1191 | |
---|
1192 | The "HTTP Content Coding Registry" defines the namespace for content |
---|
1193 | coding names (Section 4.2 of [RFC7230]). The "HTTP Content Coding |
---|
1194 | Registry" is maintained at |
---|
1195 | <http://www.iana.org/assignments/http-parameters>. |
---|
1196 | |
---|
1197 | |
---|
1198 | Section 8.4.1., paragraph 1: |
---|
1199 | OLD: |
---|
1200 | |
---|
1201 | Content Coding registrations MUST include the following fields: |
---|
1202 | |
---|
1203 | NEW: |
---|
1204 | |
---|
1205 | Content coding registrations MUST include the following fields: |
---|
1206 | |
---|
1207 | |
---|
1208 | Section 8.4.1., paragraph 6: |
---|
1209 | OLD: |
---|
1210 | |
---|
1211 | Values to be added to this namespace require IETF Review (see Section |
---|
1212 | 4.1 of [RFC5226]), and MUST conform to the purpose of content coding |
---|
1213 | defined in this section. |
---|
1214 | |
---|
1215 | NEW: |
---|
1216 | |
---|
1217 | Values to be added to this namespace require IETF Review (see Section |
---|
1218 | 4.1 of [RFC5226]) and MUST conform to the purpose of content coding |
---|
1219 | defined in this section. |
---|
1220 | |
---|
1221 | |
---|
1222 | Section 8.4.2., paragraph 1: |
---|
1223 | OLD: |
---|
1224 | |
---|
1225 | The HTTP Content Codings Registry has been updated with the |
---|
1226 | registrations below: |
---|
1227 | |
---|
1228 | NEW: |
---|
1229 | |
---|
1230 | The "HTTP Content Codings Registry" has been updated with the |
---|
1231 | registrations below: |
---|
1232 | |
---|
1233 | |
---|
1234 | Section 9., paragraph 2: |
---|
1235 | OLD: |
---|
1236 | |
---|
1237 | The list of considerations below is not exhaustive. Most security |
---|
1238 | concerns related to HTTP semantics are about securing server-side |
---|
1239 | applications (code behind the HTTP interface), securing user agent |
---|
1240 | processing of payloads received via HTTP, or secure use of the |
---|
1241 | Internet in general, rather than security of the protocol. Various |
---|
1242 | organizations maintain topical information and links to current |
---|
1243 | research on Web application security (e.g., [OWASP]). |
---|
1244 | |
---|
1245 | NEW: |
---|
1246 | |
---|
1247 | The list of considerations below is not exhaustive. Most security |
---|
1248 | concerns related to HTTP semantics are about securing server-side |
---|
1249 | applications (code behind the HTTP interface) or securing user-agent |
---|
1250 | processing of payloads received via HTTP. Secure use of the Internet |
---|
1251 | in general, rather than security of the protocol, might also be |
---|
1252 | related. Various organizations maintain topical information and |
---|
1253 | links to current research on Web application security (e.g., |
---|
1254 | [OWASP]). |
---|
1255 | |
---|
1256 | |
---|
1257 | Section 9.1., paragraph 3: |
---|
1258 | OLD: |
---|
1259 | |
---|
1260 | Attacks based on such special names tend to focus on either denial- |
---|
1261 | of-service (e.g., telling the server to read from a COM port) or |
---|
1262 | disclosure of configuration and source files that are not meant to be |
---|
1263 | served. |
---|
1264 | |
---|
1265 | NEW: |
---|
1266 | |
---|
1267 | Attacks based on such special names tend to focus on either denial of |
---|
1268 | service (e.g., telling the server to read from a COM port) or |
---|
1269 | disclosure of configuration and source files that are not meant to be |
---|
1270 | served. |
---|
1271 | |
---|
1272 | |
---|
1273 | Section 9.4., paragraph 3: |
---|
1274 | OLD: |
---|
1275 | |
---|
1276 | Since the Referer header field tells a target site about the context |
---|
1277 | that resulted in a request, it has the potential to reveal |
---|
1278 | information about the user's immediate browsing history and any |
---|
1279 | personal information that might be found in the referring resource's |
---|
1280 | URI. Limitations on Referer are described in Section 5.5.2 to |
---|
1281 | address some of its security considerations. |
---|
1282 | |
---|
1283 | NEW: |
---|
1284 | |
---|
1285 | Since the Referer header field tells a target site about the context |
---|
1286 | that resulted in a request, it has the potential to reveal |
---|
1287 | information about the user's immediate browsing history and any |
---|
1288 | personal information that might be found in the referring resource's |
---|
1289 | URI. Limitations on the Referer header field are described in |
---|
1290 | Section 5.5.2 to address some of its security considerations. |
---|
1291 | |
---|
1292 | |
---|
1293 | Section 11.1., paragraph 9: |
---|
1294 | OLD: |
---|
1295 | |
---|
1296 | [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer |
---|
1297 | Protocol (HTTP/1.1): Message Syntax and Routing", |
---|
1298 | draft-ietf-httpbis-p1-messaging-latest (work in progress), |
---|
1299 | May 2014. |
---|
1300 | |
---|
1301 | NEW: |
---|
1302 | |
---|
1303 | [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer |
---|
1304 | Protocol (HTTP/1.1): Message Syntax and Routing", |
---|
1305 | RFC 7230, May 2014. |
---|
1306 | |
---|
1307 | |
---|
1308 | Section 11.1., paragraph 10: |
---|
1309 | OLD: |
---|
1310 | |
---|
1311 | [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer |
---|
1312 | Protocol (HTTP/1.1): Conditional Requests", |
---|
1313 | draft-ietf-httpbis-p4-conditional-latest (work in |
---|
1314 | progress), May 2014. |
---|
1315 | |
---|
1316 | NEW: |
---|
1317 | |
---|
1318 | [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer |
---|
1319 | Protocol (HTTP/1.1): Conditional Requests", RFC 7232, |
---|
1320 | May 2014. |
---|
1321 | |
---|
1322 | |
---|
1323 | Section 11.1., paragraph 11: |
---|
1324 | OLD: |
---|
1325 | |
---|
1326 | [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., |
---|
1327 | "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", |
---|
1328 | draft-ietf-httpbis-p5-range-latest (work in progress), |
---|
1329 | May 2014. |
---|
1330 | |
---|
1331 | NEW: |
---|
1332 | |
---|
1333 | [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., |
---|
1334 | "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", |
---|
1335 | RFC 7233, May 2014. |
---|
1336 | |
---|
1337 | |
---|
1338 | Section 11.1., paragraph 12: |
---|
1339 | OLD: |
---|
1340 | |
---|
1341 | [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, |
---|
1342 | Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", |
---|
1343 | draft-ietf-httpbis-p6-cache-latest (work in progress), |
---|
1344 | May 2014. |
---|
1345 | |
---|
1346 | NEW: |
---|
1347 | |
---|
1348 | [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, |
---|
1349 | Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", |
---|
1350 | RFC 7234, May 2014. |
---|
1351 | |
---|
1352 | |
---|
1353 | Section 11.1., paragraph 13: |
---|
1354 | OLD: |
---|
1355 | |
---|
1356 | [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer |
---|
1357 | Protocol (HTTP/1.1): Authentication", |
---|
1358 | draft-ietf-httpbis-p7-auth-latest (work in progress), |
---|
1359 | May 2014. |
---|
1360 | |
---|
1361 | NEW: |
---|
1362 | |
---|
1363 | [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer |
---|
1364 | Protocol (HTTP/1.1): Authentication", RFC 7235, May 2014. |
---|
1365 | |
---|
1366 | |
---|
1367 | Section 11.2., paragraph 25: |
---|
1368 | OLD: |
---|
1369 | |
---|
1370 | [RFC7238] Reschke, J., "The Hypertext Transfer Protocol (HTTP) |
---|
1371 | Status Code 308 (Permanent Redirect)", |
---|
1372 | draft-reschke-http-status-308-07 (work in progress), |
---|
1373 | March 2012. |
---|
1374 | |
---|
1375 | NEW: |
---|
1376 | |
---|
1377 | [RFC7238] Reschke, J., "The Hypertext Transfer Protocol (HTTP) |
---|
1378 | Status Code 308 (Permanent Redirect)", RFC 7238, May 2014. |
---|
1379 | |
---|
1380 | |
---|
1381 | Appendix A., paragraph 16: |
---|
1382 | OLD: |
---|
1383 | |
---|
1384 | A.6. MHTML and Line Length Limitations |
---|
1385 | |
---|
1386 | NEW: |
---|
1387 | |
---|
1388 | A.6. MHTML and Line-Length Limitations |
---|
1389 | |
---|
1390 | |
---|
1391 | Appendix A., paragraph 17: |
---|
1392 | OLD: |
---|
1393 | |
---|
1394 | HTTP implementations that share code with MHTML [RFC2557] |
---|
1395 | implementations need to be aware of MIME line length limitations. |
---|
1396 | Since HTTP does not have this limitation, HTTP does not fold long |
---|
1397 | lines. MHTML messages being transported by HTTP follow all |
---|
1398 | conventions of MHTML, including line length limitations and folding, |
---|
1399 | canonicalization, etc., since HTTP transfers message-bodies as |
---|
1400 | payload and, aside from the "multipart/byteranges" type (Appendix A |
---|
1401 | of [RFC7233]), does not interpret the content or any MIME header |
---|
1402 | lines that might be contained therein. |
---|
1403 | |
---|
1404 | NEW: |
---|
1405 | |
---|
1406 | HTTP implementations that share code with MHTML [RFC2557] |
---|
1407 | implementations need to be aware of MIME line-length limitations. |
---|
1408 | Since HTTP does not have this limitation, HTTP does not fold long |
---|
1409 | lines. MHTML messages being transported by HTTP follow all |
---|
1410 | conventions of MHTML, including line-length limitations and folding, |
---|
1411 | canonicalization, etc., since HTTP transfers message-bodies as |
---|
1412 | payload and, aside from the "multipart/byteranges" type (Appendix A |
---|
1413 | of [RFC7233]), does not interpret the content or any MIME header |
---|
1414 | lines that might be contained therein. |
---|
1415 | |
---|
1416 | |
---|
1417 | Appendix B., paragraph 2: |
---|
1418 | OLD: |
---|
1419 | |
---|
1420 | A new requirement has been added that semantics embedded in a URI |
---|
1421 | should be disabled when those semantics are inconsistent with the |
---|
1422 | request method, since this is a common cause of interoperability |
---|
1423 | failure. (Section 2) |
---|
1424 | |
---|
1425 | NEW: |
---|
1426 | |
---|
1427 | A new requirement has been added that semantics embedded in a URI be |
---|
1428 | disabled when those semantics are inconsistent with the request |
---|
1429 | method, since this is a common cause of interoperability failure |
---|
1430 | (Section 2). |
---|
1431 | |
---|
1432 | |
---|
1433 | Appendix B., paragraph 3: |
---|
1434 | OLD: |
---|
1435 | |
---|
1436 | An algorithm has been added for determining if a payload is |
---|
1437 | associated with a specific identifier. (Section 3.1.4.1) |
---|
1438 | |
---|
1439 | NEW: |
---|
1440 | |
---|
1441 | An algorithm has been added for determining if a payload is |
---|
1442 | associated with a specific identifier (Section 3.1.4.1). |
---|
1443 | |
---|
1444 | |
---|
1445 | Appendix B., paragraph 4: |
---|
1446 | OLD: |
---|
1447 | |
---|
1448 | The default charset of ISO-8859-1 for text media types has been |
---|
1449 | removed; the default is now whatever the media type definition says. |
---|
1450 | Likewise, special treatment of ISO-8859-1 has been removed from the |
---|
1451 | Accept-Charset header field. (Section 3.1.1.3 and Section 5.3.3) |
---|
1452 | |
---|
1453 | NEW: |
---|
1454 | |
---|
1455 | The default charset of ISO-8859-1 for text media types has been |
---|
1456 | removed; the default is now whatever the media type definition says. |
---|
1457 | Likewise, special treatment of ISO-8859-1 has been removed from the |
---|
1458 | Accept-Charset header field. (Sections 3.1.1.3 and 5.3.3.) |
---|
1459 | |
---|
1460 | |
---|
1461 | Appendix B., paragraph 5: |
---|
1462 | OLD: |
---|
1463 | |
---|
1464 | The definition of Content-Location has been changed to no longer |
---|
1465 | affect the base URI for resolving relative URI references, due to |
---|
1466 | poor implementation support and the undesirable effect of potentially |
---|
1467 | breaking relative links in content-negotiated resources. |
---|
1468 | (Section 3.1.4.2) |
---|
1469 | |
---|
1470 | NEW: |
---|
1471 | |
---|
1472 | The definition of Content-Location has been changed to no longer |
---|
1473 | affect the base URI for resolving relative URI references, due to |
---|
1474 | poor implementation support and the undesirable effect of potentially |
---|
1475 | breaking relative links in content-negotiated resources |
---|
1476 | (Section 3.1.4.2). |
---|
1477 | |
---|
1478 | |
---|
1479 | Appendix B., paragraph 6: |
---|
1480 | OLD: |
---|
1481 | |
---|
1482 | To be consistent with the method-neutral parsing algorithm of |
---|
1483 | [RFC7230], the definition of GET has been relaxed so that requests |
---|
1484 | can have a body, even though a body has no meaning for GET. |
---|
1485 | (Section 4.3.1) |
---|
1486 | |
---|
1487 | NEW: |
---|
1488 | |
---|
1489 | To be consistent with the method-neutral parsing algorithm of |
---|
1490 | [RFC7230], the definition of GET has been relaxed so that requests |
---|
1491 | can have a body, even though a body has no meaning for GET |
---|
1492 | (Section 4.3.1). |
---|
1493 | |
---|
1494 | |
---|
1495 | Appendix B., paragraph 7: |
---|
1496 | OLD: |
---|
1497 | |
---|
1498 | Servers are no longer required to handle all Content-* header fields |
---|
1499 | and use of Content-Range has been explicitly banned in PUT requests. |
---|
1500 | (Section 4.3.4) |
---|
1501 | |
---|
1502 | NEW: |
---|
1503 | |
---|
1504 | Servers are no longer required to handle all Content-* header fields |
---|
1505 | and use of Content-Range has been explicitly banned in PUT requests |
---|
1506 | (Section 4.3.4). |
---|
1507 | |
---|
1508 | |
---|
1509 | Appendix B., paragraph 8: |
---|
1510 | OLD: |
---|
1511 | |
---|
1512 | Definition of the CONNECT method has been moved from [RFC2817] to |
---|
1513 | this specification. (Section 4.3.6) |
---|
1514 | |
---|
1515 | NEW: |
---|
1516 | |
---|
1517 | Definition of the CONNECT method has been moved from [RFC2817] to |
---|
1518 | this specification (Section 4.3.6). |
---|
1519 | |
---|
1520 | |
---|
1521 | Appendix B., paragraph 9: |
---|
1522 | OLD: |
---|
1523 | |
---|
1524 | The OPTIONS and TRACE request methods have been defined as being |
---|
1525 | safe. (Section 4.3.7 and Section 4.3.8) |
---|
1526 | |
---|
1527 | NEW: |
---|
1528 | |
---|
1529 | The OPTIONS and TRACE request methods have been defined as being safe |
---|
1530 | (Section 4.3.7 and Section 4.3.8). |
---|
1531 | |
---|
1532 | |
---|
1533 | Appendix B., paragraph 10: |
---|
1534 | OLD: |
---|
1535 | |
---|
1536 | The Expect header field's extension mechanism has been removed due to |
---|
1537 | widely-deployed broken implementations. (Section 5.1.1) |
---|
1538 | |
---|
1539 | NEW: |
---|
1540 | |
---|
1541 | The Expect header field's extension mechanism has been removed due to |
---|
1542 | widely deployed broken implementations (Section 5.1.1). |
---|
1543 | |
---|
1544 | |
---|
1545 | Appendix B., paragraph 11: |
---|
1546 | OLD: |
---|
1547 | |
---|
1548 | The Max-Forwards header field has been restricted to the OPTIONS and |
---|
1549 | TRACE methods; previously, extension methods could have used it as |
---|
1550 | well. (Section 5.1.2) |
---|
1551 | |
---|
1552 | NEW: |
---|
1553 | |
---|
1554 | The Max-Forwards header field has been restricted to the OPTIONS and |
---|
1555 | TRACE methods; previously, extension methods could have used it as |
---|
1556 | well (Section 5.1.2). |
---|
1557 | |
---|
1558 | |
---|
1559 | Appendix B., paragraph 12: |
---|
1560 | OLD: |
---|
1561 | |
---|
1562 | The "about:blank" URI has been suggested as a value for the Referer |
---|
1563 | header field when no referring URI is applicable, which distinguishes |
---|
1564 | that case from others where the Referer field is not sent or has been |
---|
1565 | removed. (Section 5.5.2) |
---|
1566 | |
---|
1567 | NEW: |
---|
1568 | |
---|
1569 | The "about:blank" URI has been suggested as a value for the Referer |
---|
1570 | header field when no referring URI is applicable, which distinguishes |
---|
1571 | that case from others where the Referer field is not sent or has been |
---|
1572 | removed (Section 5.5.2). |
---|
1573 | |
---|
1574 | |
---|
1575 | Appendix B., paragraph 13: |
---|
1576 | OLD: |
---|
1577 | |
---|
1578 | The following status codes are now cacheable (that is, they can be |
---|
1579 | stored and reused by a cache without explicit freshness information |
---|
1580 | present): 204, 404, 405, 414, 501. (Section 6) |
---|
1581 | |
---|
1582 | NEW: |
---|
1583 | |
---|
1584 | The following status codes are now cacheable (that is, they can be |
---|
1585 | stored and reused by a cache without explicit freshness information |
---|
1586 | present): 204, 404, 405, 414, 501 (Section 6). |
---|
1587 | |
---|
1588 | |
---|
1589 | Appendix B., paragraph 14: |
---|
1590 | OLD: |
---|
1591 | |
---|
1592 | The 201 (Created) status description has been changed to allow for |
---|
1593 | the possibility that more than one resource has been created. |
---|
1594 | (Section 6.3.2) |
---|
1595 | |
---|
1596 | NEW: |
---|
1597 | |
---|
1598 | The 201 (Created) status description has been changed to allow for |
---|
1599 | the possibility that more than one resource has been created |
---|
1600 | (Section 6.3.2). |
---|
1601 | |
---|
1602 | |
---|
1603 | Appendix B., paragraph 15: |
---|
1604 | OLD: |
---|
1605 | |
---|
1606 | The definition of 203 (Non-Authoritative Information) has been |
---|
1607 | broadened to include cases of payload transformations as well. |
---|
1608 | (Section 6.3.4) |
---|
1609 | |
---|
1610 | NEW: |
---|
1611 | |
---|
1612 | The definition of 203 (Non-Authoritative Information) has been |
---|
1613 | broadened to include cases of payload transformations as well |
---|
1614 | (Section 6.3.4). |
---|
1615 | |
---|
1616 | |
---|
1617 | Appendix B., paragraph 16: |
---|
1618 | OLD: |
---|
1619 | |
---|
1620 | The set of request methods that are safe to automatically redirect is |
---|
1621 | no longer closed; user agents are able to make that determination |
---|
1622 | based upon the request method semantics. The redirect status codes |
---|
1623 | 301, 302, and 307 no longer have normative requirements on response |
---|
1624 | payloads and user interaction. (Section 6.4) |
---|
1625 | |
---|
1626 | NEW: |
---|
1627 | |
---|
1628 | The set of request methods that are safe to automatically redirect is |
---|
1629 | no longer closed; user agents are able to make that determination |
---|
1630 | based upon the request method semantics. The redirect status codes |
---|
1631 | 301, 302, and 307 no longer have normative requirements on response |
---|
1632 | payloads and user interaction (Section 6.4). |
---|
1633 | |
---|
1634 | |
---|
1635 | Appendix B., paragraph 17: |
---|
1636 | OLD: |
---|
1637 | |
---|
1638 | The status codes 301 and 302 have been changed to allow user agents |
---|
1639 | to rewrite the method from POST to GET. (Sections 6.4.2 and 6.4.3) |
---|
1640 | |
---|
1641 | NEW: |
---|
1642 | |
---|
1643 | The status codes 301 and 302 have been changed to allow user agents |
---|
1644 | to rewrite the method from POST to GET. (Sections 6.4.2 and 6.4.3.) |
---|
1645 | |
---|
1646 | |
---|
1647 | Appendix B., paragraph 18: |
---|
1648 | OLD: |
---|
1649 | |
---|
1650 | The description of 303 (See Other) status code has been changed to |
---|
1651 | allow it to be cached if explicit freshness information is given, and |
---|
1652 | a specific definition has been added for a 303 response to GET. |
---|
1653 | (Section 6.4.4) |
---|
1654 | |
---|
1655 | NEW: |
---|
1656 | |
---|
1657 | The description of the 303 (See Other) status code has been changed |
---|
1658 | to allow it to be cached if explicit freshness information is given, |
---|
1659 | and a specific definition has been added for a 303 response to GET |
---|
1660 | (Section 6.4.4). |
---|
1661 | |
---|
1662 | |
---|
1663 | Appendix B., paragraph 19: |
---|
1664 | OLD: |
---|
1665 | |
---|
1666 | The 305 (Use Proxy) status code has been deprecated due to security |
---|
1667 | concerns regarding in-band configuration of a proxy. (Section 6.4.5) |
---|
1668 | |
---|
1669 | NEW: |
---|
1670 | |
---|
1671 | The 305 (Use Proxy) status code has been deprecated due to security |
---|
1672 | concerns regarding in-band configuration of a proxy (Section 6.4.5). |
---|
1673 | |
---|
1674 | |
---|
1675 | Appendix B., paragraph 20: |
---|
1676 | OLD: |
---|
1677 | |
---|
1678 | The 400 (Bad Request) status code has been relaxed so that it isn't |
---|
1679 | limited to syntax errors. (Section 6.5.1) |
---|
1680 | |
---|
1681 | NEW: |
---|
1682 | |
---|
1683 | The 400 (Bad Request) status code has been relaxed so that it isn't |
---|
1684 | limited to syntax errors (Section 6.5.1). |
---|
1685 | |
---|
1686 | |
---|
1687 | Appendix B., paragraph 21: |
---|
1688 | OLD: |
---|
1689 | |
---|
1690 | The 426 (Upgrade Required) status code has been incorporated from |
---|
1691 | [RFC2817]. (Section 6.5.15) |
---|
1692 | |
---|
1693 | NEW: |
---|
1694 | |
---|
1695 | The 426 (Upgrade Required) status code has been incorporated from |
---|
1696 | [RFC2817] (Section 6.5.15). |
---|
1697 | |
---|
1698 | |
---|
1699 | Appendix B., paragraph 22: |
---|
1700 | OLD: |
---|
1701 | |
---|
1702 | The target of requirements on HTTP-date and the Date header field |
---|
1703 | have been reduced to those systems generating the date, rather than |
---|
1704 | all systems sending a date. (Section 7.1.1) |
---|
1705 | |
---|
1706 | NEW: |
---|
1707 | |
---|
1708 | The target of requirements on HTTP-date and the Date header field |
---|
1709 | have been reduced to those systems generating the date, rather than |
---|
1710 | all systems sending a date (Section 7.1.1). |
---|
1711 | |
---|
1712 | |
---|
1713 | Appendix B., paragraph 23: |
---|
1714 | OLD: |
---|
1715 | |
---|
1716 | The syntax of the Location header field has been changed to allow all |
---|
1717 | URI references, including relative references and fragments, along |
---|
1718 | with some clarifications as to when use of fragments would not be |
---|
1719 | appropriate. (Section 7.1.2) |
---|
1720 | |
---|
1721 | NEW: |
---|
1722 | |
---|
1723 | The syntax of the Location header field has been changed to allow all |
---|
1724 | URI references, including relative references and fragments, along |
---|
1725 | with some clarifications as to when use of fragments would not be |
---|
1726 | appropriate (Section 7.1.2). |
---|
1727 | |
---|
1728 | |
---|
1729 | Appendix B., paragraph 24: |
---|
1730 | OLD: |
---|
1731 | |
---|
1732 | Allow has been reclassified as a response header field, removing the |
---|
1733 | option to specify it in a PUT request. Requirements relating to the |
---|
1734 | content of Allow have been relaxed; correspondingly, clients are not |
---|
1735 | required to always trust its value. (Section 7.4.1) |
---|
1736 | |
---|
1737 | NEW: |
---|
1738 | |
---|
1739 | Allow has been reclassified as a response header field, removing the |
---|
1740 | option to specify it in a PUT request. Requirements relating to the |
---|
1741 | content of Allow have been relaxed; correspondingly, clients are not |
---|
1742 | required to always trust its value (Section 7.4.1). |
---|
1743 | |
---|
1744 | |
---|
1745 | Appendix B., paragraph 25: |
---|
1746 | OLD: |
---|
1747 | |
---|
1748 | A Method Registry has been defined. (Section 8.1) |
---|
1749 | |
---|
1750 | NEW: |
---|
1751 | |
---|
1752 | A Method Registry has been defined (Section 8.1). |
---|
1753 | |
---|
1754 | |
---|
1755 | Appendix B., paragraph 26: |
---|
1756 | OLD: |
---|
1757 | |
---|
1758 | The Status Code Registry has been redefined by this specification; |
---|
1759 | previously, it was defined in Section 7.1 of [RFC2817]. |
---|
1760 | |
---|
1761 | (Section 8.2) |
---|
1762 | |
---|
1763 | NEW: |
---|
1764 | |
---|
1765 | The Status Code Registry has been redefined by this specification; |
---|
1766 | previously, it was defined in Section 7.1 of [RFC2817] (Section 8.2). |
---|
1767 | |
---|
1768 | |
---|
1769 | Appendix B., paragraph 27: |
---|
1770 | OLD: |
---|
1771 | |
---|
1772 | Registration of Content Codings has been changed to require IETF |
---|
1773 | Review. (Section 8.4) |
---|
1774 | |
---|
1775 | NEW: |
---|
1776 | |
---|
1777 | Registration of content codings has been changed to require IETF |
---|
1778 | Review (Section 8.4). |
---|
1779 | |
---|
1780 | |
---|
1781 | Section 1.2, paragraph 1: |
---|
1782 | OLD: |
---|
1783 | |
---|
1784 | Accept = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [ |
---|
1785 | OWS ( media-range [ accept-params ] ) ] ) ] |
---|
1786 | Accept-Charset = *( "," OWS ) ( ( charset / "*" ) [ weight ] ) *( OWS |
---|
1787 | "," [ OWS ( ( charset / "*" ) [ weight ] ) ] ) |
---|
1788 | Accept-Encoding = [ ( "," / ( codings [ weight ] ) ) *( OWS "," [ OWS |
---|
1789 | ( codings [ weight ] ) ] ) ] |
---|
1790 | Accept-Language = *( "," OWS ) ( language-range [ weight ] ) *( OWS |
---|
1791 | "," [ OWS ( language-range [ weight ] ) ] ) |
---|
1792 | Allow = [ ( "," / method ) *( OWS "," [ OWS method ] ) ] |
---|
1793 | BWS = <BWS, defined in [RFC7230], Section 3.2.3> |
---|
1794 | |
---|
1795 | NEW: |
---|
1796 | |
---|
1797 | Accept = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [ |
---|
1798 | OWS ( media-range [ accept-params ] ) ] ) ] |
---|
1799 | Accept-Charset = *( "," OWS ) ( ( charset / "*" ) [ weight ] ) *( OWS |
---|
1800 | "," [ OWS ( ( charset / "*" ) [ weight ] ) ] ) |
---|
1801 | Accept-Encoding = [ ( "," / ( codings [ weight ] ) ) *( OWS "," [ OWS |
---|
1802 | ( codings [ weight ] ) ] ) ] |
---|
1803 | Accept-Language = *( "," OWS ) ( language-range [ weight ] ) *( OWS |
---|
1804 | "," [ OWS ( language-range [ weight ] ) ] ) |
---|
1805 | Allow = [ ( "," / method ) *( OWS "," [ OWS method ] ) ] |
---|
1806 | |
---|
1807 | BWS = <BWS, defined in [RFC7230], Section 3.2.3> |
---|
1808 | |
---|
1809 | |
---|
1810 | Section 1.2, paragraph 2: |
---|
1811 | OLD: |
---|
1812 | |
---|
1813 | Content-Encoding = *( "," OWS ) content-coding *( OWS "," [ OWS |
---|
1814 | content-coding ] ) |
---|
1815 | Content-Language = *( "," OWS ) language-tag *( OWS "," [ OWS |
---|
1816 | language-tag ] ) |
---|
1817 | Content-Location = absolute-URI / partial-URI |
---|
1818 | Content-Type = media-type |
---|
1819 | |
---|
1820 | Date = HTTP-date |
---|
1821 | |
---|
1822 | NEW: |
---|
1823 | |
---|
1824 | Content-Encoding = *( "," OWS ) content-coding *( OWS "," [ OWS |
---|
1825 | content-coding ] ) |
---|
1826 | Content-Language = *( "," OWS ) language-tag *( OWS "," [ OWS |
---|
1827 | language-tag ] ) |
---|
1828 | Content-Location = absolute-URI / partial-URI |
---|
1829 | Content-Type = media-type |
---|
1830 | Date = HTTP-date |
---|
1831 | |
---|
1832 | |
---|
1833 | Section 1.2, paragraph 16: |
---|
1834 | OLD: |
---|
1835 | |
---|
1836 | charset = token |
---|
1837 | codings = content-coding / "identity" / "*" |
---|
1838 | comment = <comment, defined in [RFC7230], Section 3.2.6> |
---|
1839 | content-coding = token |
---|
1840 | date1 = day SP month SP year |
---|
1841 | date2 = day "-" month "-" 2DIGIT |
---|
1842 | date3 = month SP ( 2DIGIT / ( SP DIGIT ) ) |
---|
1843 | day = 2DIGIT |
---|
1844 | day-name = %x4D.6F.6E ; Mon |
---|
1845 | / %x54.75.65 ; Tue |
---|
1846 | / %x57.65.64 ; Wed |
---|
1847 | / %x54.68.75 ; Thu |
---|
1848 | / %x46.72.69 ; Fri |
---|
1849 | / %x53.61.74 ; Sat |
---|
1850 | / %x53.75.6E ; Sun |
---|
1851 | day-name-l = %x4D.6F.6E.64.61.79 ; Monday |
---|
1852 | / %x54.75.65.73.64.61.79 ; Tuesday |
---|
1853 | / %x57.65.64.6E.65.73.64.61.79 ; Wednesday |
---|
1854 | / %x54.68.75.72.73.64.61.79 ; Thursday |
---|
1855 | / %x46.72.69.64.61.79 ; Friday |
---|
1856 | / %x53.61.74.75.72.64.61.79 ; Saturday |
---|
1857 | / %x53.75.6E.64.61.79 ; Sunday |
---|
1858 | delay-seconds = 1*DIGIT |
---|
1859 | |
---|
1860 | NEW: |
---|
1861 | |
---|
1862 | charset = token |
---|
1863 | codings = content-coding / "identity" / "*" |
---|
1864 | comment = <comment, defined in [RFC7230], Section 3.2.6> |
---|
1865 | content-coding = token |
---|
1866 | |
---|
1867 | date1 = day SP month SP year |
---|
1868 | date2 = day "-" month "-" 2DIGIT |
---|
1869 | date3 = month SP ( 2DIGIT / ( SP DIGIT ) ) |
---|
1870 | day = 2DIGIT |
---|
1871 | day-name = %x4D.6F.6E ; Mon |
---|
1872 | / %x54.75.65 ; Tue |
---|
1873 | / %x57.65.64 ; Wed |
---|
1874 | / %x54.68.75 ; Thu |
---|
1875 | / %x46.72.69 ; Fri |
---|
1876 | / %x53.61.74 ; Sat |
---|
1877 | / %x53.75.6E ; Sun |
---|
1878 | day-name-l = %x4D.6F.6E.64.61.79 ; Monday |
---|
1879 | / %x54.75.65.73.64.61.79 ; Tuesday |
---|
1880 | / %x57.65.64.6E.65.73.64.61.79 ; Wednesday |
---|
1881 | / %x54.68.75.72.73.64.61.79 ; Thursday |
---|
1882 | / %x46.72.69.64.61.79 ; Friday |
---|
1883 | / %x53.61.74.75.72.64.61.79 ; Saturday |
---|
1884 | / %x53.75.6E.64.61.79 ; Sunday |
---|
1885 | delay-seconds = 1*DIGIT |
---|
1886 | |
---|
1887 | |
---|
1888 | Section 1.2, paragraph 21: |
---|
1889 | OLD: |
---|
1890 | |
---|
1891 | obs-date = rfc850-date / asctime-date |
---|
1892 | parameter = token "=" ( token / quoted-string ) |
---|
1893 | partial-URI = <partial-URI, defined in [RFC7230], Section 2.7> |
---|
1894 | product = token [ "/" product-version ] |
---|
1895 | product-version = token |
---|
1896 | |
---|
1897 | quoted-string = <quoted-string, defined in [RFC7230], Section 3.2.6> |
---|
1898 | qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] ) |
---|
1899 | |
---|
1900 | NEW: |
---|
1901 | |
---|
1902 | obs-date = rfc850-date / asctime-date |
---|
1903 | |
---|
1904 | parameter = token "=" ( token / quoted-string ) |
---|
1905 | partial-URI = <partial-URI, defined in [RFC7230], Section 2.7> |
---|
1906 | product = token [ "/" product-version ] |
---|
1907 | product-version = token |
---|
1908 | quoted-string = <quoted-string, defined in [RFC7230], Section 3.2.6> |
---|
1909 | qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] ) |
---|
1910 | |
---|
1911 | |
---|
1912 | Section 1.2, paragraph 47: |
---|
1913 | OLD: |
---|
1914 | |
---|
1915 | M |
---|
1916 | Max-Forwards header field 36 |
---|
1917 | MIME-Version header field 89 |
---|
1918 | |
---|
1919 | NEW: |
---|
1920 | |
---|
1921 | M |
---|
1922 | Max-Forwards header field 36 |
---|
1923 | MIME-Version header field 88 |
---|
1924 | |
---|
1925 | |
---|
1926 | Section 345, paragraph 1: |
---|
1927 | OLD: |
---|
1928 | |
---|
1929 | EMail: fielding@gbiv.com |
---|
1930 | URI: http://roy.gbiv.com/ |
---|
1931 | Julian F. Reschke (editor) |
---|
1932 | greenbytes GmbH |
---|
1933 | Hafenweg 16 |
---|
1934 | Muenster, NW 48155 |
---|
1935 | Germany |
---|
1936 | |
---|
1937 | NEW: |
---|
1938 | |
---|
1939 | EMail: fielding@gbiv.com |
---|
1940 | URI: http://roy.gbiv.com/ |
---|
1941 | |
---|
1942 | Julian F. Reschke (editor) |
---|
1943 | greenbytes GmbH |
---|
1944 | Hafenweg 16 |
---|
1945 | Muenster, NW 48155 |
---|
1946 | Germany |
---|
1947 | |
---|