source: draft-ietf-httpbis/latest/auth48/rfc7232.abdiff.txt @ 2674

Last change on this file since 2674 was 2674, checked in by julian.reschke@…, 6 years ago

fix broken sentence introduced in change [1339] for issue #304 (#553)

File size: 18.3 KB
Line 
1
2INTRODUCTION, paragraph 1:
3OLD:
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
11NEW:
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
20INTRODUCTION, paragraph 2:
21OLD:
22
23       Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests
24                 draft-ietf-httpbis-p4-conditional-latest
25
26NEW:
27
28       Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests
29
30
31INTRODUCTION, paragraph 5:
32OLD:
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
50NEW:
51
52 Status of This Memo
53
54
55INTRODUCTION, paragraph 6:
56OLD:
57
58    This Internet-Draft is submitted in full conformance with the
59    provisions of BCP 78 and BCP 79.
60
61NEW:
62
63    This is an Internet Standards Track document.
64
65
66INTRODUCTION, paragraph 7:
67OLD:
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
74NEW:
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
83INTRODUCTION, paragraph 8:
84OLD:
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
92NEW:
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
99Section 2., paragraph 1:
100OLD:
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
111NEW:
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
123Section 2.1., paragraph 3:
124OLD:
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
133NEW:
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
143Section 2.2.2., paragraph 5:
144OLD:
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
150NEW:
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
157Section 3.1., paragraph 8:
158OLD:
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
174NEW:
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
191Section 3.3., paragraph 5:
192OLD:
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
201NEW:
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
211Section 3.5., paragraph 1:
212OLD:
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
221NEW:
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
231Section 4.1., paragraph 2:
232OLD:
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
239NEW:
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
247Section 4.1., paragraph 3:
248OLD:
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
257NEW:
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
267Section 4.1., paragraph 4:
268OLD:
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
276NEW:
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
285Section 4.1., paragraph 5:
286OLD:
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
291NEW:
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
297Section 5., paragraph 1:
298OLD:
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
310NEW:
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
323Section 7.1., paragraph 1:
324OLD:
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
330NEW:
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
337Section 7.2., paragraph 1:
338OLD:
339
340    HTTP header fields are registered within the "Message Headers"
341    registry maintained at
342    <http://www.iana.org/assignments/message-headers/>.
343
344NEW:
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
351Section 7.2., paragraph 2:
352OLD:
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
358NEW:
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
365Section 8., paragraph 1:
366OLD:
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
373NEW:
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
382Section 10.1., paragraph 3:
383OLD:
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
390NEW:
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
397Section 10.1., paragraph 4:
398OLD:
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
405NEW:
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
412Section 10.1., paragraph 5:
413OLD:
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
420NEW:
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
427Section 10.1., paragraph 6:
428OLD:
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
435NEW:
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
442Appendix A., paragraph 1:
443OLD:
444
445    The definition of validator weakness has been expanded and clarified.
446    (Section 2.1)
447
448NEW:
449
450    The definition of validator weakness has been expanded and clarified
451    (Section 2.1).
452
453
454Appendix A., paragraph 2:
455OLD:
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
462NEW:
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
471Appendix A., paragraph 3:
472OLD:
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
478NEW:
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
485Appendix A., paragraph 4:
486OLD:
487
488    The precedence for evaluation of conditional requests has been
489    defined.  (Section 6)
490
491NEW:
492
493    The precedence for evaluation of conditional requests has been
494    defined (Section 6).
495
496
497Appendix B., paragraph 3:
498OLD:
499
500      OWS           = <OWS, see [RFC7230], Section 3.2.3>
501      obs-text      = <obs-text, see [RFC7230], Section 3.2.6>
502
503NEW:
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
509Appendix B., paragraph 4:
510OLD:
511
512    The rules below are defined in other parts:
513
514NEW:
515
516    The rule below is defined in [RFC7231]:
517
518
519Appendix B., paragraph 5:
520OLD:
521
522      HTTP-date     = <HTTP-date, see [RFC7231], Section 7.1.1.1>
523
524NEW:
525
526      HTTP-date     = <HTTP-date, defined in [RFC7231], Section 7.1.1.1>
527
528
529Section 1.2, paragraph 2:
530OLD:
531
532    HTTP-date = <HTTP-date, see [RFC7231], Section 7.1.1.1>
533
534NEW:
535
536    HTTP-date = <HTTP-date, defined in [RFC7231], Section 7.1.1.1>
537
538
539Section 1.2, paragraph 5:
540OLD:
541
542    OWS = <OWS, see [RFC7230], Section 3.2.3>
543
544NEW:
545
546    OWS = <OWS, defined in [RFC7230], Section 3.2.3>
547
548
549Section 1.2, paragraph 7:
550OLD:
551
552    obs-text = <obs-text, see [RFC7230], Section 3.2.6>
553    opaque-tag = DQUOTE *etagc DQUOTE
554
555NEW:
556
557    obs-text = <obs-text, defined in [RFC7230], Section 3.2.6>
558    opaque-tag = DQUOTE *etagc DQUOTE
559
Note: See TracBrowser for help on using the repository browser.