1 | |
---|
2 | INTRODUCTION, paragraph 1: |
---|
3 | OLD: |
---|
4 | |
---|
5 | HTTPbis Working Group R. Fielding, Ed. |
---|
6 | Internet-Draft Adobe |
---|
7 | Obsoletes: 2145,2616 (if approved) J. Reschke, Ed. |
---|
8 | Updates: 2817,2818 (if approved) greenbytes |
---|
9 | Intended status: Standards Track May 6, 2014 |
---|
10 | Expires: November 7, 2014 |
---|
11 | |
---|
12 | NEW: |
---|
13 | |
---|
14 | Internet Engineering Task Force (IETF) R. Fielding, Ed. |
---|
15 | Request for Comments: 7230 Adobe |
---|
16 | Obsoletes: 2145, 2616 J. Reschke, Ed. |
---|
17 | Updates: 2817, 2818 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): Message Syntax and Routing |
---|
26 | draft-ietf-httpbis-p1-messaging-latest |
---|
27 | |
---|
28 | NEW: |
---|
29 | |
---|
30 | Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing |
---|
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 7, 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/rfc7230. |
---|
100 | |
---|
101 | |
---|
102 | Section 11., paragraph 0: |
---|
103 | OLD: |
---|
104 | |
---|
105 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 |
---|
106 | 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 6 |
---|
107 | 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 |
---|
108 | 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 6 |
---|
109 | 2.1. Client/Server Messaging . . . . . . . . . . . . . . . . . 7 |
---|
110 | 2.2. Implementation Diversity . . . . . . . . . . . . . . . . . 8 |
---|
111 | 2.3. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 9 |
---|
112 | 2.4. Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 11 |
---|
113 | 2.5. Conformance and Error Handling . . . . . . . . . . . . . . 12 |
---|
114 | 2.6. Protocol Versioning . . . . . . . . . . . . . . . . . . . 13 |
---|
115 | 2.7. Uniform Resource Identifiers . . . . . . . . . . . . . . . 16 |
---|
116 | 2.7.1. http URI Scheme . . . . . . . . . . . . . . . . . . . 16 |
---|
117 | 2.7.2. https URI Scheme . . . . . . . . . . . . . . . . . . . 18 |
---|
118 | 2.7.3. http and https URI Normalization and Comparison . . . 19 |
---|
119 | 3. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 19 |
---|
120 | 3.1. Start Line . . . . . . . . . . . . . . . . . . . . . . . . 20 |
---|
121 | 3.1.1. Request Line . . . . . . . . . . . . . . . . . . . . . 21 |
---|
122 | 3.1.2. Status Line . . . . . . . . . . . . . . . . . . . . . 22 |
---|
123 | 3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 22 |
---|
124 | 3.2.1. Field Extensibility . . . . . . . . . . . . . . . . . 23 |
---|
125 | 3.2.2. Field Order . . . . . . . . . . . . . . . . . . . . . 23 |
---|
126 | 3.2.3. Whitespace . . . . . . . . . . . . . . . . . . . . . . 24 |
---|
127 | 3.2.4. Field Parsing . . . . . . . . . . . . . . . . . . . . 25 |
---|
128 | 3.2.5. Field Limits . . . . . . . . . . . . . . . . . . . . . 26 |
---|
129 | 3.2.6. Field Value Components . . . . . . . . . . . . . . . . 26 |
---|
130 | 3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 27 |
---|
131 | 3.3.1. Transfer-Encoding . . . . . . . . . . . . . . . . . . 28 |
---|
132 | 3.3.2. Content-Length . . . . . . . . . . . . . . . . . . . . 30 |
---|
133 | 3.3.3. Message Body Length . . . . . . . . . . . . . . . . . 31 |
---|
134 | 3.4. Handling Incomplete Messages . . . . . . . . . . . . . . . 33 |
---|
135 | 3.5. Message Parsing Robustness . . . . . . . . . . . . . . . . 34 |
---|
136 | 4. Transfer Codings . . . . . . . . . . . . . . . . . . . . . . . 35 |
---|
137 | 4.1. Chunked Transfer Coding . . . . . . . . . . . . . . . . . 35 |
---|
138 | 4.1.1. Chunk Extensions . . . . . . . . . . . . . . . . . . . 36 |
---|
139 | 4.1.2. Chunked Trailer Part . . . . . . . . . . . . . . . . . 36 |
---|
140 | 4.1.3. Decoding Chunked . . . . . . . . . . . . . . . . . . . 37 |
---|
141 | 4.2. Compression Codings . . . . . . . . . . . . . . . . . . . 38 |
---|
142 | 4.2.1. Compress Coding . . . . . . . . . . . . . . . . . . . 38 |
---|
143 | 4.2.2. Deflate Coding . . . . . . . . . . . . . . . . . . . . 38 |
---|
144 | 4.2.3. Gzip Coding . . . . . . . . . . . . . . . . . . . . . 38 |
---|
145 | 4.3. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 |
---|
146 | 4.4. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 39 |
---|
147 | 5. Message Routing . . . . . . . . . . . . . . . . . . . . . . . 40 |
---|
148 | 5.1. Identifying a Target Resource . . . . . . . . . . . . . . 40 |
---|
149 | 5.2. Connecting Inbound . . . . . . . . . . . . . . . . . . . . 40 |
---|
150 | 5.3. Request Target . . . . . . . . . . . . . . . . . . . . . . 41 |
---|
151 | 5.3.1. origin-form . . . . . . . . . . . . . . . . . . . . . 41 |
---|
152 | 5.3.2. absolute-form . . . . . . . . . . . . . . . . . . . . 42 |
---|
153 | 5.3.3. authority-form . . . . . . . . . . . . . . . . . . . . 42 |
---|
154 | 5.3.4. asterisk-form . . . . . . . . . . . . . . . . . . . . 42 |
---|
155 | 5.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 |
---|
156 | 5.5. Effective Request URI . . . . . . . . . . . . . . . . . . 44 |
---|
157 | 5.6. Associating a Response to a Request . . . . . . . . . . . 46 |
---|
158 | 5.7. Message Forwarding . . . . . . . . . . . . . . . . . . . . 46 |
---|
159 | 5.7.1. Via . . . . . . . . . . . . . . . . . . . . . . . . . 47 |
---|
160 | 5.7.2. Transformations . . . . . . . . . . . . . . . . . . . 48 |
---|
161 | 6. Connection Management . . . . . . . . . . . . . . . . . . . . 49 |
---|
162 | 6.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 50 |
---|
163 | 6.2. Establishment . . . . . . . . . . . . . . . . . . . . . . 51 |
---|
164 | 6.3. Persistence . . . . . . . . . . . . . . . . . . . . . . . 52 |
---|
165 | 6.3.1. Retrying Requests . . . . . . . . . . . . . . . . . . 53 |
---|
166 | 6.3.2. Pipelining . . . . . . . . . . . . . . . . . . . . . . 53 |
---|
167 | 6.4. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 54 |
---|
168 | 6.5. Failures and Time-outs . . . . . . . . . . . . . . . . . . 54 |
---|
169 | 6.6. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 55 |
---|
170 | 6.7. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 56 |
---|
171 | 7. ABNF List Extension: #rule . . . . . . . . . . . . . . . . . . 58 |
---|
172 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 60 |
---|
173 | 8.1. Header Field Registration . . . . . . . . . . . . . . . . 60 |
---|
174 | 8.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 60 |
---|
175 | 8.3. Internet Media Type Registration . . . . . . . . . . . . . 61 |
---|
176 | 8.3.1. Internet Media Type message/http . . . . . . . . . . . 61 |
---|
177 | 8.3.2. Internet Media Type application/http . . . . . . . . . 62 |
---|
178 | 8.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 63 |
---|
179 | 8.4.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 63 |
---|
180 | 8.4.2. Registration . . . . . . . . . . . . . . . . . . . . . 64 |
---|
181 | 8.5. Content Coding Registration . . . . . . . . . . . . . . . 64 |
---|
182 | 8.6. Upgrade Token Registry . . . . . . . . . . . . . . . . . . 65 |
---|
183 | 8.6.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 65 |
---|
184 | 8.6.2. Upgrade Token Registration . . . . . . . . . . . . . . 66 |
---|
185 | 9. Security Considerations . . . . . . . . . . . . . . . . . . . 66 |
---|
186 | 9.1. Establishing Authority . . . . . . . . . . . . . . . . . . 66 |
---|
187 | 9.2. Risks of Intermediaries . . . . . . . . . . . . . . . . . 67 |
---|
188 | 9.3. Attacks via Protocol Element Length . . . . . . . . . . . 68 |
---|
189 | 9.4. Response Splitting . . . . . . . . . . . . . . . . . . . . 68 |
---|
190 | 9.5. Request Smuggling . . . . . . . . . . . . . . . . . . . . 69 |
---|
191 | 9.6. Message Integrity . . . . . . . . . . . . . . . . . . . . 69 |
---|
192 | 9.7. Message Confidentiality . . . . . . . . . . . . . . . . . 70 |
---|
193 | 9.8. Privacy of Server Log Information . . . . . . . . . . . . 70 |
---|
194 | 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 71 |
---|
195 | 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 72 |
---|
196 | 11.1. Normative References . . . . . . . . . . . . . . . . . . . 72 |
---|
197 | 11.2. Informative References . . . . . . . . . . . . . . . . . . 74 |
---|
198 | Appendix A. HTTP Version History . . . . . . . . . . . . . . . . 76 |
---|
199 | A.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 77 |
---|
200 | A.1.1. Multi-homed Web Servers . . . . . . . . . . . . . . . 77 |
---|
201 | A.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . . 77 |
---|
202 | A.1.3. Introduction of Transfer-Encoding . . . . . . . . . . 78 |
---|
203 | A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 78 |
---|
204 | Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 80 |
---|
205 | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 |
---|
206 | |
---|
207 | NEW: |
---|
208 | |
---|
209 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 |
---|
210 | 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 6 |
---|
211 | 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 |
---|
212 | 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 6 |
---|
213 | 2.1. Client/Server Messaging . . . . . . . . . . . . . . . . . 7 |
---|
214 | 2.2. Implementation Diversity . . . . . . . . . . . . . . . . . 8 |
---|
215 | 2.3. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 9 |
---|
216 | 2.4. Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 11 |
---|
217 | 2.5. Conformance and Error Handling . . . . . . . . . . . . . . 12 |
---|
218 | 2.6. Protocol Versioning . . . . . . . . . . . . . . . . . . . 13 |
---|
219 | 2.7. Uniform Resource Identifiers . . . . . . . . . . . . . . . 16 |
---|
220 | 2.7.1. http URI Scheme . . . . . . . . . . . . . . . . . . . 16 |
---|
221 | 2.7.2. https URI Scheme . . . . . . . . . . . . . . . . . . . 18 |
---|
222 | 2.7.3. http and https URI Normalization and Comparison . . . 19 |
---|
223 | 3. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 19 |
---|
224 | 3.1. Start Line . . . . . . . . . . . . . . . . . . . . . . . . 20 |
---|
225 | 3.1.1. Request Line . . . . . . . . . . . . . . . . . . . . . 21 |
---|
226 | 3.1.2. Status Line . . . . . . . . . . . . . . . . . . . . . 22 |
---|
227 | 3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 22 |
---|
228 | 3.2.1. Field Extensibility . . . . . . . . . . . . . . . . . 23 |
---|
229 | 3.2.2. Field Order . . . . . . . . . . . . . . . . . . . . . 23 |
---|
230 | 3.2.3. Whitespace . . . . . . . . . . . . . . . . . . . . . . 24 |
---|
231 | 3.2.4. Field Parsing . . . . . . . . . . . . . . . . . . . . 25 |
---|
232 | 3.2.5. Field Limits . . . . . . . . . . . . . . . . . . . . . 26 |
---|
233 | 3.2.6. Field Value Components . . . . . . . . . . . . . . . . 26 |
---|
234 | 3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 27 |
---|
235 | 3.3.1. Transfer-Encoding . . . . . . . . . . . . . . . . . . 28 |
---|
236 | 3.3.2. Content-Length . . . . . . . . . . . . . . . . . . . . 30 |
---|
237 | 3.3.3. Message Body Length . . . . . . . . . . . . . . . . . 31 |
---|
238 | 3.4. Handling Incomplete Messages . . . . . . . . . . . . . . . 33 |
---|
239 | 3.5. Message Parsing Robustness . . . . . . . . . . . . . . . . 34 |
---|
240 | 4. Transfer Codings . . . . . . . . . . . . . . . . . . . . . . . 35 |
---|
241 | 4.1. Chunked Transfer Coding . . . . . . . . . . . . . . . . . 35 |
---|
242 | 4.1.1. Chunk Extensions . . . . . . . . . . . . . . . . . . . 36 |
---|
243 | 4.1.2. Chunked Trailer Part . . . . . . . . . . . . . . . . . 36 |
---|
244 | 4.1.3. Decoding Chunked . . . . . . . . . . . . . . . . . . . 37 |
---|
245 | 4.2. Compression Codings . . . . . . . . . . . . . . . . . . . 38 |
---|
246 | 4.2.1. Compress Coding . . . . . . . . . . . . . . . . . . . 38 |
---|
247 | 4.2.2. Deflate Coding . . . . . . . . . . . . . . . . . . . . 38 |
---|
248 | 4.2.3. Gzip Coding . . . . . . . . . . . . . . . . . . . . . 38 |
---|
249 | 4.3. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 |
---|
250 | 4.4. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 39 |
---|
251 | 5. Message Routing . . . . . . . . . . . . . . . . . . . . . . . 40 |
---|
252 | 5.1. Identifying a Target Resource . . . . . . . . . . . . . . 40 |
---|
253 | 5.2. Connecting Inbound . . . . . . . . . . . . . . . . . . . . 40 |
---|
254 | 5.3. Request Target . . . . . . . . . . . . . . . . . . . . . . 41 |
---|
255 | 5.3.1. origin-form . . . . . . . . . . . . . . . . . . . . . 41 |
---|
256 | 5.3.2. absolute-form . . . . . . . . . . . . . . . . . . . . 42 |
---|
257 | 5.3.3. authority-form . . . . . . . . . . . . . . . . . . . . 42 |
---|
258 | 5.3.4. asterisk-form . . . . . . . . . . . . . . . . . . . . 42 |
---|
259 | 5.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 |
---|
260 | 5.5. Effective Request URI . . . . . . . . . . . . . . . . . . 44 |
---|
261 | 5.6. Associating a Response to a Request . . . . . . . . . . . 46 |
---|
262 | 5.7. Message Forwarding . . . . . . . . . . . . . . . . . . . . 46 |
---|
263 | 5.7.1. Via . . . . . . . . . . . . . . . . . . . . . . . . . 47 |
---|
264 | 5.7.2. Transformations . . . . . . . . . . . . . . . . . . . 48 |
---|
265 | 6. Connection Management . . . . . . . . . . . . . . . . . . . . 49 |
---|
266 | 6.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 50 |
---|
267 | 6.2. Establishment . . . . . . . . . . . . . . . . . . . . . . 51 |
---|
268 | 6.3. Persistence . . . . . . . . . . . . . . . . . . . . . . . 52 |
---|
269 | 6.3.1. Retrying Requests . . . . . . . . . . . . . . . . . . 53 |
---|
270 | 6.3.2. Pipelining . . . . . . . . . . . . . . . . . . . . . . 53 |
---|
271 | 6.4. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 54 |
---|
272 | 6.5. Failures and Timeouts . . . . . . . . . . . . . . . . . . 54 |
---|
273 | 6.6. Teardown . . . . . . . . . . . . . . . . . . . . . . . . . 55 |
---|
274 | 6.7. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 56 |
---|
275 | 7. ABNF List Extension: #rule . . . . . . . . . . . . . . . . . . 58 |
---|
276 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 60 |
---|
277 | 8.1. Header Field Registration . . . . . . . . . . . . . . . . 60 |
---|
278 | 8.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 60 |
---|
279 | 8.3. Internet Media Type Registration . . . . . . . . . . . . . 61 |
---|
280 | 8.3.1. Internet Media Type message/http . . . . . . . . . . . 61 |
---|
281 | 8.3.2. Internet Media Type application/http . . . . . . . . . 62 |
---|
282 | 8.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 63 |
---|
283 | 8.4.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 63 |
---|
284 | 8.4.2. Registration . . . . . . . . . . . . . . . . . . . . . 64 |
---|
285 | 8.5. Content Coding Registration . . . . . . . . . . . . . . . 64 |
---|
286 | 8.6. Upgrade Token Registry . . . . . . . . . . . . . . . . . . 65 |
---|
287 | 8.6.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 65 |
---|
288 | 8.6.2. Upgrade Token Registration . . . . . . . . . . . . . . 66 |
---|
289 | 9. Security Considerations . . . . . . . . . . . . . . . . . . . 66 |
---|
290 | 9.1. Establishing Authority . . . . . . . . . . . . . . . . . . 66 |
---|
291 | 9.2. Risks of Intermediaries . . . . . . . . . . . . . . . . . 67 |
---|
292 | 9.3. Attacks via Protocol Element Length . . . . . . . . . . . 68 |
---|
293 | 9.4. Response Splitting . . . . . . . . . . . . . . . . . . . . 68 |
---|
294 | 9.5. Request Smuggling . . . . . . . . . . . . . . . . . . . . 69 |
---|
295 | 9.6. Message Integrity . . . . . . . . . . . . . . . . . . . . 69 |
---|
296 | 9.7. Message Confidentiality . . . . . . . . . . . . . . . . . 70 |
---|
297 | 9.8. Privacy of Server Log Information . . . . . . . . . . . . 70 |
---|
298 | 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 71 |
---|
299 | 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 72 |
---|
300 | 11.1. Normative References . . . . . . . . . . . . . . . . . . . 72 |
---|
301 | 11.2. Informative References . . . . . . . . . . . . . . . . . . 74 |
---|
302 | Appendix A. HTTP Version History . . . . . . . . . . . . . . . . 76 |
---|
303 | A.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 76 |
---|
304 | A.1.1. Multihomed Web Servers . . . . . . . . . . . . . . . . 77 |
---|
305 | A.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . . 77 |
---|
306 | A.1.3. Introduction of Transfer-Encoding . . . . . . . . . . 78 |
---|
307 | A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 78 |
---|
308 | Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 80 |
---|
309 | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 |
---|
310 | |
---|
311 | |
---|
312 | Section 1., paragraph 8: |
---|
313 | OLD: |
---|
314 | |
---|
315 | This HTTP/1.1 specification obsoletes RFC 2616 and RFC 2145 (on HTTP |
---|
316 | versioning). This specification also updates the use of CONNECT to |
---|
317 | establish a tunnel, previously defined in RFC 2817, and defines the |
---|
318 | "https" URI scheme that was described informally in RFC 2818. |
---|
319 | |
---|
320 | NEW: |
---|
321 | |
---|
322 | This HTTP/1.1 specification obsoletes [RFC2616] and [RFC2145] (on |
---|
323 | HTTP versioning). This specification also updates the use of |
---|
324 | CONNECT, previously defined in RFC 2817, to establish a tunnel, and |
---|
325 | defines the "https" URI scheme that was described informally in RFC |
---|
326 | 2818. |
---|
327 | |
---|
328 | |
---|
329 | Section 2.1., paragraph 1: |
---|
330 | OLD: |
---|
331 | |
---|
332 | HTTP is a stateless request/response protocol that operates by |
---|
333 | exchanging messages (Section 3) across a reliable transport or |
---|
334 | session-layer "connection" (Section 6). An HTTP "client" is a |
---|
335 | program that establishes a connection to a server for the purpose of |
---|
336 | sending one or more HTTP requests. An HTTP "server" is a program |
---|
337 | that accepts connections in order to service HTTP requests by sending |
---|
338 | HTTP responses. |
---|
339 | |
---|
340 | NEW: |
---|
341 | |
---|
342 | HTTP is a stateless request/response protocol that operates by |
---|
343 | exchanging messages (Section 3) across a reliable transport- or |
---|
344 | session-layer "connection" (Section 6). An HTTP "client" is a |
---|
345 | program that establishes a connection to a server for the purpose of |
---|
346 | sending one or more HTTP requests. An HTTP "server" is a program |
---|
347 | that accepts connections in order to service HTTP requests by sending |
---|
348 | HTTP responses. |
---|
349 | |
---|
350 | |
---|
351 | Section 2.1., paragraph 2: |
---|
352 | OLD: |
---|
353 | |
---|
354 | The terms client and server refer only to the roles that these |
---|
355 | programs perform for a particular connection. The same program might |
---|
356 | act as a client on some connections and a server on others. The term |
---|
357 | "user agent" refers to any of the various client programs that |
---|
358 | initiate a request, including (but not limited to) browsers, spiders |
---|
359 | (web-based robots), command-line tools, custom applications, and |
---|
360 | mobile apps. The term "origin server" refers to the program that can |
---|
361 | originate authoritative responses for a given target resource. The |
---|
362 | terms "sender" and "recipient" refer to any implementation that sends |
---|
363 | or receives a given message, respectively. |
---|
364 | |
---|
365 | NEW: |
---|
366 | |
---|
367 | The terms "client" and "server" refer only to the roles that these |
---|
368 | programs perform for a particular connection. The same program might |
---|
369 | act as a client on some connections and a server on others. The term |
---|
370 | "user agent" refers to any of the various client programs that |
---|
371 | initiate a request, including (but not limited to) browsers, spiders |
---|
372 | (web-based robots), command-line tools, custom applications, and |
---|
373 | mobile apps. The term "origin server" refers to the program that can |
---|
374 | originate authoritative responses for a given target resource. The |
---|
375 | terms "sender" and "recipient" refer to any implementation that sends |
---|
376 | or receives a given message, respectively. |
---|
377 | |
---|
378 | |
---|
379 | Section 2.2., paragraph 1: |
---|
380 | OLD: |
---|
381 | |
---|
382 | When considering the design of HTTP, it is easy to fall into a trap |
---|
383 | of thinking that all user agents are general-purpose browsers and all |
---|
384 | origin servers are large public websites. That is not the case in |
---|
385 | practice. Common HTTP user agents include household appliances, |
---|
386 | stereos, scales, firmware update scripts, command-line programs, |
---|
387 | mobile apps, and communication devices in a multitude of shapes and |
---|
388 | sizes. Likewise, common HTTP origin servers include home automation |
---|
389 | units, configurable networking components, office machines, |
---|
390 | autonomous robots, news feeds, traffic cameras, ad selectors, and |
---|
391 | video delivery platforms. |
---|
392 | |
---|
393 | NEW: |
---|
394 | |
---|
395 | When considering the design of HTTP, it is easy to fall into a trap |
---|
396 | of thinking that all user agents are general-purpose browsers and all |
---|
397 | origin servers are large public websites. That is not the case in |
---|
398 | practice. Common HTTP user agents include household appliances, |
---|
399 | stereos, scales, firmware update scripts, command-line programs, |
---|
400 | mobile apps, and communication devices in a multitude of shapes and |
---|
401 | sizes. Likewise, common HTTP origin servers include home automation |
---|
402 | units, configurable networking components, office machines, |
---|
403 | autonomous robots, news feeds, traffic cameras, ad selectors, and |
---|
404 | video-delivery platforms. |
---|
405 | |
---|
406 | |
---|
407 | Section 2.3., paragraph 3: |
---|
408 | OLD: |
---|
409 | |
---|
410 | The figure above shows three intermediaries (A, B, and C) between the |
---|
411 | user agent and origin server. A request or response message that |
---|
412 | travels the whole chain will pass through four separate connections. |
---|
413 | Some HTTP communication options might apply only to the connection |
---|
414 | with the nearest, non-tunnel neighbor, only to the end-points of the |
---|
415 | chain, or to all connections along the chain. Although the diagram |
---|
416 | is linear, each participant might be engaged in multiple, |
---|
417 | simultaneous communications. For example, B might be receiving |
---|
418 | requests from many clients other than A, and/or forwarding requests |
---|
419 | to servers other than C, at the same time that it is handling A's |
---|
420 | request. Likewise, later requests might be sent through a different |
---|
421 | path of connections, often based on dynamic configuration for load |
---|
422 | balancing. |
---|
423 | |
---|
424 | NEW: |
---|
425 | |
---|
426 | The figure above shows three intermediaries (A, B, and C) between the |
---|
427 | user agent and origin server. A request or response message that |
---|
428 | travels the whole chain will pass through four separate connections. |
---|
429 | Some HTTP communication options might apply only to the connection |
---|
430 | with the nearest, non-tunnel neighbor, only to the endpoints of the |
---|
431 | chain, or to all connections along the chain. Although the diagram |
---|
432 | is linear, each participant might be engaged in multiple, |
---|
433 | simultaneous communications. For example, B might be receiving |
---|
434 | requests from many clients other than A, and/or forwarding requests |
---|
435 | to servers other than C, at the same time that it is handling A's |
---|
436 | request. Likewise, later requests might be sent through a different |
---|
437 | path of connections, often based on dynamic configuration for load |
---|
438 | balancing. |
---|
439 | |
---|
440 | |
---|
441 | Section 2.3., paragraph 4: |
---|
442 | OLD: |
---|
443 | |
---|
444 | The terms "upstream" and "downstream" are used to describe |
---|
445 | directional requirements in relation to the message flow: all |
---|
446 | messages flow from upstream to downstream. The terms inbound and |
---|
447 | outbound are used to describe directional requirements in relation to |
---|
448 | the request route: "inbound" means toward the origin server and |
---|
449 | "outbound" means toward the user agent. |
---|
450 | |
---|
451 | NEW: |
---|
452 | |
---|
453 | The terms "upstream" and "downstream" are used to describe |
---|
454 | directional requirements in relation to the message flow: all |
---|
455 | messages flow from upstream to downstream. The terms "inbound" and |
---|
456 | "outbound" are used to describe directional requirements in relation |
---|
457 | to the request route: "inbound" means toward the origin server and |
---|
458 | "outbound" means toward the user agent. |
---|
459 | |
---|
460 | |
---|
461 | Section 2.3., paragraph 5: |
---|
462 | OLD: |
---|
463 | |
---|
464 | A "proxy" is a message forwarding agent that is selected by the |
---|
465 | client, usually via local configuration rules, to receive requests |
---|
466 | for some type(s) of absolute URI and attempt to satisfy those |
---|
467 | requests via translation through the HTTP interface. Some |
---|
468 | translations are minimal, such as for proxy requests for "http" URIs, |
---|
469 | whereas other requests might require translation to and from entirely |
---|
470 | different application-level protocols. Proxies are often used to |
---|
471 | group an organization's HTTP requests through a common intermediary |
---|
472 | for the sake of security, annotation services, or shared caching. |
---|
473 | Some proxies are designed to apply transformations to selected |
---|
474 | messages or payloads while they are being forwarded, as described in |
---|
475 | Section 5.7.2. |
---|
476 | |
---|
477 | NEW: |
---|
478 | |
---|
479 | A "proxy" is a message-forwarding agent that is selected by the |
---|
480 | client, usually via local configuration rules, to receive requests |
---|
481 | for some type(s) of absolute URI and attempt to satisfy those |
---|
482 | requests via translation through the HTTP interface. Some |
---|
483 | translations are minimal, such as for proxy requests for "http" URIs, |
---|
484 | whereas other requests might require translation to and from entirely |
---|
485 | different application-level protocols. Proxies are often used to |
---|
486 | group an organization's HTTP requests through a common intermediary |
---|
487 | for the sake of security, annotation services, or shared caching. |
---|
488 | Some proxies are designed to apply transformations to selected |
---|
489 | messages or payloads while they are being forwarded, as described in |
---|
490 | Section 5.7.2. |
---|
491 | |
---|
492 | |
---|
493 | Section 2.3., paragraph 6: |
---|
494 | OLD: |
---|
495 | |
---|
496 | A "gateway" (a.k.a., "reverse proxy") is an intermediary that acts as |
---|
497 | an origin server for the outbound connection, but translates received |
---|
498 | requests and forwards them inbound to another server or servers. |
---|
499 | Gateways are often used to encapsulate legacy or untrusted |
---|
500 | information services, to improve server performance through |
---|
501 | "accelerator" caching, and to enable partitioning or load balancing |
---|
502 | of HTTP services across multiple machines. |
---|
503 | |
---|
504 | NEW: |
---|
505 | |
---|
506 | A "gateway" (a.k.a. "reverse proxy") is an intermediary that acts as |
---|
507 | an origin server for the outbound connection but translates received |
---|
508 | requests and forwards them inbound to another server or servers. |
---|
509 | Gateways are often used to encapsulate legacy or untrusted |
---|
510 | information services, to improve server performance through |
---|
511 | "accelerator" caching, and to enable partitioning or load balancing |
---|
512 | of HTTP services across multiple machines. |
---|
513 | |
---|
514 | |
---|
515 | Section 2.3., paragraph 7: |
---|
516 | OLD: |
---|
517 | |
---|
518 | All HTTP requirements applicable to an origin server also apply to |
---|
519 | the outbound communication of a gateway. A gateway communicates with |
---|
520 | inbound servers using any protocol that it desires, including private |
---|
521 | extensions to HTTP that are outside the scope of this specification. |
---|
522 | However, an HTTP-to-HTTP gateway that wishes to interoperate with |
---|
523 | third-party HTTP servers ought to conform to user agent requirements |
---|
524 | on the gateway's inbound connection. |
---|
525 | |
---|
526 | NEW: |
---|
527 | |
---|
528 | All HTTP requirements applicable to an origin server also apply to |
---|
529 | the outbound communication of a gateway. A gateway communicates with |
---|
530 | inbound servers using any protocol that it desires, including private |
---|
531 | extensions to HTTP that are outside the scope of this specification. |
---|
532 | However, an HTTP-to-HTTP gateway that wishes to interoperate with |
---|
533 | third-party HTTP servers ought to conform to user-agent requirements |
---|
534 | on the gateway's inbound connection. |
---|
535 | |
---|
536 | |
---|
537 | Section 2.3., paragraph 11: |
---|
538 | OLD: |
---|
539 | |
---|
540 | HTTP is defined as a stateless protocol, meaning that each request |
---|
541 | message can be understood in isolation. Many implementations depend |
---|
542 | on HTTP's stateless design in order to reuse proxied connections or |
---|
543 | dynamically load-balance requests across multiple servers. Hence, a |
---|
544 | server MUST NOT assume that two requests on the same connection are |
---|
545 | from the same user agent unless the connection is secured and |
---|
546 | specific to that agent. Some non-standard HTTP extensions (e.g., |
---|
547 | [RFC4559]) have been known to violate this requirement, resulting in |
---|
548 | security and interoperability problems. |
---|
549 | |
---|
550 | NEW: |
---|
551 | |
---|
552 | HTTP is defined as a stateless protocol, meaning that each request |
---|
553 | message can be understood in isolation. Many implementations depend |
---|
554 | on HTTP's stateless design in order to reuse proxied connections or |
---|
555 | dynamically load balance requests across multiple servers. Hence, a |
---|
556 | server MUST NOT assume that two requests on the same connection are |
---|
557 | from the same user agent unless the connection is secured and |
---|
558 | specific to that agent. Some non-standard HTTP extensions (e.g., |
---|
559 | [RFC4559]) have been known to violate this requirement, resulting in |
---|
560 | security and interoperability problems. |
---|
561 | |
---|
562 | |
---|
563 | Section 2.4., paragraph 5: |
---|
564 | OLD: |
---|
565 | |
---|
566 | There are a wide variety of architectures and configurations of |
---|
567 | caches deployed across the World Wide Web and inside large |
---|
568 | organizations. These include national hierarchies of proxy caches to |
---|
569 | save transoceanic bandwidth, collaborative systems that broadcast or |
---|
570 | multicast cache entries, archives of pre-fetched cache entries for |
---|
571 | use in off-line or high-latency environments, and so on. |
---|
572 | |
---|
573 | NEW: |
---|
574 | |
---|
575 | There is a wide variety of architectures and configurations of caches |
---|
576 | deployed across the World Wide Web and inside large organizations. |
---|
577 | These include national hierarchies of proxy caches to save |
---|
578 | transoceanic bandwidth, collaborative systems that broadcast or |
---|
579 | multicast cache entries, archives of pre-fetched cache entries for |
---|
580 | use in off-line or high-latency environments, and so on. |
---|
581 | |
---|
582 | |
---|
583 | Section 2.5., paragraph 5: |
---|
584 | OLD: |
---|
585 | |
---|
586 | When a received protocol element is parsed, the recipient MUST be |
---|
587 | able to parse any value of reasonable length that is applicable to |
---|
588 | the recipient's role and matches the grammar defined by the |
---|
589 | corresponding ABNF rules. Note, however, that some received protocol |
---|
590 | elements might not be parsed. For example, an intermediary |
---|
591 | forwarding a message might parse a header-field into generic field- |
---|
592 | name and field-value components, but then forward the header field |
---|
593 | without further parsing inside the field-value. |
---|
594 | |
---|
595 | NEW: |
---|
596 | |
---|
597 | When a received protocol element is parsed, the recipient MUST be |
---|
598 | able to parse any value of reasonable length that is applicable to |
---|
599 | the recipient's role and that matches the grammar defined by the |
---|
600 | corresponding ABNF rules. Note, however, that some received protocol |
---|
601 | elements might not be parsed. For example, an intermediary |
---|
602 | forwarding a message might parse a header-field into generic field- |
---|
603 | name and field-value components, but then forward the header field |
---|
604 | without further parsing inside the field-value. |
---|
605 | |
---|
606 | |
---|
607 | Section 2.5., paragraph 6: |
---|
608 | OLD: |
---|
609 | |
---|
610 | HTTP does not have specific length limitations for many of its |
---|
611 | protocol elements because the lengths that might be appropriate will |
---|
612 | vary widely, depending on the deployment context and purpose of the |
---|
613 | implementation. Hence, interoperability between senders and |
---|
614 | recipients depends on shared expectations regarding what is a |
---|
615 | reasonable length for each protocol element. Furthermore, what is |
---|
616 | commonly understood to be a reasonable length for some protocol |
---|
617 | elements has changed over the course of the past two decades of HTTP |
---|
618 | use, and is expected to continue changing in the future. |
---|
619 | |
---|
620 | NEW: |
---|
621 | |
---|
622 | HTTP does not have specific length limitations for many of its |
---|
623 | protocol elements because the lengths that might be appropriate will |
---|
624 | vary widely, depending on the deployment context and purpose of the |
---|
625 | implementation. Hence, interoperability between senders and |
---|
626 | recipients depends on shared expectations regarding what is a |
---|
627 | reasonable length for each protocol element. Furthermore, what is |
---|
628 | commonly understood to be a reasonable length for some protocol |
---|
629 | elements has changed over the course of the past two decades of HTTP |
---|
630 | use and is expected to continue changing in the future. |
---|
631 | |
---|
632 | |
---|
633 | Section 2.6., paragraph 2: |
---|
634 | OLD: |
---|
635 | |
---|
636 | The version of an HTTP message is indicated by an HTTP-version field |
---|
637 | in the first line of the message. HTTP-version is case-sensitive. |
---|
638 | |
---|
639 | NEW: |
---|
640 | |
---|
641 | The version of an HTTP message is indicated by an HTTP-version field |
---|
642 | in the first line of the message. HTTP-version is case sensitive. |
---|
643 | |
---|
644 | |
---|
645 | Section 2.6., paragraph 3: |
---|
646 | OLD: |
---|
647 | |
---|
648 | HTTP-version = HTTP-name "/" DIGIT "." DIGIT |
---|
649 | HTTP-name = %x48.54.54.50 ; "HTTP", case-sensitive |
---|
650 | |
---|
651 | NEW: |
---|
652 | |
---|
653 | HTTP-version = HTTP-name "/" DIGIT "." DIGIT |
---|
654 | HTTP-name = %x48.54.54.50 ; "HTTP", case sensitive |
---|
655 | |
---|
656 | |
---|
657 | Section 2.6., paragraph 7: |
---|
658 | OLD: |
---|
659 | |
---|
660 | New header fields can be introduced without changing the protocol |
---|
661 | version if their defined semantics allow them to be safely ignored by |
---|
662 | recipients that do not recognize them. Header field extensibility is |
---|
663 | discussed in Section 3.2.1. |
---|
664 | |
---|
665 | NEW: |
---|
666 | |
---|
667 | New header fields can be introduced without changing the protocol |
---|
668 | version if their defined semantics allow them to be safely ignored by |
---|
669 | recipients that do not recognize them. Header-field extensibility is |
---|
670 | discussed in Section 3.2.1. |
---|
671 | |
---|
672 | |
---|
673 | Section 2.6., paragraph 14: |
---|
674 | OLD: |
---|
675 | |
---|
676 | When an HTTP message is received with a major version number that the |
---|
677 | recipient implements, but a higher minor version number than what the |
---|
678 | recipient implements, the recipient SHOULD process the message as if |
---|
679 | it were in the highest minor version within that major version to |
---|
680 | which the recipient is conformant. A recipient can assume that a |
---|
681 | message with a higher minor version, when sent to a recipient that |
---|
682 | has not yet indicated support for that higher version, is |
---|
683 | sufficiently backwards-compatible to be safely processed by any |
---|
684 | implementation of the same major version. |
---|
685 | |
---|
686 | NEW: |
---|
687 | |
---|
688 | When an HTTP message is received with a major version number that the |
---|
689 | recipient implements, but a higher minor version number than what the |
---|
690 | recipient implements, the recipient SHOULD process the message as if |
---|
691 | it were in the highest minor version within that major version to |
---|
692 | which the recipient is conformant. A recipient can assume that a |
---|
693 | message with a higher minor version, when sent to a recipient that |
---|
694 | has not yet indicated support for that higher version, is |
---|
695 | sufficiently backwards compatible to be safely processed by any |
---|
696 | implementation of the same major version. |
---|
697 | |
---|
698 | |
---|
699 | Section 2.7., paragraph 2: |
---|
700 | OLD: |
---|
701 | |
---|
702 | The definitions of "URI-reference", "absolute-URI", "relative-part", |
---|
703 | "scheme", "authority", "port", "host", "path-abempty", "segment", |
---|
704 | "query", and "fragment" are adopted from the URI generic syntax. An |
---|
705 | "absolute-path" rule is defined for protocol elements that can |
---|
706 | contain a non-empty path component. (This rule differs slightly from |
---|
707 | RFC 3986's path-abempty rule, which allows for an empty path to be |
---|
708 | used in references, and path-absolute rule, which does not allow |
---|
709 | paths that begin with "//".) A "partial-URI" rule is defined for |
---|
710 | protocol elements that can contain a relative URI but not a fragment |
---|
711 | component. |
---|
712 | |
---|
713 | NEW: |
---|
714 | |
---|
715 | The definitions of "URI-reference", "absolute-URI", "relative-part", |
---|
716 | "scheme", "authority", "port", "host", "path-abempty", "segment", |
---|
717 | "query", and "fragment" are adopted from the URI generic syntax. An |
---|
718 | "absolute-path" rule is defined for protocol elements that can |
---|
719 | contain a non-empty path component. (This rule differs slightly from |
---|
720 | the path-abempty rule of RFC 3986, which allows for an empty path to |
---|
721 | be used in references, and path-absolute rule, which does not allow |
---|
722 | paths that begin with "//".) A "partial-URI" rule is defined for |
---|
723 | protocol elements that can contain a relative URI but not a fragment |
---|
724 | component. |
---|
725 | |
---|
726 | |
---|
727 | Section 2.7.1., paragraph 1: |
---|
728 | OLD: |
---|
729 | |
---|
730 | The "http" URI scheme is hereby defined for the purpose of minting |
---|
731 | identifiers according to their association with the hierarchical |
---|
732 | namespace governed by a potential HTTP origin server listening for |
---|
733 | TCP ([RFC0793]) connections on a given port. |
---|
734 | |
---|
735 | NEW: |
---|
736 | |
---|
737 | The "http" URI scheme is hereby defined for the purpose of minting |
---|
738 | identifiers according to their association with the hierarchical |
---|
739 | namespace governed by a potential HTTP origin server listening for |
---|
740 | TCP ([RFC793]) connections on a given port. |
---|
741 | |
---|
742 | |
---|
743 | Section 2.1, paragraph 0: |
---|
744 | OLD: |
---|
745 | |
---|
746 | If the port is equal to the default port for a scheme, the normal |
---|
747 | form is to omit the port subcomponent. When not being used in |
---|
748 | absolute form as the request target of an OPTIONS request, an empty |
---|
749 | path component is equivalent to an absolute path of "/", so the |
---|
750 | normal form is to provide a path of "/" instead. The scheme and host |
---|
751 | are case-insensitive and normally provided in lowercase; all other |
---|
752 | components are compared in a case-sensitive manner. Characters other |
---|
753 | than those in the "reserved" set are equivalent to their percent- |
---|
754 | encoded octets: the normal form is to not encode them (see Sections |
---|
755 | 2.1 and 2.2 of [RFC3986]). |
---|
756 | |
---|
757 | NEW: |
---|
758 | |
---|
759 | If the port is equal to the default port for a scheme, the normal |
---|
760 | form is to omit the port subcomponent. When not being used in |
---|
761 | absolute form as the request target of an OPTIONS request, an empty |
---|
762 | path component is equivalent to an absolute path of "/", so the |
---|
763 | normal form is to provide a path of "/" instead. The scheme and host |
---|
764 | are case insensitive and normally provided in lowercase; all other |
---|
765 | components are compared in a case-sensitive manner. Characters other |
---|
766 | than those in the "reserved" set are equivalent to their percent- |
---|
767 | encoded octets: the normal form is to not encode them (see Sections |
---|
768 | 2.1 and 2.2 of [RFC3986]). |
---|
769 | |
---|
770 | |
---|
771 | Section 3.1., paragraph 1: |
---|
772 | OLD: |
---|
773 | |
---|
774 | An HTTP message can either be a request from client to server or a |
---|
775 | response from server to client. Syntactically, the two types of |
---|
776 | message differ only in the start-line, which is either a request-line |
---|
777 | (for requests) or a status-line (for responses), and in the algorithm |
---|
778 | for determining the length of the message body (Section 3.3). |
---|
779 | |
---|
780 | NEW: |
---|
781 | |
---|
782 | An HTTP message can be either a request from client to server or a |
---|
783 | response from server to client. Syntactically, the two types of |
---|
784 | message differ only in the start-line, which is either a request-line |
---|
785 | (for requests) or a status-line (for responses), and in the algorithm |
---|
786 | for determining the length of the message body (Section 3.3). |
---|
787 | |
---|
788 | |
---|
789 | Section 3.1., paragraph 2: |
---|
790 | OLD: |
---|
791 | |
---|
792 | In theory, a client could receive requests and a server could receive |
---|
793 | responses, distinguishing them by their different start-line formats, |
---|
794 | but in practice servers are implemented to only expect a request (a |
---|
795 | response is interpreted as an unknown or invalid request method) and |
---|
796 | clients are implemented to only expect a response. |
---|
797 | |
---|
798 | NEW: |
---|
799 | |
---|
800 | In theory, a client could receive requests and a server could receive |
---|
801 | responses, distinguishing them by their different start-line formats, |
---|
802 | but, in practice, servers are implemented only to expect a request (a |
---|
803 | response is interpreted as an unknown or invalid request method) and |
---|
804 | clients are implemented to only expect a response. |
---|
805 | |
---|
806 | |
---|
807 | Section 3.1.1., paragraph 1: |
---|
808 | OLD: |
---|
809 | |
---|
810 | A request-line begins with a method token, followed by a single space |
---|
811 | (SP), the request-target, another single space (SP), the protocol |
---|
812 | version, and ending with CRLF. |
---|
813 | |
---|
814 | NEW: |
---|
815 | |
---|
816 | A request-line begins with a method token and is followed by a single |
---|
817 | space (SP), the request-target, another single space (SP), the |
---|
818 | protocol version, and ends with CRLF. |
---|
819 | |
---|
820 | |
---|
821 | Section 3.1.1., paragraph 3: |
---|
822 | OLD: |
---|
823 | |
---|
824 | The method token indicates the request method to be performed on the |
---|
825 | target resource. The request method is case-sensitive. |
---|
826 | |
---|
827 | NEW: |
---|
828 | |
---|
829 | The method token indicates the request method to be performed on the |
---|
830 | target resource. The request method is case sensitive. |
---|
831 | |
---|
832 | |
---|
833 | Section 400, paragraph 1: |
---|
834 | OLD: |
---|
835 | |
---|
836 | HTTP does not place a pre-defined limit on the length of a request- |
---|
837 | line, as described in Section 2.5. A server that receives a method |
---|
838 | longer than any that it implements SHOULD respond with a 501 (Not |
---|
839 | Implemented) status code. A server that receives a request-target |
---|
840 | longer than any URI it wishes to parse MUST respond with a 414 (URI |
---|
841 | Too Long) status code (see Section 6.5.12 of [RFC7231]). |
---|
842 | |
---|
843 | NEW: |
---|
844 | |
---|
845 | HTTP does not place a predefined limit on the length of a request- |
---|
846 | line, as described in Section 2.5. A server that receives a method |
---|
847 | longer than any that it implements SHOULD respond with a 501 (Not |
---|
848 | Implemented) status code. A server that receives a request-target |
---|
849 | longer than any URI it wishes to parse MUST respond with a 414 (URI |
---|
850 | Too Long) status code (see Section 6.5.12 of [RFC7231]). |
---|
851 | |
---|
852 | |
---|
853 | Section 400, paragraph 2: |
---|
854 | OLD: |
---|
855 | |
---|
856 | Various ad-hoc limitations on request-line length are found in |
---|
857 | practice. It is RECOMMENDED that all HTTP senders and recipients |
---|
858 | support, at a minimum, request-line lengths of 8000 octets. |
---|
859 | |
---|
860 | NEW: |
---|
861 | |
---|
862 | Various ad hoc limitations on request-line length are found in |
---|
863 | practice. It is RECOMMENDED that all HTTP senders and recipients |
---|
864 | support, at a minimum, request-line lengths of 8000 octets. |
---|
865 | |
---|
866 | |
---|
867 | Section 3.1.2., paragraph 1: |
---|
868 | OLD: |
---|
869 | |
---|
870 | The first line of a response message is the status-line, consisting |
---|
871 | of the protocol version, a space (SP), the status code, another |
---|
872 | space, a possibly-empty textual phrase describing the status code, |
---|
873 | and ending with CRLF. |
---|
874 | |
---|
875 | NEW: |
---|
876 | |
---|
877 | The first line of a response message is the status-line, consisting |
---|
878 | of the protocol version, a space (SP), the status code, another space |
---|
879 | (SP), a possibly empty textual phrase describing the status code, |
---|
880 | and, finally, CRLF. |
---|
881 | |
---|
882 | |
---|
883 | Section 3.2.1., paragraph 4: |
---|
884 | OLD: |
---|
885 | |
---|
886 | All defined header fields ought to be registered with IANA in the |
---|
887 | Message Header Field Registry, as described in Section 8.3 of |
---|
888 | [RFC7231]. |
---|
889 | |
---|
890 | NEW: |
---|
891 | |
---|
892 | All defined header fields ought to be registered with IANA in the |
---|
893 | "Message Headers" field registry, as described in Section 8.3 of |
---|
894 | [RFC7231]. |
---|
895 | |
---|
896 | |
---|
897 | Section 3.2.2., paragraph 4: |
---|
898 | OLD: |
---|
899 | |
---|
900 | Note: In practice, the "Set-Cookie" header field ([RFC6265]) often |
---|
901 | appears multiple times in a response message and does not use the |
---|
902 | list syntax, violating the above requirements on multiple header |
---|
903 | fields with the same name. Since it cannot be combined into a |
---|
904 | single field-value, recipients ought to handle "Set-Cookie" as a |
---|
905 | special case while processing header fields. (See Appendix A.2.3 |
---|
906 | of [Kri2001] for details.) |
---|
907 | |
---|
908 | NEW: |
---|
909 | |
---|
910 | Note: In practice, the "Set-Cookie" header field ([RFC6265]) often |
---|
911 | appears multiple times in a response message and does not use the |
---|
912 | list syntax, violating the above requirements on multiple header |
---|
913 | fields with the same name. Since it cannot be combined into a |
---|
914 | single field-value, recipients ought to handle Set-Cookie as a |
---|
915 | special case while processing header fields. (See Appendix A.2.3 |
---|
916 | of [Kri2001] for details.) |
---|
917 | |
---|
918 | |
---|
919 | Section 3.2.3., paragraph 2: |
---|
920 | OLD: |
---|
921 | |
---|
922 | The OWS rule is used where zero or more linear whitespace octets |
---|
923 | might appear. For protocol elements where optional whitespace is |
---|
924 | preferred to improve readability, a sender SHOULD generate the |
---|
925 | optional whitespace as a single SP; otherwise, a sender SHOULD NOT |
---|
926 | generate optional whitespace except as needed to white-out invalid or |
---|
927 | unwanted protocol elements during in-place message filtering. |
---|
928 | |
---|
929 | NEW: |
---|
930 | |
---|
931 | The OWS rule is used where zero or more linear whitespace octets |
---|
932 | might appear. For protocol elements where optional whitespace is |
---|
933 | preferred to improve readability, a sender SHOULD generate the |
---|
934 | optional whitespace as a single SP; otherwise, a sender SHOULD NOT |
---|
935 | generate optional whitespace except as needed to white out invalid or |
---|
936 | unwanted protocol elements during in-place message filtering. |
---|
937 | |
---|
938 | |
---|
939 | Section 3.2.4., paragraph 1: |
---|
940 | OLD: |
---|
941 | |
---|
942 | Messages are parsed using a generic algorithm, independent of the |
---|
943 | individual header field names. The contents within a given field |
---|
944 | value are not parsed until a later stage of message interpretation |
---|
945 | (usually after the message's entire header section has been |
---|
946 | processed). Consequently, this specification does not use ABNF rules |
---|
947 | to define each "Field-Name: Field Value" pair, as was done in |
---|
948 | previous editions. Instead, this specification uses ABNF rules which |
---|
949 | are named according to each registered field name, wherein the rule |
---|
950 | defines the valid grammar for that field's corresponding field values |
---|
951 | (i.e., after the field-value has been extracted from the header |
---|
952 | section by a generic field parser). |
---|
953 | |
---|
954 | NEW: |
---|
955 | |
---|
956 | Messages are parsed using a generic algorithm, independent of the |
---|
957 | individual header field names. The contents within a given field |
---|
958 | value are not parsed until a later stage of message interpretation |
---|
959 | (usually after the message's entire header section has been |
---|
960 | processed). Consequently, this specification does not use ABNF rules |
---|
961 | to define each "field-name: field-value" pair, as was done in |
---|
962 | previous editions. Instead, this specification uses ABNF rules that |
---|
963 | are named according to each registered field name, wherein the rule |
---|
964 | defines the valid grammar for that field's corresponding field values |
---|
965 | (i.e., after the field-value has been extracted from the header |
---|
966 | section by a generic field parser). |
---|
967 | |
---|
968 | |
---|
969 | Section 3.2.4., paragraph 8: |
---|
970 | OLD: |
---|
971 | |
---|
972 | Historically, HTTP has allowed field content with text in the ISO- |
---|
973 | 8859-1 [ISO-8859-1] charset, supporting other charsets only through |
---|
974 | use of [RFC2047] encoding. In practice, most HTTP header field |
---|
975 | values use only a subset of the US-ASCII charset [USASCII]. Newly |
---|
976 | defined header fields SHOULD limit their field values to US-ASCII |
---|
977 | octets. A recipient SHOULD treat other octets in field content (obs- |
---|
978 | text) as opaque data. |
---|
979 | |
---|
980 | NEW: |
---|
981 | |
---|
982 | Historically, HTTP has allowed field content with text in the |
---|
983 | ISO-8859-1 [ISO-8859-1] charset, supporting other charsets only |
---|
984 | through use of [RFC2047] encoding. In practice, most HTTP header |
---|
985 | field values use only a subset of the US-ASCII charset [USASCII]. |
---|
986 | Newly defined header fields SHOULD limit their field values to |
---|
987 | US-ASCII octets. A recipient SHOULD treat other octets in field |
---|
988 | content (obs-text) as opaque data. |
---|
989 | |
---|
990 | |
---|
991 | Section 3.2.5., paragraph 1: |
---|
992 | OLD: |
---|
993 | |
---|
994 | HTTP does not place a pre-defined limit on the length of each header |
---|
995 | field or on the length of the header section as a whole, as described |
---|
996 | in Section 2.5. Various ad-hoc limitations on individual header |
---|
997 | field length are found in practice, often depending on the specific |
---|
998 | field semantics. |
---|
999 | |
---|
1000 | NEW: |
---|
1001 | |
---|
1002 | HTTP does not place a predefined limit on the length of each header |
---|
1003 | field or on the length of the header section as a whole, as described |
---|
1004 | in Section 2.5. Various ad hoc limitations on individual header |
---|
1005 | field length are found in practice, often depending on the specific |
---|
1006 | field semantics. |
---|
1007 | |
---|
1008 | |
---|
1009 | Section 7., paragraph 1: |
---|
1010 | OLD: |
---|
1011 | |
---|
1012 | Since there is no way to distinguish a successfully completed, close- |
---|
1013 | delimited message from a partially-received message interrupted by |
---|
1014 | network failure, a server SHOULD generate encoding or length- |
---|
1015 | delimited messages whenever possible. The close-delimiting feature |
---|
1016 | exists primarily for backwards compatibility with HTTP/1.0. |
---|
1017 | |
---|
1018 | NEW: |
---|
1019 | |
---|
1020 | Since there is no way to distinguish a successfully completed, close- |
---|
1021 | delimited message from a partially received message interrupted by |
---|
1022 | network failure, a server SHOULD generate encoding or length- |
---|
1023 | delimited messages whenever possible. The close-delimiting feature |
---|
1024 | exists primarily for backwards compatibility with HTTP/1.0. |
---|
1025 | |
---|
1026 | |
---|
1027 | Section 3.4., paragraph 1: |
---|
1028 | OLD: |
---|
1029 | |
---|
1030 | A server that receives an incomplete request message, usually due to |
---|
1031 | a canceled request or a triggered time-out exception, MAY send an |
---|
1032 | error response prior to closing the connection. |
---|
1033 | |
---|
1034 | NEW: |
---|
1035 | |
---|
1036 | A server that receives an incomplete request message, usually due to |
---|
1037 | a canceled request or a triggered timeout exception, MAY send an |
---|
1038 | error response prior to closing the connection. |
---|
1039 | |
---|
1040 | |
---|
1041 | Section 3.4., paragraph 4: |
---|
1042 | OLD: |
---|
1043 | |
---|
1044 | A message body that uses the chunked transfer coding is incomplete if |
---|
1045 | the zero-sized chunk that terminates the encoding has not been |
---|
1046 | received. A message that uses a valid Content-Length is incomplete |
---|
1047 | if the size of the message body received (in octets) is less than the |
---|
1048 | value given by Content-Length. A response that has neither chunked |
---|
1049 | transfer coding nor Content-Length is terminated by closure of the |
---|
1050 | connection, and thus is considered complete regardless of the number |
---|
1051 | of message body octets received, provided that the header section was |
---|
1052 | received intact. |
---|
1053 | |
---|
1054 | NEW: |
---|
1055 | |
---|
1056 | A message body that uses the chunked transfer coding is incomplete if |
---|
1057 | the zero-sized chunk that terminates the encoding has not been |
---|
1058 | received. A message that uses a valid Content-Length is incomplete |
---|
1059 | if the size of the message body received (in octets) is less than the |
---|
1060 | value given by Content-Length. A response that has neither chunked |
---|
1061 | transfer coding nor Content-Length is terminated by closure of the |
---|
1062 | connection and, thus, is considered complete regardless of the number |
---|
1063 | of message body octets received, provided that the header section was |
---|
1064 | received intact. |
---|
1065 | |
---|
1066 | |
---|
1067 | Section 4., paragraph 5: |
---|
1068 | OLD: |
---|
1069 | |
---|
1070 | All transfer-coding names are case-insensitive and ought to be |
---|
1071 | registered within the HTTP Transfer Coding registry, as defined in |
---|
1072 | Section 8.4. They are used in the TE (Section 4.3) and Transfer- |
---|
1073 | Encoding (Section 3.3.1) header fields. |
---|
1074 | |
---|
1075 | NEW: |
---|
1076 | |
---|
1077 | All transfer-coding names are case insensitive and ought to be |
---|
1078 | registered within the "HTTP Transfer Coding" registry, as defined in |
---|
1079 | Section 8.4. They are used in the TE (Section 4.3) and Transfer- |
---|
1080 | Encoding (Section 3.3.1) header fields. |
---|
1081 | |
---|
1082 | |
---|
1083 | Section 4.2.3., paragraph 1: |
---|
1084 | OLD: |
---|
1085 | |
---|
1086 | The "gzip" coding is an LZ77 coding with a 32 bit CRC that is |
---|
1087 | commonly produced by the gzip file compression program [RFC1952]. A |
---|
1088 | recipient SHOULD consider "x-gzip" to be equivalent to "gzip". |
---|
1089 | |
---|
1090 | NEW: |
---|
1091 | |
---|
1092 | The "gzip" coding is an LZ77 coding with a 32-bit Cyclic Redundancy |
---|
1093 | Check (CRC) that is commonly produced by the gzip file compression |
---|
1094 | program [RFC1952]. A recipient SHOULD consider "x-gzip" to be |
---|
1095 | equivalent to "gzip". |
---|
1096 | |
---|
1097 | |
---|
1098 | Section 5.7.1., paragraph 8: |
---|
1099 | OLD: |
---|
1100 | |
---|
1101 | A sender MAY generate comments in the Via header field to identify |
---|
1102 | the software of each recipient, analogous to the User-Agent and |
---|
1103 | Server header fields. However, all comments in the Via field are |
---|
1104 | optional and a recipient MAY remove them prior to forwarding the |
---|
1105 | message. |
---|
1106 | |
---|
1107 | NEW: |
---|
1108 | |
---|
1109 | A sender MAY generate comments in the Via header field to identify |
---|
1110 | the software of each recipient, analogous to the User-Agent and |
---|
1111 | Server header fields. However, all comments in the Via field are |
---|
1112 | optional, and a recipient MAY remove them prior to forwarding the |
---|
1113 | message. |
---|
1114 | |
---|
1115 | |
---|
1116 | Section 5.7.2., paragraph 6: |
---|
1117 | OLD: |
---|
1118 | |
---|
1119 | A proxy MUST NOT transform the payload (Section 3.3 of [RFC7231]) of |
---|
1120 | a message that contains a no-transform cache-control directive |
---|
1121 | (Section 5.2 of [RFC7234]). |
---|
1122 | |
---|
1123 | NEW: |
---|
1124 | |
---|
1125 | A proxy MUST NOT transform the payload (Section 3.3 of [RFC7231]) of |
---|
1126 | a message that contains a no-transform Cache-Control directive |
---|
1127 | (Section 5.2 of [RFC7234]). |
---|
1128 | |
---|
1129 | |
---|
1130 | Section 200, paragraph 0: |
---|
1131 | OLD: |
---|
1132 | |
---|
1133 | A proxy MAY transform the payload of a message that does not contain |
---|
1134 | a no-transform cache-control directive. A proxy that transforms a |
---|
1135 | payload MUST add a Warning header field with the warn-code of 214 |
---|
1136 | ("Transformation Applied") if one is not already in the message (see |
---|
1137 | Section 5.5 of [RFC7234]). A proxy that transforms the payload of a |
---|
1138 | 200 (OK) response can further inform downstream recipients that a |
---|
1139 | transformation has been applied by changing the response status code |
---|
1140 | to 203 (Non-Authoritative Information) (Section 6.3.4 of [RFC7231]). |
---|
1141 | |
---|
1142 | NEW: |
---|
1143 | |
---|
1144 | A proxy MAY transform the payload of a message that does not contain |
---|
1145 | a no-transform Cache-Control directive. A proxy that transforms a |
---|
1146 | payload MUST add a Warning header field with the warn-code of 214 |
---|
1147 | ("Transformation Applied") if one is not already in the message (see |
---|
1148 | Section 5.5 of [RFC7234]). A proxy that transforms the payload of a |
---|
1149 | 200 (OK) response can further inform downstream recipients that a |
---|
1150 | transformation has been applied by changing the response status code |
---|
1151 | to 203 (Non-Authoritative Information) (Section 6.3.4 of [RFC7231]). |
---|
1152 | |
---|
1153 | |
---|
1154 | Section 6., paragraph 1: |
---|
1155 | OLD: |
---|
1156 | |
---|
1157 | HTTP messaging is independent of the underlying transport or session- |
---|
1158 | layer connection protocol(s). HTTP only presumes a reliable |
---|
1159 | transport with in-order delivery of requests and the corresponding |
---|
1160 | in-order delivery of responses. The mapping of HTTP request and |
---|
1161 | response structures onto the data units of an underlying transport |
---|
1162 | protocol is outside the scope of this specification. |
---|
1163 | |
---|
1164 | NEW: |
---|
1165 | |
---|
1166 | HTTP messaging is independent of the underlying transport- or |
---|
1167 | session-layer connection protocol(s). HTTP only presumes a reliable |
---|
1168 | transport with in-order delivery of requests and the corresponding |
---|
1169 | in-order delivery of responses. The mapping of HTTP request and |
---|
1170 | response structures onto the data units of an underlying transport |
---|
1171 | protocol is outside the scope of this specification. |
---|
1172 | |
---|
1173 | |
---|
1174 | Section 6., paragraph 3: |
---|
1175 | OLD: |
---|
1176 | |
---|
1177 | HTTP implementations are expected to engage in connection management, |
---|
1178 | which includes maintaining the state of current connections, |
---|
1179 | establishing a new connection or reusing an existing connection, |
---|
1180 | processing messages received on a connection, detecting connection |
---|
1181 | failures, and closing each connection. Most clients maintain |
---|
1182 | multiple connections in parallel, including more than one connection |
---|
1183 | per server endpoint. Most servers are designed to maintain thousands |
---|
1184 | of concurrent connections, while controlling request queues to enable |
---|
1185 | fair use and detect denial of service attacks. |
---|
1186 | |
---|
1187 | NEW: |
---|
1188 | |
---|
1189 | HTTP implementations are expected to engage in connection management, |
---|
1190 | which includes maintaining the state of current connections, |
---|
1191 | establishing a new connection or reusing an existing connection, |
---|
1192 | processing messages received on a connection, detecting connection |
---|
1193 | failures, and closing each connection. Most clients maintain |
---|
1194 | multiple connections in parallel, including more than one connection |
---|
1195 | per server endpoint. Most servers are designed to maintain thousands |
---|
1196 | of concurrent connections, while controlling request queues to enable |
---|
1197 | fair use and detect denial-of-service attacks. |
---|
1198 | |
---|
1199 | |
---|
1200 | Section 6.1., paragraph 6: |
---|
1201 | OLD: |
---|
1202 | |
---|
1203 | Connection options are case-insensitive. |
---|
1204 | |
---|
1205 | NEW: |
---|
1206 | |
---|
1207 | Connection options are case insensitive. |
---|
1208 | |
---|
1209 | |
---|
1210 | Section 6.2., paragraph 1: |
---|
1211 | OLD: |
---|
1212 | |
---|
1213 | It is beyond the scope of this specification to describe how |
---|
1214 | connections are established via various transport or session-layer |
---|
1215 | protocols. Each connection applies to only one transport link. |
---|
1216 | |
---|
1217 | NEW: |
---|
1218 | |
---|
1219 | It is beyond the scope of this specification to describe how |
---|
1220 | connections are established via various transport- or session-layer |
---|
1221 | protocols. Each connection applies to only one transport link. |
---|
1222 | |
---|
1223 | |
---|
1224 | Section 6.3., paragraph 1: |
---|
1225 | OLD: |
---|
1226 | |
---|
1227 | HTTP/1.1 defaults to the use of "persistent connections", allowing |
---|
1228 | multiple requests and responses to be carried over a single |
---|
1229 | connection. The "close" connection-option is used to signal that a |
---|
1230 | connection will not persist after the current request/response. HTTP |
---|
1231 | implementations SHOULD support persistent connections. |
---|
1232 | |
---|
1233 | NEW: |
---|
1234 | |
---|
1235 | HTTP/1.1 defaults to the use of "persistent connections", allowing |
---|
1236 | multiple requests and responses to be carried over a single |
---|
1237 | connection. The "close" connection option is used to signal that a |
---|
1238 | connection will not persist after the current request/response. HTTP |
---|
1239 | implementations SHOULD support persistent connections. |
---|
1240 | |
---|
1241 | |
---|
1242 | Section 6.3., paragraph 3: |
---|
1243 | OLD: |
---|
1244 | |
---|
1245 | o If the close connection option is present, the connection will not |
---|
1246 | persist after the current response; else, |
---|
1247 | |
---|
1248 | NEW: |
---|
1249 | |
---|
1250 | o If the "close" connection option is present, the connection will |
---|
1251 | not persist after the current response; else, |
---|
1252 | |
---|
1253 | |
---|
1254 | Section 6.3., paragraph 7: |
---|
1255 | OLD: |
---|
1256 | |
---|
1257 | A client MAY send additional requests on a persistent connection |
---|
1258 | until it sends or receives a close connection option or receives an |
---|
1259 | HTTP/1.0 response without a "keep-alive" connection option. |
---|
1260 | |
---|
1261 | NEW: |
---|
1262 | |
---|
1263 | A client MAY send additional requests on a persistent connection |
---|
1264 | until it sends or receives a "close" connection option or receives an |
---|
1265 | HTTP/1.0 response without a "keep-alive" connection option. |
---|
1266 | |
---|
1267 | |
---|
1268 | Section 6.3., paragraph 10: |
---|
1269 | OLD: |
---|
1270 | |
---|
1271 | See Appendix A.1.2 for more information on backward compatibility |
---|
1272 | with HTTP/1.0 clients. |
---|
1273 | |
---|
1274 | NEW: |
---|
1275 | |
---|
1276 | See Appendix A.1.2 for more information on backwards compatibility |
---|
1277 | with HTTP/1.0 clients. |
---|
1278 | |
---|
1279 | |
---|
1280 | Section 6.3.2., paragraph 1: |
---|
1281 | OLD: |
---|
1282 | |
---|
1283 | A client that supports persistent connections MAY "pipeline" its |
---|
1284 | requests (i.e., send multiple requests without waiting for each |
---|
1285 | response). A server MAY process a sequence of pipelined requests in |
---|
1286 | parallel if they all have safe methods (Section 4.2.1 of [RFC7231]), |
---|
1287 | but MUST send the corresponding responses in the same order that the |
---|
1288 | requests were received. |
---|
1289 | |
---|
1290 | NEW: |
---|
1291 | |
---|
1292 | A client that supports persistent connections MAY "pipeline" its |
---|
1293 | requests (i.e., send multiple requests without waiting for each |
---|
1294 | response). A server MAY process a sequence of pipelined requests in |
---|
1295 | parallel if they all have safe methods (Section 4.2.1 of [RFC7231]), |
---|
1296 | but it MUST send the corresponding responses in the same order that |
---|
1297 | the requests were received. |
---|
1298 | |
---|
1299 | |
---|
1300 | Section 6.4., paragraph 2: |
---|
1301 | OLD: |
---|
1302 | |
---|
1303 | Previous revisions of HTTP gave a specific number of connections as a |
---|
1304 | ceiling, but this was found to be impractical for many applications. |
---|
1305 | As a result, this specification does not mandate a particular maximum |
---|
1306 | number of connections, but instead encourages clients to be |
---|
1307 | conservative when opening multiple connections. |
---|
1308 | |
---|
1309 | NEW: |
---|
1310 | |
---|
1311 | Previous revisions of HTTP gave a specific number of connections as a |
---|
1312 | ceiling, but this was found to be impractical for many applications. |
---|
1313 | As a result, this specification does not mandate a particular maximum |
---|
1314 | number of connections but, instead, encourages clients to be |
---|
1315 | conservative when opening multiple connections. |
---|
1316 | |
---|
1317 | |
---|
1318 | Section 6.4., paragraph 4: |
---|
1319 | OLD: |
---|
1320 | |
---|
1321 | Note that a server might reject traffic that it deems abusive or |
---|
1322 | characteristic of a denial of service attack, such as an excessive |
---|
1323 | number of open connections from a single client. |
---|
1324 | |
---|
1325 | NEW: |
---|
1326 | |
---|
1327 | Note that a server might reject traffic that it deems abusive or |
---|
1328 | characteristic of a denial-of-service attack, such as an excessive |
---|
1329 | number of open connections from a single client. |
---|
1330 | |
---|
1331 | |
---|
1332 | Section 6.4., paragraph 5: |
---|
1333 | OLD: |
---|
1334 | |
---|
1335 | 6.5. Failures and Time-outs |
---|
1336 | |
---|
1337 | NEW: |
---|
1338 | |
---|
1339 | 6.5. Failures and Timeouts |
---|
1340 | |
---|
1341 | |
---|
1342 | Section 6.4., paragraph 6: |
---|
1343 | OLD: |
---|
1344 | |
---|
1345 | Servers will usually have some time-out value beyond which they will |
---|
1346 | no longer maintain an inactive connection. Proxy servers might make |
---|
1347 | this a higher value since it is likely that the client will be making |
---|
1348 | more connections through the same proxy server. The use of |
---|
1349 | persistent connections places no requirements on the length (or |
---|
1350 | existence) of this time-out for either the client or the server. |
---|
1351 | |
---|
1352 | NEW: |
---|
1353 | |
---|
1354 | Servers will usually have some timeout value beyond which they will |
---|
1355 | no longer maintain an inactive connection. Proxy servers might make |
---|
1356 | this a higher value since it is likely that the client will be making |
---|
1357 | more connections through the same proxy server. The use of |
---|
1358 | persistent connections places no requirements on the length (or |
---|
1359 | existence) of this timeout for either the client or the server. |
---|
1360 | |
---|
1361 | |
---|
1362 | Section 6.4., paragraph 7: |
---|
1363 | OLD: |
---|
1364 | |
---|
1365 | A client or server that wishes to time-out SHOULD issue a graceful |
---|
1366 | close on the connection. Implementations SHOULD constantly monitor |
---|
1367 | open connections for a received closure signal and respond to it as |
---|
1368 | appropriate, since prompt closure of both sides of a connection |
---|
1369 | enables allocated system resources to be reclaimed. |
---|
1370 | |
---|
1371 | NEW: |
---|
1372 | |
---|
1373 | A client or server that wishes to time out SHOULD issue a graceful |
---|
1374 | close on the connection. Implementations SHOULD constantly monitor |
---|
1375 | open connections for a received closure signal and respond to it as |
---|
1376 | appropriate, since prompt closure of both sides of a connection |
---|
1377 | enables allocated system resources to be reclaimed. |
---|
1378 | |
---|
1379 | |
---|
1380 | Section 6.4., paragraph 9: |
---|
1381 | OLD: |
---|
1382 | |
---|
1383 | A server SHOULD sustain persistent connections, when possible, and |
---|
1384 | allow the underlying transport's flow control mechanisms to resolve |
---|
1385 | temporary overloads, rather than terminate connections with the |
---|
1386 | expectation that clients will retry. The latter technique can |
---|
1387 | exacerbate network congestion. |
---|
1388 | |
---|
1389 | NEW: |
---|
1390 | |
---|
1391 | A server SHOULD sustain persistent connections, when possible, and |
---|
1392 | allow the underlying transport's flow-control mechanisms to resolve |
---|
1393 | temporary overloads, rather than terminate connections with the |
---|
1394 | expectation that clients will retry. The latter technique can |
---|
1395 | exacerbate network congestion. |
---|
1396 | |
---|
1397 | |
---|
1398 | Section 6.4., paragraph 11: |
---|
1399 | OLD: |
---|
1400 | |
---|
1401 | 6.6. Tear-down |
---|
1402 | |
---|
1403 | NEW: |
---|
1404 | |
---|
1405 | 6.6. Teardown |
---|
1406 | |
---|
1407 | |
---|
1408 | Section 6.4., paragraph 13: |
---|
1409 | OLD: |
---|
1410 | |
---|
1411 | A client that sends a close connection option MUST NOT send further |
---|
1412 | requests on that connection (after the one containing close) and MUST |
---|
1413 | close the connection after reading the final response message |
---|
1414 | corresponding to this request. |
---|
1415 | |
---|
1416 | NEW: |
---|
1417 | |
---|
1418 | A client that sends a "close" connection option MUST NOT send further |
---|
1419 | requests on that connection (after the one containing close) and MUST |
---|
1420 | close the connection after reading the final response message |
---|
1421 | corresponding to this request. |
---|
1422 | |
---|
1423 | |
---|
1424 | Section 6.4., paragraph 14: |
---|
1425 | OLD: |
---|
1426 | |
---|
1427 | A server that receives a close connection option MUST initiate a |
---|
1428 | close of the connection (see below) after it sends the final response |
---|
1429 | to the request that contained close. The server SHOULD send a close |
---|
1430 | connection option in its final response on that connection. The |
---|
1431 | server MUST NOT process any further requests received on that |
---|
1432 | connection. |
---|
1433 | |
---|
1434 | NEW: |
---|
1435 | |
---|
1436 | A server that receives a "close" connection option MUST initiate a |
---|
1437 | close of the connection (see below) after it sends the final response |
---|
1438 | to the request that contained close. The server SHOULD send a close |
---|
1439 | connection option in its final response on that connection. The |
---|
1440 | server MUST NOT process any further requests received on that |
---|
1441 | connection. |
---|
1442 | |
---|
1443 | |
---|
1444 | Section 6.4., paragraph 15: |
---|
1445 | OLD: |
---|
1446 | |
---|
1447 | A server that sends a close connection option MUST initiate a close |
---|
1448 | of the connection (see below) after it sends the response containing |
---|
1449 | close. The server MUST NOT process any further requests received on |
---|
1450 | that connection. |
---|
1451 | |
---|
1452 | NEW: |
---|
1453 | |
---|
1454 | A server that sends a "close" connection option MUST initiate a close |
---|
1455 | of the connection (see below) after it sends the response containing |
---|
1456 | close. The server MUST NOT process any further requests received on |
---|
1457 | that connection. |
---|
1458 | |
---|
1459 | |
---|
1460 | Section 6.4., paragraph 16: |
---|
1461 | OLD: |
---|
1462 | |
---|
1463 | A client that receives a close connection option MUST cease sending |
---|
1464 | requests on that connection and close the connection after reading |
---|
1465 | the response message containing the close; if additional pipelined |
---|
1466 | requests had been sent on the connection, the client SHOULD NOT |
---|
1467 | assume that they will be processed by the server. |
---|
1468 | |
---|
1469 | NEW: |
---|
1470 | |
---|
1471 | A client that receives a "close" connection option MUST cease sending |
---|
1472 | requests on that connection and close the connection after reading |
---|
1473 | the response message containing the close; if additional pipelined |
---|
1474 | requests had been sent on the connection, the client SHOULD NOT |
---|
1475 | assume that they will be processed by the server. |
---|
1476 | |
---|
1477 | |
---|
1478 | Section 6.4., paragraph 17: |
---|
1479 | OLD: |
---|
1480 | |
---|
1481 | If a server performs an immediate close of a TCP connection, there is |
---|
1482 | a significant risk that the client will not be able to read the last |
---|
1483 | HTTP response. If the server receives additional data from the |
---|
1484 | client on a fully-closed connection, such as another request that was |
---|
1485 | sent by the client before receiving the server's response, the |
---|
1486 | server's TCP stack will send a reset packet to the client; |
---|
1487 | unfortunately, the reset packet might erase the client's |
---|
1488 | unacknowledged input buffers before they can be read and interpreted |
---|
1489 | by the client's HTTP parser. |
---|
1490 | |
---|
1491 | NEW: |
---|
1492 | |
---|
1493 | If a server performs an immediate close of a TCP connection, there is |
---|
1494 | a significant risk that the client will not be able to read the last |
---|
1495 | HTTP response. If the server receives additional data from the |
---|
1496 | client on a fully closed connection, such as another request that was |
---|
1497 | sent by the client before receiving the server's response, the |
---|
1498 | server's TCP stack will send a reset packet to the client; |
---|
1499 | unfortunately, the reset packet might erase the client's |
---|
1500 | unacknowledged input buffers before they can be read and interpreted |
---|
1501 | by the client's HTTP parser. |
---|
1502 | |
---|
1503 | |
---|
1504 | Section 6.7., paragraph 9: |
---|
1505 | OLD: |
---|
1506 | |
---|
1507 | The capabilities and nature of the application-level communication |
---|
1508 | after the protocol change is entirely dependent upon the new |
---|
1509 | protocol(s) chosen. However, immediately after sending the 101 |
---|
1510 | response, the server is expected to continue responding to the |
---|
1511 | original request as if it had received its equivalent within the new |
---|
1512 | protocol (i.e., the server still has an outstanding request to |
---|
1513 | satisfy after the protocol has been changed, and is expected to do so |
---|
1514 | without requiring the request to be repeated). |
---|
1515 | |
---|
1516 | NEW: |
---|
1517 | |
---|
1518 | The capabilities and nature of the application-level communication |
---|
1519 | after the protocol change is entirely dependent upon the new |
---|
1520 | protocol(s) chosen. However, immediately after sending the 101 |
---|
1521 | (Switching Protocols) response, the server is expected to continue |
---|
1522 | responding to the original request as if it had received its |
---|
1523 | equivalent within the new protocol (i.e., the server still has an |
---|
1524 | outstanding request to satisfy after the protocol has been changed, |
---|
1525 | and is expected to do so without requiring the request to be |
---|
1526 | repeated). |
---|
1527 | |
---|
1528 | |
---|
1529 | Section 101, paragraph 0: |
---|
1530 | OLD: |
---|
1531 | |
---|
1532 | For example, if the Upgrade header field is received in a GET request |
---|
1533 | and the server decides to switch protocols, it first responds with a |
---|
1534 | 101 (Switching Protocols) message in HTTP/1.1 and then immediately |
---|
1535 | follows that with the new protocol's equivalent of a response to a |
---|
1536 | GET on the target resource. This allows a connection to be upgraded |
---|
1537 | to protocols with the same semantics as HTTP without the latency cost |
---|
1538 | of an additional round-trip. A server MUST NOT switch protocols |
---|
1539 | unless the received message semantics can be honored by the new |
---|
1540 | protocol; an OPTIONS request can be honored by any protocol. |
---|
1541 | |
---|
1542 | NEW: |
---|
1543 | |
---|
1544 | For example, if the Upgrade header field is received in a GET request |
---|
1545 | and the server decides to switch protocols, it first responds with a |
---|
1546 | 101 (Switching Protocols) message in HTTP/1.1 and then immediately |
---|
1547 | follows that with the new protocol's equivalent of a response to a |
---|
1548 | GET on the target resource. This allows a connection to be upgraded |
---|
1549 | to protocols with the same semantics as HTTP without the latency cost |
---|
1550 | of an additional round trip. A server MUST NOT switch protocols |
---|
1551 | unless the received message semantics can be honored by the new |
---|
1552 | protocol; an OPTIONS request can be honored by any protocol. |
---|
1553 | |
---|
1554 | |
---|
1555 | Section 101, paragraph 5: |
---|
1556 | OLD: |
---|
1557 | |
---|
1558 | A client cannot begin using an upgraded protocol on the connection |
---|
1559 | until it has completely sent the request message (i.e., the client |
---|
1560 | can't change the protocol it is sending in the middle of a message). |
---|
1561 | If a server receives both Upgrade and an Expect header field with the |
---|
1562 | "100-continue" expectation (Section 5.1.1 of [RFC7231]), the server |
---|
1563 | MUST send a 100 (Continue) response before sending a 101 (Switching |
---|
1564 | Protocols) response. |
---|
1565 | |
---|
1566 | NEW: |
---|
1567 | |
---|
1568 | A client cannot begin using an upgraded protocol on the connection |
---|
1569 | until it has completely sent the request message (i.e., the client |
---|
1570 | can't change the protocol it is sending in the middle of a message). |
---|
1571 | If a server receives both an Upgrade and an Expect header field with |
---|
1572 | the "100-continue" expectation (Section 5.1.1 of [RFC7231]), the |
---|
1573 | server MUST send a 100 (Continue) response before sending a 101 |
---|
1574 | (Switching Protocols) response. |
---|
1575 | |
---|
1576 | |
---|
1577 | Section 7., paragraph 9: |
---|
1578 | OLD: |
---|
1579 | |
---|
1580 | For compatibility with legacy list rules, a recipient MUST parse and |
---|
1581 | ignore a reasonable number of empty list elements: enough to handle |
---|
1582 | common mistakes by senders that merge values, but not so much that |
---|
1583 | they could be used as a denial of service mechanism. In other words, |
---|
1584 | a recipient MUST accept lists that satisfy the following syntax: |
---|
1585 | |
---|
1586 | NEW: |
---|
1587 | |
---|
1588 | For compatibility with legacy list rules, a recipient MUST parse and |
---|
1589 | ignore a reasonable number of empty list elements: enough to handle |
---|
1590 | common mistakes by senders that merge values, but not so much that |
---|
1591 | they could be used as a denial-of-service mechanism. In other words, |
---|
1592 | a recipient MUST accept lists that satisfy the following syntax: |
---|
1593 | |
---|
1594 | |
---|
1595 | Section 7., paragraph 14: |
---|
1596 | OLD: |
---|
1597 | |
---|
1598 | Then the following are valid values for example-list (not including |
---|
1599 | the double quotes, which are present for delimitation only): |
---|
1600 | |
---|
1601 | NEW: |
---|
1602 | |
---|
1603 | Then, the following are valid values for example-list (not including |
---|
1604 | the double quotes, which are present for delimitation only): |
---|
1605 | |
---|
1606 | |
---|
1607 | Section 8.1., paragraph 1: |
---|
1608 | OLD: |
---|
1609 | |
---|
1610 | HTTP header fields are registered within the Message Header Field |
---|
1611 | Registry maintained at |
---|
1612 | <http://www.iana.org/assignments/message-headers/>. |
---|
1613 | |
---|
1614 | NEW: |
---|
1615 | |
---|
1616 | HTTP header fields are registered within the "Message Header" field |
---|
1617 | registry maintained at |
---|
1618 | <http://www.iana.org/assignments/message-headers/>. |
---|
1619 | |
---|
1620 | |
---|
1621 | Section 8.1., paragraph 2: |
---|
1622 | OLD: |
---|
1623 | |
---|
1624 | This document defines the following HTTP header fields, so their |
---|
1625 | associated registry entries shall be updated according to the |
---|
1626 | permanent registrations below (see [BCP90]): |
---|
1627 | |
---|
1628 | NEW: |
---|
1629 | |
---|
1630 | This document defines the following HTTP header fields, so the |
---|
1631 | "Permanent Message Header Field Names" registry has been updated |
---|
1632 | accordingly (see [BCP90]). |
---|
1633 | |
---|
1634 | |
---|
1635 | Section 8.1., paragraph 4: |
---|
1636 | OLD: |
---|
1637 | |
---|
1638 | Furthermore, the header field-name "Close" shall be registered as |
---|
1639 | "reserved", since using that name as an HTTP header field might |
---|
1640 | conflict with the "close" connection option of the "Connection" |
---|
1641 | header field (Section 6.1). |
---|
1642 | |
---|
1643 | NEW: |
---|
1644 | |
---|
1645 | Furthermore, the header field-name "Close" has been registered as |
---|
1646 | "reserved", since using that name as an HTTP header field might |
---|
1647 | conflict with the "close" connection option of the "Connection" |
---|
1648 | header field (Section 6.1). |
---|
1649 | |
---|
1650 | |
---|
1651 | Section 8.2., paragraph 2: |
---|
1652 | OLD: |
---|
1653 | |
---|
1654 | This document defines the following URI schemes, so their associated |
---|
1655 | registry entries shall be updated according to the permanent |
---|
1656 | registrations below: |
---|
1657 | |
---|
1658 | NEW: |
---|
1659 | |
---|
1660 | This document defines the following URI schemes, so the "Permanent |
---|
1661 | URI Schemes" registry has been updated accordingly. |
---|
1662 | |
---|
1663 | |
---|
1664 | Section 8.3., paragraph 2: |
---|
1665 | OLD: |
---|
1666 | |
---|
1667 | This document serves as the specification for the Internet media |
---|
1668 | types "message/http" and "application/http". The following is to be |
---|
1669 | registered with IANA. |
---|
1670 | |
---|
1671 | NEW: |
---|
1672 | |
---|
1673 | This document serves as the specification for the Internet media |
---|
1674 | types "message/http" and "application/http". The following has been |
---|
1675 | registered with IANA. |
---|
1676 | |
---|
1677 | |
---|
1678 | Section 8.3.1., paragraph 18: |
---|
1679 | OLD: |
---|
1680 | |
---|
1681 | Person and email address to contact for further information: See |
---|
1682 | Authors Section. |
---|
1683 | |
---|
1684 | NEW: |
---|
1685 | |
---|
1686 | Person and email address to contact for further information: |
---|
1687 | See Authors' Addresses Section. |
---|
1688 | |
---|
1689 | |
---|
1690 | Section 8.3.1., paragraph 21: |
---|
1691 | OLD: |
---|
1692 | |
---|
1693 | Author: See Authors Section. |
---|
1694 | |
---|
1695 | NEW: |
---|
1696 | |
---|
1697 | Author: See Authors' Addresses Section. |
---|
1698 | |
---|
1699 | |
---|
1700 | Section 8.3.2., paragraph 8: |
---|
1701 | OLD: |
---|
1702 | |
---|
1703 | Encoding considerations: HTTP messages enclosed by this type are in |
---|
1704 | "binary" format; use of an appropriate Content-Transfer-Encoding |
---|
1705 | is required when transmitted via E-mail. |
---|
1706 | |
---|
1707 | NEW: |
---|
1708 | |
---|
1709 | Encoding considerations: HTTP messages enclosed by this type are in |
---|
1710 | "binary" format; use of an appropriate Content-Transfer-Encoding |
---|
1711 | is required when transmitted via email. |
---|
1712 | |
---|
1713 | |
---|
1714 | Section 8.3.2., paragraph 19: |
---|
1715 | OLD: |
---|
1716 | |
---|
1717 | Person and email address to contact for further information: See |
---|
1718 | Authors Section. |
---|
1719 | |
---|
1720 | NEW: |
---|
1721 | |
---|
1722 | Person and email address to contact for further information: |
---|
1723 | See Authors' Addresses Section. |
---|
1724 | |
---|
1725 | |
---|
1726 | Section 8.3.2., paragraph 22: |
---|
1727 | OLD: |
---|
1728 | |
---|
1729 | Author: See Authors Section. |
---|
1730 | |
---|
1731 | NEW: |
---|
1732 | |
---|
1733 | Author: See Authors' Addresses Section. |
---|
1734 | |
---|
1735 | |
---|
1736 | Section 8.4., paragraph 1: |
---|
1737 | OLD: |
---|
1738 | |
---|
1739 | The HTTP Transfer Coding Registry defines the name space for transfer |
---|
1740 | coding names. It is maintained at |
---|
1741 | <http://www.iana.org/assignments/http-parameters>. |
---|
1742 | |
---|
1743 | NEW: |
---|
1744 | |
---|
1745 | The "HTTP Transfer Coding" registry defines the namespace for |
---|
1746 | transfer coding names. It is maintained at |
---|
1747 | <http://www.iana.org/assignments/http-parameters>. |
---|
1748 | |
---|
1749 | |
---|
1750 | Section 8.4.1., paragraph 5: |
---|
1751 | OLD: |
---|
1752 | |
---|
1753 | Values to be added to this name space require IETF Review (see |
---|
1754 | Section 4.1 of [RFC5226]), and MUST conform to the purpose of |
---|
1755 | transfer coding defined in this specification. |
---|
1756 | |
---|
1757 | NEW: |
---|
1758 | |
---|
1759 | Values to be added to this namespace require IETF Review (see Section |
---|
1760 | 4.1 of [RFC5226]), and MUST conform to the purpose of transfer coding |
---|
1761 | defined in this specification. |
---|
1762 | |
---|
1763 | |
---|
1764 | Section 8.4.2., paragraph 1: |
---|
1765 | OLD: |
---|
1766 | |
---|
1767 | The HTTP Transfer Coding Registry shall be updated with the |
---|
1768 | registrations below: |
---|
1769 | |
---|
1770 | NEW: |
---|
1771 | |
---|
1772 | The "HTTP Transfer Coding Registry" has been updated with the |
---|
1773 | registrations below: |
---|
1774 | |
---|
1775 | |
---|
1776 | Section 8.5., paragraph 1: |
---|
1777 | OLD: |
---|
1778 | |
---|
1779 | IANA maintains the registry of HTTP Content Codings at |
---|
1780 | <http://www.iana.org/assignments/http-parameters>. |
---|
1781 | |
---|
1782 | NEW: |
---|
1783 | |
---|
1784 | IANA maintains the "HTTP Content Coding Registry" at |
---|
1785 | <http://www.iana.org/assignments/http-parameters>. |
---|
1786 | |
---|
1787 | |
---|
1788 | Section 8.5., paragraph 2: |
---|
1789 | OLD: |
---|
1790 | |
---|
1791 | The HTTP Content Codings Registry shall be updated with the |
---|
1792 | registrations below: |
---|
1793 | |
---|
1794 | NEW: |
---|
1795 | |
---|
1796 | The "HTTP Content Codings Registry" has been updated with the |
---|
1797 | registrations below: |
---|
1798 | |
---|
1799 | |
---|
1800 | Section 8.6., paragraph 1: |
---|
1801 | OLD: |
---|
1802 | |
---|
1803 | The HTTP Upgrade Token Registry defines the name space for protocol- |
---|
1804 | name tokens used to identify protocols in the Upgrade header field. |
---|
1805 | The registry is maintained at |
---|
1806 | <http://www.iana.org/assignments/http-upgrade-tokens>. |
---|
1807 | |
---|
1808 | NEW: |
---|
1809 | |
---|
1810 | The "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry" |
---|
1811 | defines the namespace for protocol-name tokens used to identify |
---|
1812 | protocols in the Upgrade header field. The registry is maintained at |
---|
1813 | <http://www.iana.org/assignments/http-upgrade-tokens>. |
---|
1814 | |
---|
1815 | |
---|
1816 | Section 8.6.2., paragraph 1: |
---|
1817 | OLD: |
---|
1818 | |
---|
1819 | The "HTTP" entry in the HTTP Upgrade Token Registry shall be updated |
---|
1820 | with the registration below: |
---|
1821 | |
---|
1822 | NEW: |
---|
1823 | |
---|
1824 | The "HTTP" entry in the "HTTP Upgrade Token" registry shall be |
---|
1825 | updated with the registration below: |
---|
1826 | |
---|
1827 | |
---|
1828 | Section 9.1., paragraph 3: |
---|
1829 | OLD: |
---|
1830 | |
---|
1831 | When a registered name is used in the authority component, the "http" |
---|
1832 | URI scheme (Section 2.7.1) relies on the user's local name resolution |
---|
1833 | service to determine where it can find authoritative responses. This |
---|
1834 | means that any attack on a user's network host table, cached names, |
---|
1835 | or name resolution libraries becomes an avenue for attack on |
---|
1836 | establishing authority. Likewise, the user's choice of server for |
---|
1837 | Domain Name Service (DNS), and the hierarchy of servers from which it |
---|
1838 | obtains resolution results, could impact the authenticity of address |
---|
1839 | mappings; DNSSEC ([RFC4033]) is one way to improve authenticity. |
---|
1840 | |
---|
1841 | NEW: |
---|
1842 | |
---|
1843 | When a registered name is used in the authority component, the "http" |
---|
1844 | URI scheme (Section 2.7.1) relies on the user's local name resolution |
---|
1845 | service to determine where it can find authoritative responses. This |
---|
1846 | means that any attack on a user's network host table, cached names, |
---|
1847 | or name resolution libraries becomes an avenue for attack on |
---|
1848 | establishing authority. Likewise, the user's choice of server for |
---|
1849 | Domain Name Service (DNS), and the hierarchy of servers from which it |
---|
1850 | obtains resolution results, could impact the authenticity of address |
---|
1851 | mappings; DNS Security Extensions (DNSSEC) ([RFC4033]) is one way to |
---|
1852 | improve authenticity. |
---|
1853 | |
---|
1854 | |
---|
1855 | Section 9.2., paragraph 1: |
---|
1856 | OLD: |
---|
1857 | |
---|
1858 | By their very nature, HTTP intermediaries are men-in-the-middle, and |
---|
1859 | thus represent an opportunity for man-in-the-middle attacks. |
---|
1860 | Compromise of the systems on which the intermediaries run can result |
---|
1861 | in serious security and privacy problems. Intermediaries might have |
---|
1862 | access to security-related information, personal information about |
---|
1863 | individual users and organizations, and proprietary information |
---|
1864 | belonging to users and content providers. A compromised |
---|
1865 | intermediary, or an intermediary implemented or configured without |
---|
1866 | regard to security and privacy considerations, might be used in the |
---|
1867 | commission of a wide range of potential attacks. |
---|
1868 | |
---|
1869 | NEW: |
---|
1870 | |
---|
1871 | By their very nature, HTTP intermediaries are men in the middle and, |
---|
1872 | thus, represent an opportunity for man-in-the-middle attacks. |
---|
1873 | Compromise of the systems on which the intermediaries run can result |
---|
1874 | in serious security and privacy problems. Intermediaries might have |
---|
1875 | access to security-related information, personal information about |
---|
1876 | individual users and organizations, and proprietary information |
---|
1877 | belonging to users and content providers. A compromised |
---|
1878 | intermediary, or an intermediary implemented or configured without |
---|
1879 | regard to security and privacy considerations, might be used in the |
---|
1880 | commission of a wide range of potential attacks. |
---|
1881 | |
---|
1882 | |
---|
1883 | Section 9.3., paragraph 4: |
---|
1884 | OLD: |
---|
1885 | |
---|
1886 | Recipients ought to carefully limit the extent to which they process |
---|
1887 | other protocol elements, including (but not limited to) request |
---|
1888 | methods, response status phrases, header field-names, numeric values, |
---|
1889 | and body chunks. Failure to limit such processing can result in |
---|
1890 | buffer overflows, arithmetic overflows, or increased vulnerability to |
---|
1891 | denial of service attacks. |
---|
1892 | |
---|
1893 | NEW: |
---|
1894 | |
---|
1895 | Recipients ought to carefully limit the extent to which they process |
---|
1896 | other protocol elements, including (but not limited to) request |
---|
1897 | methods, response status phrases, header field-names, numeric values, |
---|
1898 | and body chunks. Failure to limit such processing can result in |
---|
1899 | buffer overflows, arithmetic overflows, or increased vulnerability to |
---|
1900 | denial-of-service attacks. |
---|
1901 | |
---|
1902 | |
---|
1903 | Section 9.6., paragraph 2: |
---|
1904 | OLD: |
---|
1905 | |
---|
1906 | User agents are encouraged to implement configurable means for |
---|
1907 | detecting and reporting failures of message integrity such that those |
---|
1908 | means can be enabled within environments for which integrity is |
---|
1909 | necessary. For example, a browser being used to view medical history |
---|
1910 | or drug interaction information needs to indicate to the user when |
---|
1911 | such information is detected by the protocol to be incomplete, |
---|
1912 | expired, or corrupted during transfer. Such mechanisms might be |
---|
1913 | selectively enabled via user agent extensions or the presence of |
---|
1914 | message integrity metadata in a response. At a minimum, user agents |
---|
1915 | ought to provide some indication that allows a user to distinguish |
---|
1916 | between a complete and incomplete response message (Section 3.4) when |
---|
1917 | such verification is desired. |
---|
1918 | |
---|
1919 | NEW: |
---|
1920 | |
---|
1921 | User agents are encouraged to implement configurable means for |
---|
1922 | detecting and reporting failures of message integrity such that those |
---|
1923 | means can be enabled within environments for which integrity is |
---|
1924 | necessary. For example, a browser being used to view medical history |
---|
1925 | or drug interaction information needs to indicate to the user when |
---|
1926 | such information is detected by the protocol to be incomplete, |
---|
1927 | expired, or corrupted during transfer. Such mechanisms might be |
---|
1928 | selectively enabled via user-agent extensions or the presence of |
---|
1929 | message integrity metadata in a response. At a minimum, user agents |
---|
1930 | ought to provide some indication that allows a user to distinguish |
---|
1931 | between a complete and incomplete response message (Section 3.4) when |
---|
1932 | such verification is desired. |
---|
1933 | |
---|
1934 | |
---|
1935 | Section 9.8., paragraph 2: |
---|
1936 | OLD: |
---|
1937 | |
---|
1938 | HTTP log information is confidential in nature; its handling is often |
---|
1939 | constrained by laws and regulations. Log information needs to be |
---|
1940 | securely stored and appropriate guidelines followed for its analysis. |
---|
1941 | Anonymization of personal information within individual entries |
---|
1942 | helps, but is generally not sufficient to prevent real log traces |
---|
1943 | from being re-identified based on correlation with other access |
---|
1944 | characteristics. As such, access traces that are keyed to a specific |
---|
1945 | client are unsafe to publish even if the key is pseudonymous. |
---|
1946 | |
---|
1947 | NEW: |
---|
1948 | |
---|
1949 | HTTP log information is confidential in nature; its handling is often |
---|
1950 | constrained by laws and regulations. Log information needs to be |
---|
1951 | securely stored and appropriate guidelines followed for its analysis. |
---|
1952 | Anonymization of personal information within individual entries |
---|
1953 | helps, but it is generally not sufficient to prevent real log traces |
---|
1954 | from being re-identified based on correlation with other access |
---|
1955 | characteristics. As such, access traces that are keyed to a specific |
---|
1956 | client are unsafe to publish even if the key is pseudonymous. |
---|
1957 | |
---|
1958 | |
---|
1959 | Section 10., paragraph 1: |
---|
1960 | OLD: |
---|
1961 | |
---|
1962 | This edition of HTTP/1.1 builds on the many contributions that went |
---|
1963 | into RFC 1945, RFC 2068, RFC 2145, and RFC 2616, including |
---|
1964 | substantial contributions made by the previous authors, editors, and |
---|
1965 | working group chairs: Tim Berners-Lee, Ari Luotonen, Roy T. Fielding, |
---|
1966 | Henrik Frystyk Nielsen, Jim Gettys, Jeffrey C. Mogul, Larry Masinter, |
---|
1967 | and Paul J. Leach. Mark Nottingham oversaw this effort as working |
---|
1968 | group chair. |
---|
1969 | |
---|
1970 | NEW: |
---|
1971 | |
---|
1972 | This edition of HTTP/1.1 builds on the many contributions that went |
---|
1973 | into RFC 1945, RFC 2068, RFC 2145, and RFC 2616, including |
---|
1974 | substantial contributions made by the previous authors, editors, and |
---|
1975 | Working Group Chairs: Tim Berners-Lee, Ari Luotonen, Roy T. Fielding, |
---|
1976 | Henrik Frystyk Nielsen, Jim Gettys, Jeffrey C. Mogul, Larry Masinter, |
---|
1977 | and Paul J. Leach. Mark Nottingham oversaw this effort as Working |
---|
1978 | Group Chair. |
---|
1979 | |
---|
1980 | |
---|
1981 | Section 11.1., paragraph 1: |
---|
1982 | OLD: |
---|
1983 | |
---|
1984 | [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, |
---|
1985 | RFC 793, September 1981. |
---|
1986 | |
---|
1987 | [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data |
---|
1988 | Format Specification version 3.3", RFC 1950, May 1996. |
---|
1989 | |
---|
1990 | NEW: |
---|
1991 | |
---|
1992 | [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data |
---|
1993 | Format Specification version 3.3", RFC 1950, May 1996. |
---|
1994 | |
---|
1995 | |
---|
1996 | Section 11.1., paragraph 7: |
---|
1997 | OLD: |
---|
1998 | |
---|
1999 | [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext |
---|
2000 | Transfer Protocol (HTTP/1.1): Semantics and Content", |
---|
2001 | draft-ietf-httpbis-p2-semantics-latest (work in |
---|
2002 | progress), May 2014. |
---|
2003 | |
---|
2004 | NEW: |
---|
2005 | |
---|
2006 | [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext |
---|
2007 | Transfer Protocol (HTTP/1.1): Semantics and Content", |
---|
2008 | RFC 7231, May 2014. |
---|
2009 | |
---|
2010 | |
---|
2011 | Section 11.1., paragraph 8: |
---|
2012 | OLD: |
---|
2013 | |
---|
2014 | [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext |
---|
2015 | Transfer Protocol (HTTP/1.1): Conditional Requests", |
---|
2016 | draft-ietf-httpbis-p4-conditional-latest (work in |
---|
2017 | progress), May 2014. |
---|
2018 | |
---|
2019 | NEW: |
---|
2020 | |
---|
2021 | [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext |
---|
2022 | Transfer Protocol (HTTP/1.1): Conditional Requests", |
---|
2023 | RFC 7232, May 2014. |
---|
2024 | |
---|
2025 | |
---|
2026 | Section 11.1., paragraph 9: |
---|
2027 | OLD: |
---|
2028 | |
---|
2029 | [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., |
---|
2030 | "Hypertext Transfer Protocol (HTTP/1.1): Range |
---|
2031 | Requests", draft-ietf-httpbis-p5-range-latest (work in |
---|
2032 | progress), May 2014. |
---|
2033 | |
---|
2034 | NEW: |
---|
2035 | |
---|
2036 | [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., |
---|
2037 | "Hypertext Transfer Protocol (HTTP/1.1): Range |
---|
2038 | Requests", RFC 7233, May 2014. |
---|
2039 | |
---|
2040 | |
---|
2041 | Section 11.1., paragraph 10: |
---|
2042 | OLD: |
---|
2043 | |
---|
2044 | [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, |
---|
2045 | Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", |
---|
2046 | draft-ietf-httpbis-p6-cache-latest (work in progress), |
---|
2047 | May 2014. |
---|
2048 | |
---|
2049 | NEW: |
---|
2050 | |
---|
2051 | [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, |
---|
2052 | Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", |
---|
2053 | RFC 7234, May 2014. |
---|
2054 | |
---|
2055 | |
---|
2056 | Section 11.1., paragraph 11: |
---|
2057 | OLD: |
---|
2058 | |
---|
2059 | [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext |
---|
2060 | Transfer Protocol (HTTP/1.1): Authentication", |
---|
2061 | draft-ietf-httpbis-p7-auth-latest (work in progress), |
---|
2062 | May 2014. |
---|
2063 | |
---|
2064 | NEW: |
---|
2065 | |
---|
2066 | [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext |
---|
2067 | Transfer Protocol (HTTP/1.1): Authentication", |
---|
2068 | RFC 7235, May 2014. |
---|
2069 | |
---|
2070 | [RFC793] Postel, J., "Transmission Control Protocol", STD 7, |
---|
2071 | RFC 793, September 1981. |
---|
2072 | |
---|
2073 | |
---|
2074 | Section 11.1., paragraph 13: |
---|
2075 | OLD: |
---|
2076 | |
---|
2077 | [Welch] Welch, T., "A Technique for High Performance Data |
---|
2078 | Compression", IEEE Computer 17(6), June 1984. |
---|
2079 | |
---|
2080 | NEW: |
---|
2081 | |
---|
2082 | [Welch] Welch, T., "A Technique for High-Performance Data |
---|
2083 | Compression", IEEE Computer 17(6), June 1984. |
---|
2084 | |
---|
2085 | |
---|
2086 | Appendix A., paragraph 1: |
---|
2087 | OLD: |
---|
2088 | |
---|
2089 | HTTP has been in use since 1990. The first version, later referred |
---|
2090 | to as HTTP/0.9, was a simple protocol for hypertext data transfer |
---|
2091 | across the Internet, using only a single request method (GET) and no |
---|
2092 | metadata. HTTP/1.0, as defined by [RFC1945], added a range of |
---|
2093 | request methods and MIME-like messaging, allowing for metadata to be |
---|
2094 | transferred and modifiers placed on the request/response semantics. |
---|
2095 | However, HTTP/1.0 did not sufficiently take into consideration the |
---|
2096 | effects of hierarchical proxies, caching, the need for persistent |
---|
2097 | connections, or name-based virtual hosts. The proliferation of |
---|
2098 | incompletely-implemented applications calling themselves "HTTP/1.0" |
---|
2099 | further necessitated a protocol version change in order for two |
---|
2100 | communicating applications to determine each other's true |
---|
2101 | capabilities. |
---|
2102 | |
---|
2103 | NEW: |
---|
2104 | |
---|
2105 | HTTP has been in use since 1990. The first version, later referred |
---|
2106 | to as HTTP/0.9, was a simple protocol for hypertext data transfer |
---|
2107 | across the Internet, using only a single request method (GET) and no |
---|
2108 | metadata. HTTP/1.0, as defined by [RFC1945], added a range of |
---|
2109 | request methods and MIME-like messaging, allowing for metadata to be |
---|
2110 | transferred and modifiers placed on the request/response semantics. |
---|
2111 | However, HTTP/1.0 did not sufficiently take into consideration the |
---|
2112 | effects of hierarchical proxies, caching, the need for persistent |
---|
2113 | connections, or name-based virtual hosts. The proliferation of |
---|
2114 | incompletely implemented applications calling themselves "HTTP/1.0" |
---|
2115 | further necessitated a protocol version change in order for two |
---|
2116 | communicating applications to determine each other's true |
---|
2117 | capabilities. |
---|
2118 | |
---|
2119 | |
---|
2120 | Appendix A., paragraph 2: |
---|
2121 | OLD: |
---|
2122 | |
---|
2123 | HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent |
---|
2124 | requirements that enable reliable implementations, adding only those |
---|
2125 | features that can either be safely ignored by an HTTP/1.0 recipient |
---|
2126 | or only sent when communicating with a party advertising conformance |
---|
2127 | with HTTP/1.1. |
---|
2128 | |
---|
2129 | NEW: |
---|
2130 | |
---|
2131 | HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent |
---|
2132 | requirements that enable reliable implementations, adding only those |
---|
2133 | features that can either be safely ignored by an HTTP/1.0 recipient |
---|
2134 | or only be sent when communicating with a party advertising |
---|
2135 | conformance with HTTP/1.1. |
---|
2136 | |
---|
2137 | |
---|
2138 | Appendix A., paragraph 7: |
---|
2139 | OLD: |
---|
2140 | |
---|
2141 | A.1.1. Multi-homed Web Servers |
---|
2142 | |
---|
2143 | NEW: |
---|
2144 | |
---|
2145 | A.1.1. Multihomed Web Servers |
---|
2146 | |
---|
2147 | |
---|
2148 | Section 19.7.1, paragraph 8: |
---|
2149 | OLD: |
---|
2150 | |
---|
2151 | HTTP's approach to error handling has been explained. (Section 2.5) |
---|
2152 | |
---|
2153 | NEW: |
---|
2154 | |
---|
2155 | HTTP's approach to error handling has been explained (Section 2.5). |
---|
2156 | |
---|
2157 | |
---|
2158 | Section 19.7.1, paragraph 9: |
---|
2159 | OLD: |
---|
2160 | |
---|
2161 | The HTTP-version ABNF production has been clarified to be case- |
---|
2162 | sensitive. Additionally, version numbers has been restricted to |
---|
2163 | single digits, due to the fact that implementations are known to |
---|
2164 | handle multi-digit version numbers incorrectly. (Section 2.6) |
---|
2165 | |
---|
2166 | NEW: |
---|
2167 | |
---|
2168 | The HTTP-version ABNF production has been clarified to be case |
---|
2169 | sensitive. Additionally, version numbers have been restricted to |
---|
2170 | single digits, due to the fact that implementations are known to |
---|
2171 | handle multi-digit version numbers incorrectly (Section 2.6). |
---|
2172 | |
---|
2173 | |
---|
2174 | Section 19.7.1, paragraph 10: |
---|
2175 | OLD: |
---|
2176 | |
---|
2177 | Userinfo (i.e., username and password) are now disallowed in HTTP and |
---|
2178 | HTTPS URIs, because of security issues related to their transmission |
---|
2179 | on the wire. (Section 2.7.1) |
---|
2180 | |
---|
2181 | NEW: |
---|
2182 | |
---|
2183 | Userinfo (i.e., username and password) are now disallowed in HTTP and |
---|
2184 | HTTPS URIs, because of security issues related to their transmission |
---|
2185 | on the wire (Section 2.7.1). |
---|
2186 | |
---|
2187 | |
---|
2188 | Section 19.7.1, paragraph 11: |
---|
2189 | OLD: |
---|
2190 | |
---|
2191 | The HTTPS URI scheme is now defined by this specification; |
---|
2192 | previously, it was done in Section 2.4 of [RFC2818]. Furthermore, it |
---|
2193 | implies end-to-end security. (Section 2.7.2) |
---|
2194 | |
---|
2195 | NEW: |
---|
2196 | |
---|
2197 | The HTTPS URI scheme is now defined by this specification; |
---|
2198 | previously, it was defined in Section 2.4 of [RFC2818]. Furthermore, |
---|
2199 | it implies end-to-end security (Section 2.7.2). |
---|
2200 | |
---|
2201 | |
---|
2202 | Section 19.7.1, paragraph 12: |
---|
2203 | OLD: |
---|
2204 | |
---|
2205 | HTTP messages can be (and often are) buffered by implementations; |
---|
2206 | despite it sometimes being available as a stream, HTTP is |
---|
2207 | fundamentally a message-oriented protocol. Minimum supported sizes |
---|
2208 | for various protocol elements have been suggested, to improve |
---|
2209 | interoperability. (Section 3) |
---|
2210 | |
---|
2211 | NEW: |
---|
2212 | |
---|
2213 | HTTP messages can be (and often are) buffered by implementations; |
---|
2214 | despite it sometimes being available as a stream, HTTP is |
---|
2215 | fundamentally a message-oriented protocol. Minimum supported sizes |
---|
2216 | for various protocol elements have been suggested, to improve |
---|
2217 | interoperability (Section 3). |
---|
2218 | |
---|
2219 | |
---|
2220 | Section 19.7.1, paragraph 13: |
---|
2221 | OLD: |
---|
2222 | |
---|
2223 | Invalid whitespace around field-names is now required to be rejected, |
---|
2224 | because accepting it represents a security vulnerability. The ABNF |
---|
2225 | productions defining header fields now only list the field value. |
---|
2226 | (Section 3.2) |
---|
2227 | |
---|
2228 | NEW: |
---|
2229 | |
---|
2230 | Invalid whitespace around field-names is now required to be rejected, |
---|
2231 | because accepting it represents a security vulnerability. The ABNF |
---|
2232 | productions defining header fields now only list the field value |
---|
2233 | (Section 3.2). |
---|
2234 | |
---|
2235 | |
---|
2236 | Section 19.7.1, paragraph 14: |
---|
2237 | OLD: |
---|
2238 | |
---|
2239 | Rules about implicit linear whitespace between certain grammar |
---|
2240 | productions have been removed; now whitespace is only allowed where |
---|
2241 | specifically defined in the ABNF. (Section 3.2.3) |
---|
2242 | |
---|
2243 | NEW: |
---|
2244 | |
---|
2245 | Rules about implicit linear whitespace between certain grammar |
---|
2246 | productions have been removed; now whitespace is only allowed where |
---|
2247 | specifically defined in the ABNF (Section 3.2.3). |
---|
2248 | |
---|
2249 | |
---|
2250 | Section 19.7.1, paragraph 15: |
---|
2251 | OLD: |
---|
2252 | |
---|
2253 | Header fields that span multiple lines ("line folding") are |
---|
2254 | deprecated. (Section 3.2.4) |
---|
2255 | The NUL octet is no longer allowed in comment and quoted-string text, |
---|
2256 | and handling of backslash-escaping in them has been clarified. The |
---|
2257 | quoted-pair rule no longer allows escaping control characters other |
---|
2258 | than HTAB. Non-ASCII content in header fields and the reason phrase |
---|
2259 | has been obsoleted and made opaque (the TEXT rule was removed). |
---|
2260 | (Section 3.2.6) |
---|
2261 | |
---|
2262 | NEW: |
---|
2263 | |
---|
2264 | Header fields that span multiple lines ("line folding") are |
---|
2265 | deprecated (Section 3.2.4). |
---|
2266 | |
---|
2267 | The NUL octet is no longer allowed in comment and quoted-string text, |
---|
2268 | and handling of backslash-escaping in them has been clarified. The |
---|
2269 | quoted-pair rule no longer allows escaping control characters other |
---|
2270 | than HTAB. Non-US-ASCII content in header fields and the reason |
---|
2271 | phrase has been obsoleted and made opaque (the TEXT rule was removed) |
---|
2272 | (Section 3.2.6). |
---|
2273 | |
---|
2274 | |
---|
2275 | Section 19.7.1, paragraph 16: |
---|
2276 | OLD: |
---|
2277 | |
---|
2278 | Bogus "Content-Length" header fields are now required to be handled |
---|
2279 | as errors by recipients. (Section 3.3.2) |
---|
2280 | |
---|
2281 | NEW: |
---|
2282 | |
---|
2283 | Bogus "Content-Length" header fields are now required to be handled |
---|
2284 | as errors by recipients (Section 3.3.2). |
---|
2285 | |
---|
2286 | |
---|
2287 | Section 19.7.1, paragraph 17: |
---|
2288 | OLD: |
---|
2289 | |
---|
2290 | The algorithm for determining the message body length has been |
---|
2291 | clarified to indicate all of the special cases (e.g., driven by |
---|
2292 | methods or status codes) that affect it, and that new protocol |
---|
2293 | elements cannot define such special cases. CONNECT is a new, special |
---|
2294 | case in determining message body length. "multipart/byteranges" is no |
---|
2295 | longer a way of determining message body length detection. |
---|
2296 | (Section 3.3.3) |
---|
2297 | |
---|
2298 | NEW: |
---|
2299 | |
---|
2300 | The algorithm for determining the message body length has been |
---|
2301 | clarified to indicate all of the special cases (e.g., driven by |
---|
2302 | methods or status codes) that affect it, and that new protocol |
---|
2303 | elements cannot define such special cases. CONNECT is a new, special |
---|
2304 | case in determining message body length. "multipart/byteranges" is no |
---|
2305 | longer a way of determining message body length detection |
---|
2306 | (Section 3.3.3). |
---|
2307 | |
---|
2308 | |
---|
2309 | Section 19.7.1, paragraph 18: |
---|
2310 | OLD: |
---|
2311 | |
---|
2312 | The "identity" transfer coding token has been removed. (Sections 3.3 |
---|
2313 | and 4) |
---|
2314 | |
---|
2315 | NEW: |
---|
2316 | |
---|
2317 | The "identity" transfer coding token has been removed (Sections 3.3 |
---|
2318 | and 4). |
---|
2319 | |
---|
2320 | |
---|
2321 | Section 19.7.1, paragraph 19: |
---|
2322 | OLD: |
---|
2323 | |
---|
2324 | Chunk length does not include the count of the octets in the chunk |
---|
2325 | header and trailer. Line folding in chunk extensions is disallowed. |
---|
2326 | (Section 4.1) |
---|
2327 | |
---|
2328 | NEW: |
---|
2329 | |
---|
2330 | Chunk length does not include the count of the octets in the chunk |
---|
2331 | header and trailer. Line folding in chunk extensions is disallowed |
---|
2332 | (Section 4.1). |
---|
2333 | |
---|
2334 | |
---|
2335 | Section 19.7.1, paragraph 20: |
---|
2336 | OLD: |
---|
2337 | |
---|
2338 | The meaning of the "deflate" content coding has been clarified. |
---|
2339 | (Section 4.2.2) |
---|
2340 | |
---|
2341 | NEW: |
---|
2342 | |
---|
2343 | The meaning of the "deflate" content coding has been clarified |
---|
2344 | (Section 4.2.2). |
---|
2345 | |
---|
2346 | |
---|
2347 | Section 19.7.1, paragraph 21: |
---|
2348 | OLD: |
---|
2349 | |
---|
2350 | The segment + query components of RFC 3986 have been used to define |
---|
2351 | the request-target, instead of abs_path from RFC 1808. The asterisk- |
---|
2352 | form of the request-target is only allowed with the OPTIONS method. |
---|
2353 | (Section 5.3) |
---|
2354 | |
---|
2355 | NEW: |
---|
2356 | |
---|
2357 | The segment + query components of RFC 3986 have been used to define |
---|
2358 | the request-target, instead of abs_path from RFC 1808. The asterisk- |
---|
2359 | form of the request-target is only allowed with the OPTIONS method |
---|
2360 | (Section 5.3). |
---|
2361 | |
---|
2362 | |
---|
2363 | Section 19.7.1, paragraph 22: |
---|
2364 | OLD: |
---|
2365 | |
---|
2366 | The term "Effective Request URI" has been introduced. (Section 5.5) |
---|
2367 | |
---|
2368 | NEW: |
---|
2369 | |
---|
2370 | The term "Effective Request URI" has been introduced (Section 5.5). |
---|
2371 | |
---|
2372 | |
---|
2373 | Section 19.7.1, paragraph 23: |
---|
2374 | OLD: |
---|
2375 | |
---|
2376 | Gateways do not need to generate Via header fields anymore. |
---|
2377 | (Section 5.7.1) |
---|
2378 | |
---|
2379 | NEW: |
---|
2380 | |
---|
2381 | Gateways do not need to generate Via header fields anymore |
---|
2382 | (Section 5.7.1). |
---|
2383 | |
---|
2384 | |
---|
2385 | Section 19.7.1, paragraph 24: |
---|
2386 | OLD: |
---|
2387 | |
---|
2388 | Exactly when "close" connection options have to be sent has been |
---|
2389 | clarified. Also, "hop-by-hop" header fields are required to appear |
---|
2390 | in the Connection header field; just because they're defined as hop- |
---|
2391 | by-hop in this specification doesn't exempt them. (Section 6.1) |
---|
2392 | |
---|
2393 | NEW: |
---|
2394 | |
---|
2395 | Exactly when "close" connection options have to be sent has been |
---|
2396 | clarified. Also, "hop-by-hop" header fields are required to appear |
---|
2397 | in the Connection header field; just because they're defined as hop- |
---|
2398 | by-hop in this specification doesn't exempt them (Section 6.1). |
---|
2399 | |
---|
2400 | |
---|
2401 | Section 19.7.1, paragraph 25: |
---|
2402 | OLD: |
---|
2403 | |
---|
2404 | The limit of two connections per server has been removed. An |
---|
2405 | idempotent sequence of requests is no longer required to be retried. |
---|
2406 | The requirement to retry requests under certain circumstances when |
---|
2407 | the server prematurely closes the connection has been removed. Also, |
---|
2408 | some extraneous requirements about when servers are allowed to close |
---|
2409 | connections prematurely have been removed. (Section 6.3) |
---|
2410 | |
---|
2411 | NEW: |
---|
2412 | |
---|
2413 | The limit of two connections per server has been removed. An |
---|
2414 | idempotent sequence of requests is no longer required to be retried. |
---|
2415 | The requirement to retry requests under certain circumstances when |
---|
2416 | the server prematurely closes the connection has been removed. Also, |
---|
2417 | some extraneous requirements about when servers are allowed to close |
---|
2418 | connections prematurely have been removed (Section 6.3). |
---|
2419 | |
---|
2420 | |
---|
2421 | Section 19.7.1, paragraph 26: |
---|
2422 | OLD: |
---|
2423 | |
---|
2424 | The semantics of the Upgrade header field is now defined in responses |
---|
2425 | other than 101 (this was incorporated from [RFC2817]). Furthermore, |
---|
2426 | the ordering in the field value is now significant. (Section 6.7) |
---|
2427 | |
---|
2428 | NEW: |
---|
2429 | |
---|
2430 | The semantics of the Upgrade header field is now defined in responses |
---|
2431 | other than 101 (this was incorporated from [RFC2817]). Furthermore, |
---|
2432 | the ordering in the field value is now significant (Section 6.7). |
---|
2433 | |
---|
2434 | |
---|
2435 | Section 19.7.1, paragraph 27: |
---|
2436 | OLD: |
---|
2437 | |
---|
2438 | Empty list elements in list productions (e.g., a list header field |
---|
2439 | containing ", ,") have been deprecated. (Section 7) |
---|
2440 | |
---|
2441 | NEW: |
---|
2442 | |
---|
2443 | Empty list elements in list productions (e.g., a list header field |
---|
2444 | containing ", ,") have been deprecated (Section 7). |
---|
2445 | |
---|
2446 | |
---|
2447 | Section 19.7.1, paragraph 28: |
---|
2448 | OLD: |
---|
2449 | |
---|
2450 | Registration of Transfer Codings now requires IETF Review |
---|
2451 | (Section 8.4) |
---|
2452 | |
---|
2453 | NEW: |
---|
2454 | |
---|
2455 | Registration of Transfer Codings now requires IETF Review |
---|
2456 | (Section 8.4). |
---|
2457 | |
---|
2458 | |
---|
2459 | Section 19.7.1, paragraph 29: |
---|
2460 | OLD: |
---|
2461 | |
---|
2462 | This specification now defines the Upgrade Token Registry, previously |
---|
2463 | defined in Section 7.2 of [RFC2817]. (Section 8.6) |
---|
2464 | |
---|
2465 | NEW: |
---|
2466 | |
---|
2467 | This specification now defines the "HTTP Upgrade Tokens" registry, |
---|
2468 | previously defined in Section 7.2 of [RFC2817] (Section 8.6). |
---|
2469 | |
---|
2470 | |
---|
2471 | Section 19.7.1, paragraph 30: |
---|
2472 | OLD: |
---|
2473 | |
---|
2474 | The expectation to support HTTP/0.9 requests has been removed. |
---|
2475 | (Appendix A) |
---|
2476 | |
---|
2477 | NEW: |
---|
2478 | |
---|
2479 | The expectation to support HTTP/0.9 requests has been removed |
---|
2480 | (Appendix A). |
---|
2481 | |
---|
2482 | |
---|
2483 | Section 19.7.1, paragraph 31: |
---|
2484 | OLD: |
---|
2485 | |
---|
2486 | Issues with the Keep-Alive and Proxy-Connection header fields in |
---|
2487 | requests are pointed out, with use of the latter being discouraged |
---|
2488 | altogether. (Appendix A.1.2) |
---|
2489 | |
---|
2490 | NEW: |
---|
2491 | |
---|
2492 | Issues with the Keep-Alive and Proxy-Connection header fields in |
---|
2493 | requests are pointed out, with use of the latter being discouraged |
---|
2494 | altogether (Appendix A.1.2). |
---|
2495 | |
---|
2496 | |
---|
2497 | Appendix B., paragraph 7: |
---|
2498 | OLD: |
---|
2499 | |
---|
2500 | URI-reference = <URI-reference, defined in [RFC3986], Section 4.1> |
---|
2501 | Upgrade = *( "," OWS ) protocol *( OWS "," [ OWS protocol ] ) |
---|
2502 | Via = *( "," OWS ) ( received-protocol RWS received-by [ RWS comment |
---|
2503 | ] ) *( OWS "," [ OWS ( received-protocol RWS received-by [ RWS |
---|
2504 | comment ] ) ] ) |
---|
2505 | |
---|
2506 | NEW: |
---|
2507 | |
---|
2508 | URI-reference = <URI-reference, defined in [RFC3986], Section 4.1> |
---|
2509 | Upgrade = *( "," OWS ) protocol *( OWS "," [ OWS protocol ] ) |
---|
2510 | |
---|
2511 | Via = *( "," OWS ) ( received-protocol RWS received-by [ RWS comment |
---|
2512 | ] ) *( OWS "," [ OWS ( received-protocol RWS received-by [ RWS |
---|
2513 | comment ] ) ] ) |
---|
2514 | |
---|
2515 | |
---|
2516 | Appendix B., paragraph 15: |
---|
2517 | OLD: |
---|
2518 | |
---|
2519 | partial-URI = relative-part [ "?" query ] |
---|
2520 | path-abempty = <path-abempty, defined in [RFC3986], Section 3.3> |
---|
2521 | port = <port, defined in [RFC3986], Section 3.2.3> |
---|
2522 | protocol = protocol-name [ "/" protocol-version ] |
---|
2523 | protocol-name = token |
---|
2524 | protocol-version = token |
---|
2525 | pseudonym = token |
---|
2526 | |
---|
2527 | qdtext = HTAB / SP / "!" / %x23-5B ; '#'-'[' |
---|
2528 | / %x5D-7E ; ']'-'~' |
---|
2529 | / obs-text |
---|
2530 | query = <query, defined in [RFC3986], Section 3.4> |
---|
2531 | quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text ) |
---|
2532 | quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE |
---|
2533 | |
---|
2534 | NEW: |
---|
2535 | |
---|
2536 | partial-URI = relative-part [ "?" query ] |
---|
2537 | path-abempty = <path-abempty, defined in [RFC3986], Section 3.3> |
---|
2538 | port = <port, defined in [RFC3986], Section 3.2.3> |
---|
2539 | protocol = protocol-name [ "/" protocol-version ] |
---|
2540 | protocol-name = token |
---|
2541 | protocol-version = token |
---|
2542 | pseudonym = token |
---|
2543 | qdtext = HTAB / SP / "!" / %x23-5B ; '#'-'[' |
---|
2544 | / %x5D-7E ; ']'-'~' |
---|
2545 | / obs-text |
---|
2546 | query = <query, defined in [RFC3986], Section 3.4> |
---|
2547 | quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text ) |
---|
2548 | quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE |
---|
2549 | |
---|
2550 | |
---|
2551 | Appendix B., paragraph 24: |
---|
2552 | OLD: |
---|
2553 | |
---|
2554 | D |
---|
2555 | deflate (Coding Format) 38 |
---|
2556 | Delimiters 26 |
---|
2557 | downstream 9 |
---|
2558 | |
---|
2559 | NEW: |
---|
2560 | |
---|
2561 | D |
---|
2562 | deflate (Coding Format) 38 |
---|
2563 | Delimiters 26 |
---|
2564 | downstream 10 |
---|
2565 | |
---|
2566 | |
---|
2567 | Appendix B., paragraph 26: |
---|
2568 | OLD: |
---|
2569 | |
---|
2570 | G |
---|
2571 | gateway 10 |
---|
2572 | Grammar |
---|
2573 | absolute-form 41-42 |
---|
2574 | absolute-path 16 |
---|
2575 | absolute-URI 16 |
---|
2576 | ALPHA 6 |
---|
2577 | asterisk-form 41-42 |
---|
2578 | authority 16 |
---|
2579 | authority-form 41-42 |
---|
2580 | BWS 24 |
---|
2581 | chunk 35 |
---|
2582 | chunk-data 35 |
---|
2583 | chunk-ext 35-36 |
---|
2584 | chunk-ext-name 36 |
---|
2585 | chunk-ext-val 36 |
---|
2586 | chunk-size 35 |
---|
2587 | chunked-body 35-36 |
---|
2588 | comment 27 |
---|
2589 | Connection 51 |
---|
2590 | connection-option 51 |
---|
2591 | Content-Length 30 |
---|
2592 | CR 6 |
---|
2593 | CRLF 6 |
---|
2594 | ctext 27 |
---|
2595 | CTL 6 |
---|
2596 | DIGIT 6 |
---|
2597 | DQUOTE 6 |
---|
2598 | field-content 22 |
---|
2599 | field-name 22, 39 |
---|
2600 | field-value 22 |
---|
2601 | field-vchar 22 |
---|
2602 | fragment 16 |
---|
2603 | header-field 22, 36 |
---|
2604 | HEXDIG 6 |
---|
2605 | Host 43 |
---|
2606 | HTAB 6 |
---|
2607 | HTTP-message 19 |
---|
2608 | HTTP-name 13 |
---|
2609 | http-URI 16 |
---|
2610 | HTTP-version 13 |
---|
2611 | https-URI 18 |
---|
2612 | last-chunk 35 |
---|
2613 | LF 6 |
---|
2614 | message-body 27 |
---|
2615 | method 21 |
---|
2616 | obs-fold 22 |
---|
2617 | obs-text 27 |
---|
2618 | OCTET 6 |
---|
2619 | origin-form 41 |
---|
2620 | OWS 24 |
---|
2621 | partial-URI 16 |
---|
2622 | port 16 |
---|
2623 | protocol-name 47 |
---|
2624 | protocol-version 47 |
---|
2625 | pseudonym 47 |
---|
2626 | qdtext 27 |
---|
2627 | query 16 |
---|
2628 | quoted-pair 27 |
---|
2629 | quoted-string 27 |
---|
2630 | rank 38 |
---|
2631 | reason-phrase 22 |
---|
2632 | received-by 47 |
---|
2633 | received-protocol 47 |
---|
2634 | request-line 21 |
---|
2635 | request-target 41 |
---|
2636 | RWS 24 |
---|
2637 | scheme 16 |
---|
2638 | segment 16 |
---|
2639 | SP 6 |
---|
2640 | start-line 20 |
---|
2641 | status-code 22 |
---|
2642 | status-line 22 |
---|
2643 | t-codings 38 |
---|
2644 | t-ranking 38 |
---|
2645 | tchar 27 |
---|
2646 | TE 38 |
---|
2647 | token 27 |
---|
2648 | Trailer 39 |
---|
2649 | trailer-part 35-36 |
---|
2650 | transfer-coding 35 |
---|
2651 | Transfer-Encoding 28 |
---|
2652 | transfer-extension 35 |
---|
2653 | transfer-parameter 35 |
---|
2654 | Upgrade 56 |
---|
2655 | uri-host 16 |
---|
2656 | URI-reference 16 |
---|
2657 | VCHAR 6 |
---|
2658 | Via 47 |
---|
2659 | gzip (Coding Format) 38 |
---|
2660 | |
---|
2661 | NEW: |
---|
2662 | |
---|
2663 | G |
---|
2664 | gateway 10 |
---|
2665 | Grammar |
---|
2666 | absolute-form 41-42 |
---|
2667 | absolute-path 16 |
---|
2668 | absolute-URI 16 |
---|
2669 | ALPHA 6 |
---|
2670 | asterisk-form 41-42 |
---|
2671 | authority 16 |
---|
2672 | authority-form 41-42 |
---|
2673 | BWS 24 |
---|
2674 | chunk 35 |
---|
2675 | chunk-data 35 |
---|
2676 | chunk-ext 35-36 |
---|
2677 | chunk-ext-name 36 |
---|
2678 | chunk-ext-val 36 |
---|
2679 | chunk-size 35 |
---|
2680 | chunked-body 35-36 |
---|
2681 | comment 27 |
---|
2682 | Connection 51 |
---|
2683 | connection-option 51 |
---|
2684 | Content-Length 30 |
---|
2685 | CR 6 |
---|
2686 | CRLF 6 |
---|
2687 | ctext 27 |
---|
2688 | CTL 6 |
---|
2689 | DIGIT 6 |
---|
2690 | DQUOTE 6 |
---|
2691 | field-content 22 |
---|
2692 | field-name 22, 39 |
---|
2693 | field-value 22 |
---|
2694 | field-vchar 22 |
---|
2695 | fragment 16 |
---|
2696 | header-field 22, 36 |
---|
2697 | HEXDIG 6 |
---|
2698 | Host 43 |
---|
2699 | HTAB 6 |
---|
2700 | HTTP-message 19 |
---|
2701 | HTTP-name 14 |
---|
2702 | http-URI 16 |
---|
2703 | HTTP-version 14 |
---|
2704 | https-URI 18 |
---|
2705 | last-chunk 35 |
---|
2706 | LF 6 |
---|
2707 | message-body 27 |
---|
2708 | method 21 |
---|
2709 | obs-fold 22 |
---|
2710 | obs-text 27 |
---|
2711 | OCTET 6 |
---|
2712 | origin-form 41 |
---|
2713 | OWS 24 |
---|
2714 | partial-URI 16 |
---|
2715 | port 16 |
---|
2716 | protocol-name 47 |
---|
2717 | protocol-version 47 |
---|
2718 | pseudonym 47 |
---|
2719 | qdtext 27 |
---|
2720 | query 16 |
---|
2721 | quoted-pair 27 |
---|
2722 | quoted-string 27 |
---|
2723 | rank 38 |
---|
2724 | reason-phrase 22 |
---|
2725 | received-by 47 |
---|
2726 | received-protocol 47 |
---|
2727 | request-line 21 |
---|
2728 | request-target 41 |
---|
2729 | RWS 24 |
---|
2730 | scheme 16 |
---|
2731 | segment 16 |
---|
2732 | SP 6 |
---|
2733 | start-line 20 |
---|
2734 | status-code 22 |
---|
2735 | status-line 22 |
---|
2736 | t-codings 38 |
---|
2737 | t-ranking 38 |
---|
2738 | tchar 27 |
---|
2739 | TE 38 |
---|
2740 | token 27 |
---|
2741 | Trailer 39 |
---|
2742 | trailer-part 35-36 |
---|
2743 | transfer-coding 35 |
---|
2744 | Transfer-Encoding 28 |
---|
2745 | transfer-extension 35 |
---|
2746 | transfer-parameter 35 |
---|
2747 | Upgrade 56 |
---|
2748 | uri-host 16 |
---|
2749 | URI-reference 16 |
---|
2750 | VCHAR 6 |
---|
2751 | Via 47 |
---|
2752 | gzip (Coding Format) 38 |
---|
2753 | |
---|
2754 | |
---|
2755 | Appendix B., paragraph 28: |
---|
2756 | OLD: |
---|
2757 | |
---|
2758 | I |
---|
2759 | inbound 9 |
---|
2760 | interception proxy 11 |
---|
2761 | intermediary 9 |
---|
2762 | |
---|
2763 | NEW: |
---|
2764 | |
---|
2765 | I |
---|
2766 | inbound 10 |
---|
2767 | interception proxy 11 |
---|
2768 | intermediary 9 |
---|
2769 | |
---|
2770 | |
---|
2771 | Appendix B., paragraph 31: |
---|
2772 | OLD: |
---|
2773 | |
---|
2774 | O |
---|
2775 | origin server 7 |
---|
2776 | origin-form (of request-target) 41 |
---|
2777 | outbound 9 |
---|
2778 | |
---|
2779 | NEW: |
---|
2780 | |
---|
2781 | O |
---|
2782 | origin server 7 |
---|
2783 | origin-form (of request-target) 41 |
---|
2784 | outbound 10 |
---|
2785 | |
---|
2786 | |
---|
2787 | Appendix B., paragraph 36: |
---|
2788 | OLD: |
---|
2789 | |
---|
2790 | U |
---|
2791 | Upgrade header field 56 |
---|
2792 | upstream 9 |
---|
2793 | URI scheme |
---|
2794 | http 16 |
---|
2795 | https 18 |
---|
2796 | user agent 7 |
---|
2797 | |
---|
2798 | NEW: |
---|
2799 | |
---|
2800 | U |
---|
2801 | Upgrade header field 56 |
---|
2802 | upstream 10 |
---|
2803 | URI scheme |
---|
2804 | http 16 |
---|
2805 | https 18 |
---|
2806 | user agent 7 |
---|
2807 | |
---|
2808 | |
---|
2809 | Section 345, paragraph 1: |
---|
2810 | OLD: |
---|
2811 | |
---|
2812 | EMail: fielding@gbiv.com |
---|
2813 | URI: http://roy.gbiv.com/ |
---|
2814 | |
---|
2815 | Julian F. Reschke (editor) |
---|
2816 | greenbytes GmbH |
---|
2817 | Hafenweg 16 |
---|
2818 | Muenster, NW 48155 |
---|
2819 | Germany |
---|
2820 | |
---|
2821 | NEW: |
---|
2822 | |
---|
2823 | EMail: fielding@gbiv.com |
---|
2824 | URI: http://roy.gbiv.com/ |
---|
2825 | Julian F. Reschke (editor) |
---|
2826 | greenbytes GmbH |
---|
2827 | Hafenweg 16 |
---|
2828 | Muenster, NW 48155 |
---|
2829 | Germany |
---|
2830 | |
---|