1 | |
---|
2 | INTRODUCTION, paragraph 1: |
---|
3 | OLD: |
---|
4 | |
---|
5 | HTTPbis Working Group R. Fielding, Ed. |
---|
6 | Internet-Draft Adobe |
---|
7 | Obsoletes: 2616 (if approved) J. Reschke, Ed. |
---|
8 | Intended status: Standards Track greenbytes |
---|
9 | Expires: November 15, 2014 May 14, 2014 |
---|
10 | |
---|
11 | NEW: |
---|
12 | |
---|
13 | Internet Engineering Task Force (IETF) R. Fielding, Ed. |
---|
14 | Request for Comments: 7232 Adobe |
---|
15 | Obsoletes: 2616 J. Reschke, Ed. |
---|
16 | Category: Standards Track greenbytes |
---|
17 | ISSN: 2070-1721 May 2014 |
---|
18 | |
---|
19 | |
---|
20 | INTRODUCTION, paragraph 2: |
---|
21 | OLD: |
---|
22 | |
---|
23 | Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests |
---|
24 | draft-ietf-httpbis-p4-conditional-latest |
---|
25 | |
---|
26 | NEW: |
---|
27 | |
---|
28 | Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests |
---|
29 | |
---|
30 | |
---|
31 | INTRODUCTION, paragraph 5: |
---|
32 | OLD: |
---|
33 | |
---|
34 | Editorial Note (To be removed by RFC Editor) |
---|
35 | |
---|
36 | Discussion of this draft takes place on the HTTPBIS working group |
---|
37 | mailing list (ietf-http-wg@w3.org), which is archived at |
---|
38 | <http://lists.w3.org/Archives/Public/ietf-http-wg/>. |
---|
39 | |
---|
40 | The current issues list is at |
---|
41 | <http://tools.ietf.org/wg/httpbis/trac/report/3> and related |
---|
42 | documents (including fancy diffs) can be found at |
---|
43 | <http://tools.ietf.org/wg/httpbis/>. |
---|
44 | |
---|
45 | _This is a temporary document for the purpose of tracking the |
---|
46 | editorial changes made during the AUTH48 (RFC publication) phase._ |
---|
47 | |
---|
48 | Status of This Memo |
---|
49 | |
---|
50 | NEW: |
---|
51 | |
---|
52 | Status of This Memo |
---|
53 | |
---|
54 | |
---|
55 | INTRODUCTION, paragraph 6: |
---|
56 | OLD: |
---|
57 | |
---|
58 | This Internet-Draft is submitted in full conformance with the |
---|
59 | provisions of BCP 78 and BCP 79. |
---|
60 | |
---|
61 | NEW: |
---|
62 | |
---|
63 | This is an Internet Standards Track document. |
---|
64 | |
---|
65 | |
---|
66 | INTRODUCTION, paragraph 7: |
---|
67 | OLD: |
---|
68 | |
---|
69 | Internet-Drafts are working documents of the Internet Engineering |
---|
70 | Task Force (IETF). Note that other groups may also distribute |
---|
71 | working documents as Internet-Drafts. The list of current Internet- |
---|
72 | Drafts is at http://datatracker.ietf.org/drafts/current/. |
---|
73 | |
---|
74 | NEW: |
---|
75 | |
---|
76 | This document is a product of the Internet Engineering Task Force |
---|
77 | (IETF). It represents the consensus of the IETF community. It has |
---|
78 | received public review and has been approved for publication by the |
---|
79 | Internet Engineering Steering Group (IESG). Further information on |
---|
80 | Internet Standards is available in Section 2 of RFC 5741. |
---|
81 | |
---|
82 | |
---|
83 | INTRODUCTION, paragraph 8: |
---|
84 | OLD: |
---|
85 | |
---|
86 | Internet-Drafts are draft documents valid for a maximum of six months |
---|
87 | and may be updated, replaced, or obsoleted by other documents at any |
---|
88 | time. It is inappropriate to use Internet-Drafts as reference |
---|
89 | material or to cite them other than as "work in progress." |
---|
90 | This Internet-Draft will expire on November 15, 2014. |
---|
91 | |
---|
92 | NEW: |
---|
93 | |
---|
94 | Information about the current status of this document, any errata, |
---|
95 | and how to provide feedback on it may be obtained at |
---|
96 | http://www.rfc-editor.org/info/rfc7232. |
---|
97 | |
---|
98 | |
---|
99 | Section 2., paragraph 1: |
---|
100 | OLD: |
---|
101 | |
---|
102 | This specification defines two forms of metadata that are commonly |
---|
103 | used to observe resource state and test for preconditions: |
---|
104 | modification dates (Section 2.2) and opaque entity tags |
---|
105 | (Section 2.3). Additional metadata that reflects resource state has |
---|
106 | been defined by various extensions of HTTP, such as Web Distributed |
---|
107 | Authoring and Versioning (WebDAV, [RFC4918]), that are beyond the |
---|
108 | scope of this specification. A resource metadata value is referred |
---|
109 | to as a "validator" when it is used within a precondition. |
---|
110 | |
---|
111 | NEW: |
---|
112 | |
---|
113 | This specification defines two forms of metadata that are commonly |
---|
114 | used to observe resource state and test for preconditions: |
---|
115 | modification dates (Section 2.2) and opaque entity tags |
---|
116 | (Section 2.3). Additional metadata that reflects resource state has |
---|
117 | been defined by various extensions of HTTP, such as Web Distributed |
---|
118 | Authoring and Versioning (WebDAV) [RFC4918], that are beyond the |
---|
119 | scope of this specification. A resource metadata value is referred |
---|
120 | to as a "validator" when it is used within a precondition. |
---|
121 | |
---|
122 | |
---|
123 | Section 2.1., paragraph 3: |
---|
124 | OLD: |
---|
125 | |
---|
126 | A strong validator might change for reasons other than a change to |
---|
127 | the representation data, such as when a semantically significant part |
---|
128 | of the representation metadata is changed (e.g., Content-Type), but |
---|
129 | it is in the best interests of the origin server to only change the |
---|
130 | value when it is necessary to invalidate the stored responses held by |
---|
131 | remote caches and authoring tools. |
---|
132 | |
---|
133 | NEW: |
---|
134 | |
---|
135 | A strong validator might change for reasons other than a change to |
---|
136 | the representation data, such as when a semantically significant part |
---|
137 | of the representation metadata is changed (e.g., Content-Type), but |
---|
138 | it is in the best interests of the origin server to change only the |
---|
139 | value when it is necessary to invalidate the stored responses held by |
---|
140 | remote caches and authoring tools. |
---|
141 | |
---|
142 | |
---|
143 | Section 2.2.2., paragraph 5: |
---|
144 | OLD: |
---|
145 | |
---|
146 | o The validator is about to be used by a client in an If-Modified- |
---|
147 | Since, If-Unmodified-Since, or If-Range header field, because the |
---|
148 | client has a cache entry for the associated representation, and |
---|
149 | |
---|
150 | NEW: |
---|
151 | |
---|
152 | o The validator is about to be used by a client in an If-Modified- |
---|
153 | Since or If-Unmodified-Since header field, because the client has |
---|
154 | a cache entry, or If-Range for the associated representation, and |
---|
155 | |
---|
156 | |
---|
157 | Section 3.1., paragraph 8: |
---|
158 | OLD: |
---|
159 | |
---|
160 | An origin server MUST NOT perform the requested method if a received |
---|
161 | If-Match condition evaluates to false; instead, the origin server |
---|
162 | MUST respond with either a) the 412 (Precondition Failed) status code |
---|
163 | or b) one of the 2xx (Successful) status codes if the origin server |
---|
164 | has verified that a state change is being requested and the final |
---|
165 | state is already reflected in the current state of the target |
---|
166 | resource (i.e., the change requested by the user agent has already |
---|
167 | succeeded, but the user agent might not be aware of it, perhaps |
---|
168 | because the prior response was lost or a compatible change was made |
---|
169 | by some other user agent). In the latter case, the origin server |
---|
170 | MUST NOT send a validator header field in the response unless it can |
---|
171 | verify that the request is a duplicate of an immediately prior change |
---|
172 | made by the same user agent. |
---|
173 | |
---|
174 | NEW: |
---|
175 | |
---|
176 | An origin server MUST NOT perform the requested method if a received |
---|
177 | If-Match condition evaluates to false; instead, the origin server |
---|
178 | MUST respond with either: a) the 412 (Precondition Failed) status |
---|
179 | code or b) one of the 2xx (Successful) status codes if the origin |
---|
180 | server has verified that a state change is being requested and the |
---|
181 | final state is already reflected in the current state of the target |
---|
182 | resource (i.e., the change requested by the user agent has already |
---|
183 | succeeded, but the user agent might not be aware of it, perhaps |
---|
184 | because the prior response was lost or a compatible change was made |
---|
185 | by some other user agent). In the latter case, the origin server |
---|
186 | MUST NOT send a validator header field in the response unless it can |
---|
187 | verify that the request is a duplicate of an immediately prior change |
---|
188 | made by the same user agent. |
---|
189 | |
---|
190 | |
---|
191 | Section 3.3., paragraph 5: |
---|
192 | OLD: |
---|
193 | |
---|
194 | A recipient MUST ignore If-Modified-Since if the request contains an |
---|
195 | If-None-Match header field; the condition in If-None-Match is |
---|
196 | considered to be a more accurate replacement for the condition in If- |
---|
197 | Modified-Since, and the two are only combined for the sake of |
---|
198 | interoperating with older intermediaries that might not implement If- |
---|
199 | None-Match. |
---|
200 | |
---|
201 | NEW: |
---|
202 | |
---|
203 | A recipient MUST ignore If-Modified-Since if the request contains an |
---|
204 | If-None-Match header field; the condition in If-None-Match is |
---|
205 | considered to be a more accurate replacement for the condition in If- |
---|
206 | Modified-Since and the two are only combined for the sake of |
---|
207 | interoperating with older intermediaries that might not implement If- |
---|
208 | None-Match. |
---|
209 | |
---|
210 | |
---|
211 | Section 3.5., paragraph 1: |
---|
212 | OLD: |
---|
213 | |
---|
214 | The "If-Range" header field provides a special conditional request |
---|
215 | mechanism that is similar to the If-Match and If-Unmodified-Since |
---|
216 | header fields but that instructs the recipient to ignore the Range |
---|
217 | header field if the validator doesn't match, resulting in transfer of |
---|
218 | the new selected representation instead of a 412 response. If-Range |
---|
219 | is defined in Section 3.2 of [RFC7233]. |
---|
220 | |
---|
221 | NEW: |
---|
222 | |
---|
223 | The "If-Range" header field provides a special conditional request |
---|
224 | mechanism that is similar to the If-Match and If-Unmodified-Since |
---|
225 | header fields but that instructs the recipient to ignore the Range |
---|
226 | header field if the validator doesn't match, resulting in transfer of |
---|
227 | the new selected representation instead of a 412 (Precondition |
---|
228 | Failed) response. If-Range is defined in Section 3.2 of [RFC7233]. |
---|
229 | |
---|
230 | |
---|
231 | Section 4.1., paragraph 2: |
---|
232 | OLD: |
---|
233 | |
---|
234 | The server generating a 304 response MUST generate any of the |
---|
235 | following header fields that would have been sent in a 200 (OK) |
---|
236 | response to the same request: Cache-Control, Content-Location, Date, |
---|
237 | ETag, Expires, and Vary. |
---|
238 | |
---|
239 | NEW: |
---|
240 | |
---|
241 | The server generating a 304 (Not Modified) response MUST generate any |
---|
242 | of the following header fields that would have been sent in a 200 |
---|
243 | (OK) response to the same request: Cache-Control, Content-Location, |
---|
244 | Date, ETag, Expires, and Vary. |
---|
245 | |
---|
246 | |
---|
247 | Section 4.1., paragraph 3: |
---|
248 | OLD: |
---|
249 | |
---|
250 | Since the goal of a 304 response is to minimize information transfer |
---|
251 | when the recipient already has one or more cached representations, a |
---|
252 | sender SHOULD NOT generate representation metadata other than the |
---|
253 | above listed fields unless said metadata exists for the purpose of |
---|
254 | guiding cache updates (e.g., Last-Modified might be useful if the |
---|
255 | response does not have an ETag field). |
---|
256 | |
---|
257 | NEW: |
---|
258 | |
---|
259 | Since the goal of a 304 (Not Modified) response is to minimize |
---|
260 | information transfer when the recipient already has one or more |
---|
261 | cached representations, a sender SHOULD NOT generate representation |
---|
262 | metadata other than the above listed fields unless said metadata |
---|
263 | exists for the purpose of guiding cache updates (e.g., Last-Modified |
---|
264 | might be useful if the response does not have an ETag field). |
---|
265 | |
---|
266 | |
---|
267 | Section 4.1., paragraph 4: |
---|
268 | OLD: |
---|
269 | |
---|
270 | Requirements on a cache that receives a 304 response are defined in |
---|
271 | Section 4.3.4 of [RFC7234]. If the conditional request originated |
---|
272 | with an outbound client, such as a user agent with its own cache |
---|
273 | sending a conditional GET to a shared proxy, then the proxy SHOULD |
---|
274 | forward the 304 response to that client. |
---|
275 | |
---|
276 | NEW: |
---|
277 | |
---|
278 | Requirements on a cache that receives a 304 (Not Modified) response |
---|
279 | are defined in Section 4.3.4 of [RFC7234]. If the conditional |
---|
280 | request originated with an outbound client, such as a user agent with |
---|
281 | its own cache sending a conditional GET to a shared proxy, then the |
---|
282 | proxy SHOULD forward the 304 (Not Modified) response to that client. |
---|
283 | |
---|
284 | |
---|
285 | Section 4.1., paragraph 5: |
---|
286 | OLD: |
---|
287 | |
---|
288 | A 304 response cannot contain a message-body; it is always terminated |
---|
289 | by the first empty line after the header fields. |
---|
290 | |
---|
291 | NEW: |
---|
292 | |
---|
293 | A 304 (Not Modified) response cannot contain a message-body; it is |
---|
294 | always terminated by the first empty line after the header fields. |
---|
295 | |
---|
296 | |
---|
297 | Section 5., paragraph 1: |
---|
298 | OLD: |
---|
299 | |
---|
300 | Except when excluded below, a recipient cache or origin server MUST |
---|
301 | evaluate received request preconditions after it has successfully |
---|
302 | performed its normal request checks and just before it would perform |
---|
303 | the action associated with the request method. A server MUST ignore |
---|
304 | all received preconditions if its response to the same request |
---|
305 | without those conditions would have been a status code other than a |
---|
306 | 2xx or 412 (Precondition Failed). In other words, redirects and |
---|
307 | failures take precedence over the evaluation of preconditions in |
---|
308 | conditional requests. |
---|
309 | |
---|
310 | NEW: |
---|
311 | |
---|
312 | Except when excluded below, a recipient cache or origin server MUST |
---|
313 | evaluate received request preconditions after it has successfully |
---|
314 | performed its normal request checks and just before it would perform |
---|
315 | the action associated with the request method. A server MUST ignore |
---|
316 | all received preconditions if its response to the same request |
---|
317 | without those conditions would have been a status code other than a |
---|
318 | 2xx (Successful) or 412 (Precondition Failed). In other words, |
---|
319 | redirects and failures take precedence over the evaluation of |
---|
320 | preconditions in conditional requests. |
---|
321 | |
---|
322 | |
---|
323 | Section 7.1., paragraph 1: |
---|
324 | OLD: |
---|
325 | |
---|
326 | The "Hypertext Transfer Protocol (HTTP) Status Code Registry" located |
---|
327 | at <http://www.iana.org/assignments/http-status-codes> has been |
---|
328 | updated with the registrations below: |
---|
329 | |
---|
330 | NEW: |
---|
331 | |
---|
332 | The "HTTP Status Codes" registry located at |
---|
333 | <http://www.iana.org/assignments/http-status-codes> has been updated |
---|
334 | with the registrations below: |
---|
335 | |
---|
336 | |
---|
337 | Section 7.2., paragraph 1: |
---|
338 | OLD: |
---|
339 | |
---|
340 | HTTP header fields are registered within the "Message Headers" |
---|
341 | registry maintained at |
---|
342 | <http://www.iana.org/assignments/message-headers/>. |
---|
343 | |
---|
344 | NEW: |
---|
345 | |
---|
346 | HTTP header fields are registered within the Message Header Field |
---|
347 | Registry maintained at |
---|
348 | <http://www.iana.org/assignments/message-headers/>. |
---|
349 | |
---|
350 | |
---|
351 | Section 7.2., paragraph 2: |
---|
352 | OLD: |
---|
353 | |
---|
354 | This document defines the following HTTP header fields, so the |
---|
355 | "Permanent Message Header Field Names" registry has been updated |
---|
356 | accordingly (see [BCP90]). |
---|
357 | |
---|
358 | NEW: |
---|
359 | |
---|
360 | This document defines the following HTTP header fields, so their |
---|
361 | associated registry entries have been updated according to the |
---|
362 | permanent registrations below (see [BCP90]): |
---|
363 | |
---|
364 | |
---|
365 | Section 8., paragraph 1: |
---|
366 | OLD: |
---|
367 | |
---|
368 | This section is meant to inform developers, information providers, |
---|
369 | and users of known security concerns specific to the HTTP conditional |
---|
370 | request mechanisms. More general security considerations are |
---|
371 | addressed in HTTP messaging [RFC7230] and semantics [RFC7231]. |
---|
372 | |
---|
373 | NEW: |
---|
374 | |
---|
375 | This section is meant to inform developers, information providers, |
---|
376 | and users of known security concerns specific to the HTTP conditional |
---|
377 | request mechanisms. More general security considerations are |
---|
378 | addressed in the HTTP messaging [RFC7230] and semantics [RFC7231] |
---|
379 | documents. |
---|
380 | |
---|
381 | |
---|
382 | Section 10.1., paragraph 3: |
---|
383 | OLD: |
---|
384 | |
---|
385 | [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer |
---|
386 | Protocol (HTTP/1.1): Message Syntax and Routing", |
---|
387 | draft-ietf-httpbis-p1-messaging-latest (work in progress), |
---|
388 | May 2014. |
---|
389 | |
---|
390 | NEW: |
---|
391 | |
---|
392 | [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer |
---|
393 | Protocol (HTTP/1.1): Message Syntax and Routing", |
---|
394 | RFC 7230, May 2014. |
---|
395 | |
---|
396 | |
---|
397 | Section 10.1., paragraph 4: |
---|
398 | OLD: |
---|
399 | |
---|
400 | [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer |
---|
401 | Protocol (HTTP/1.1): Semantics and Content", |
---|
402 | draft-ietf-httpbis-p2-semantics-latest (work in progress), |
---|
403 | May 2014. |
---|
404 | |
---|
405 | NEW: |
---|
406 | |
---|
407 | [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer |
---|
408 | Protocol (HTTP/1.1): Semantics and Content", RFC 7231, |
---|
409 | May 2014. |
---|
410 | |
---|
411 | |
---|
412 | Section 10.1., paragraph 5: |
---|
413 | OLD: |
---|
414 | |
---|
415 | [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., |
---|
416 | "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", |
---|
417 | draft-ietf-httpbis-p5-range-latest (work in progress), |
---|
418 | May 2014. |
---|
419 | |
---|
420 | NEW: |
---|
421 | |
---|
422 | [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., |
---|
423 | "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", |
---|
424 | RFC 7233, May 2014. |
---|
425 | |
---|
426 | |
---|
427 | Section 10.1., paragraph 6: |
---|
428 | OLD: |
---|
429 | |
---|
430 | [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, |
---|
431 | Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", |
---|
432 | draft-ietf-httpbis-p6-cache-latest (work in progress), |
---|
433 | May 2014. |
---|
434 | |
---|
435 | NEW: |
---|
436 | |
---|
437 | [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, |
---|
438 | Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", |
---|
439 | RFC 7234, May 2014. |
---|
440 | |
---|
441 | |
---|
442 | Appendix A., paragraph 1: |
---|
443 | OLD: |
---|
444 | |
---|
445 | The definition of validator weakness has been expanded and clarified. |
---|
446 | (Section 2.1) |
---|
447 | |
---|
448 | NEW: |
---|
449 | |
---|
450 | The definition of validator weakness has been expanded and clarified |
---|
451 | (Section 2.1). |
---|
452 | |
---|
453 | |
---|
454 | Appendix A., paragraph 2: |
---|
455 | OLD: |
---|
456 | |
---|
457 | Weak entity-tags are now allowed in all requests except range |
---|
458 | requests. (Sections 2.1 and 3.2) |
---|
459 | The ETag header field ABNF has been changed to not use quoted-string, |
---|
460 | thus avoiding escaping issues. (Section 2.3) |
---|
461 | |
---|
462 | NEW: |
---|
463 | |
---|
464 | Weak entity-tags are now allowed in all requests except range |
---|
465 | requests. (Sections 2.1 and 3.2.) |
---|
466 | |
---|
467 | The ETag header field ABNF has been changed to not use quoted-string, |
---|
468 | thus avoiding escaping issues (Section 2.3). |
---|
469 | |
---|
470 | |
---|
471 | Appendix A., paragraph 3: |
---|
472 | OLD: |
---|
473 | |
---|
474 | ETag is defined to provide an entity tag for the selected |
---|
475 | representation, thereby clarifying what it applies to in various |
---|
476 | situations (such as a PUT response). (Section 2.3) |
---|
477 | |
---|
478 | NEW: |
---|
479 | |
---|
480 | ETag is defined to provide an entity tag for the selected |
---|
481 | representation, thereby clarifying what it applies to in various |
---|
482 | situations (such as a PUT response) (Section 2.3). |
---|
483 | |
---|
484 | |
---|
485 | Appendix A., paragraph 4: |
---|
486 | OLD: |
---|
487 | |
---|
488 | The precedence for evaluation of conditional requests has been |
---|
489 | defined. (Section 6) |
---|
490 | |
---|
491 | NEW: |
---|
492 | |
---|
493 | The precedence for evaluation of conditional requests has been |
---|
494 | defined (Section 6). |
---|
495 | |
---|
496 | |
---|
497 | Appendix B., paragraph 3: |
---|
498 | OLD: |
---|
499 | |
---|
500 | OWS = <OWS, see [RFC7230], Section 3.2.3> |
---|
501 | obs-text = <obs-text, see [RFC7230], Section 3.2.6> |
---|
502 | |
---|
503 | NEW: |
---|
504 | |
---|
505 | OWS = <OWS, defined in [RFC7230], Section 3.2.3> |
---|
506 | obs-text = <obs-text, defined in [RFC7230], Section 3.2.6> |
---|
507 | |
---|
508 | |
---|
509 | Appendix B., paragraph 4: |
---|
510 | OLD: |
---|
511 | |
---|
512 | The rules below are defined in other parts: |
---|
513 | |
---|
514 | NEW: |
---|
515 | |
---|
516 | The rule below is defined in [RFC7231]: |
---|
517 | |
---|
518 | |
---|
519 | Appendix B., paragraph 5: |
---|
520 | OLD: |
---|
521 | |
---|
522 | HTTP-date = <HTTP-date, see [RFC7231], Section 7.1.1.1> |
---|
523 | |
---|
524 | NEW: |
---|
525 | |
---|
526 | HTTP-date = <HTTP-date, defined in [RFC7231], Section 7.1.1.1> |
---|
527 | |
---|
528 | |
---|
529 | Section 1.2, paragraph 2: |
---|
530 | OLD: |
---|
531 | |
---|
532 | HTTP-date = <HTTP-date, see [RFC7231], Section 7.1.1.1> |
---|
533 | |
---|
534 | NEW: |
---|
535 | |
---|
536 | HTTP-date = <HTTP-date, defined in [RFC7231], Section 7.1.1.1> |
---|
537 | |
---|
538 | |
---|
539 | Section 1.2, paragraph 5: |
---|
540 | OLD: |
---|
541 | |
---|
542 | OWS = <OWS, see [RFC7230], Section 3.2.3> |
---|
543 | |
---|
544 | NEW: |
---|
545 | |
---|
546 | OWS = <OWS, defined in [RFC7230], Section 3.2.3> |
---|
547 | |
---|
548 | |
---|
549 | Section 1.2, paragraph 7: |
---|
550 | OLD: |
---|
551 | |
---|
552 | obs-text = <obs-text, see [RFC7230], Section 3.2.6> |
---|
553 | opaque-tag = DQUOTE *etagc DQUOTE |
---|
554 | |
---|
555 | NEW: |
---|
556 | |
---|
557 | obs-text = <obs-text, defined in [RFC7230], Section 3.2.6> |
---|
558 | opaque-tag = DQUOTE *etagc DQUOTE |
---|
559 | |
---|