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

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

punctuation, title case etc (#553)

File size: 21.2 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 14, 2014                                  May 13, 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 14, 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.1., paragraph 6:
144OLD:
145
146    In contrast, a "weak validator" is representation metadata that might
147    not change for every change to the representation data.  This
148    weakness might be due to limitations in how the value is calculated,
149    such as clock resolution or an inability to ensure uniqueness for all
150    possible representations of the resource, or due to a desire by the
151    resource owner to group representations by some self-determined set
152    of equivalency rather than unique sequences of data.  An origin
153    server SHOULD change a weak entity-tag whenever it considers prior
154    representations to be unacceptable as a substitute for the current
155    representation.  In other words, a weak entity-tag ought to change
156    whenever the origin server wants caches to invalidate old responses.
157
158NEW:
159
160    In contrast, a "weak validator" is representation metadata that might
161    not change for every change to the representation data.  This
162    weakness might be due to limitations in how the value is calculated,
163    such as clock resolution, an inability to ensure uniqueness for all
164    possible representations of the resource, or a desire of the resource
165    owner to group representations by some self-determined set of
166    equivalency rather than unique sequences of data.  An origin server
167    SHOULD change a weak entity-tag whenever it considers prior
168    representations to be unacceptable as a substitute for the current
169    representation.  In other words, a weak entity-tag ought to change
170    whenever the origin server wants caches to invalidate old responses.
171
172
173Section 2.2.2., paragraph 5:
174OLD:
175
176    o  The validator is about to be used by a client in an If-Modified-
177       Since, If-Unmodified-Since header field, because the client has a
178       cache entry, or If-Range for the associated representation, and
179
180NEW:
181
182    o  The validator is about to be used by a client in an If-Modified-
183       Since or If-Unmodified-Since header field, because the client has
184       a cache entry, or If-Range for the associated representation, and
185
186
187Section 3.1., paragraph 8:
188OLD:
189
190    An origin server MUST NOT perform the requested method if a received
191    If-Match condition evaluates to false; instead, the origin server
192    MUST respond with either a) the 412 (Precondition Failed) status code
193    or b) one of the 2xx (Successful) status codes if the origin server
194    has verified that a state change is being requested and the final
195    state is already reflected in the current state of the target
196    resource (i.e., the change requested by the user agent has already
197    succeeded, but the user agent might not be aware of it, perhaps
198    because the prior response was lost or a compatible change was made
199    by some other user agent).  In the latter case, the origin server
200    MUST NOT send a validator header field in the response unless it can
201    verify that the request is a duplicate of an immediately prior change
202    made by the same user agent.
203
204NEW:
205
206    An origin server MUST NOT perform the requested method if a received
207    If-Match condition evaluates to false; instead, the origin server
208    MUST respond with either: a) the 412 (Precondition Failed) status
209    code or b) one of the 2xx (Successful) status codes if the origin
210    server has verified that a state change is being requested and the
211    final state is already reflected in the current state of the target
212    resource (i.e., the change requested by the user agent has already
213    succeeded, but the user agent might not be aware of it, perhaps
214    because the prior response was lost or a compatible change was made
215    by some other user agent).  In the latter case, the origin server
216    MUST NOT send a validator header field in the response unless it can
217    verify that the request is a duplicate of an immediately prior change
218    made by the same user agent.
219
220
221Section 3.3., paragraph 5:
222OLD:
223
224    A recipient MUST ignore If-Modified-Since if the request contains an
225    If-None-Match header field; the condition in If-None-Match is
226    considered to be a more accurate replacement for the condition in If-
227    Modified-Since, and the two are only combined for the sake of
228    interoperating with older intermediaries that might not implement If-
229    None-Match.
230
231NEW:
232
233    A recipient MUST ignore If-Modified-Since if the request contains an
234    If-None-Match header field; the condition in If-None-Match is
235    considered to be a more accurate replacement for the condition in If-
236    Modified-Since and the two are only combined for the sake of
237    interoperating with older intermediaries that might not implement If-
238    None-Match.
239
240
241Section 3.5., paragraph 1:
242OLD:
243
244    The "If-Range" header field provides a special conditional request
245    mechanism that is similar to the If-Match and If-Unmodified-Since
246    header fields but that instructs the recipient to ignore the Range
247    header field if the validator doesn't match, resulting in transfer of
248    the new selected representation instead of a 412 response.  If-Range
249    is defined in Section 3.2 of [RFC7233].
250
251NEW:
252
253    The "If-Range" header field provides a special conditional request
254    mechanism that is similar to the If-Match and If-Unmodified-Since
255    header fields but that instructs the recipient to ignore the Range
256    header field if the validator doesn't match, resulting in transfer of
257    the new selected representation instead of a 412 (Precondition
258    Failed) response.  If-Range is defined in Section 3.2 of [RFC7233].
259
260
261Section 4.1., paragraph 2:
262OLD:
263
264    The server generating a 304 response MUST generate any of the
265    following header fields that would have been sent in a 200 (OK)
266    response to the same request: Cache-Control, Content-Location, Date,
267    ETag, Expires, and Vary.
268
269NEW:
270
271    The server generating a 304 (Not Modified) response MUST generate any
272    of the following header fields that would have been sent in a 200
273    (OK) response to the same request: Cache-Control, Content-Location,
274    Date, ETag, Expires, and Vary.
275
276
277Section 4.1., paragraph 3:
278OLD:
279
280    Since the goal of a 304 response is to minimize information transfer
281    when the recipient already has one or more cached representations, a
282    sender SHOULD NOT generate representation metadata other than the
283    above listed fields unless said metadata exists for the purpose of
284    guiding cache updates (e.g., Last-Modified might be useful if the
285    response does not have an ETag field).
286
287NEW:
288
289    Since the goal of a 304 (Not Modified) response is to minimize
290    information transfer when the recipient already has one or more
291    cached representations, a sender SHOULD NOT generate representation
292    metadata other than the above listed fields unless said metadata
293    exists for the purpose of guiding cache updates (e.g., Last-Modified
294    might be useful if the response does not have an ETag field).
295
296
297Section 4.1., paragraph 4:
298OLD:
299
300    Requirements on a cache that receives a 304 response are defined in
301    Section 4.3.4 of [RFC7234].  If the conditional request originated
302    with an outbound client, such as a user agent with its own cache
303    sending a conditional GET to a shared proxy, then the proxy SHOULD
304    forward the 304 response to that client.
305
306NEW:
307
308    Requirements on a cache that receives a 304 (Not Modified) response
309    are defined in Section 4.3.4 of [RFC7234].  If the conditional
310    request originated with an outbound client, such as a user agent with
311    its own cache sending a conditional GET to a shared proxy, then the
312    proxy SHOULD forward the 304 (Not Modified) response to that client.
313
314
315Section 4.1., paragraph 5:
316OLD:
317
318    A 304 response cannot contain a message-body; it is always terminated
319    by the first empty line after the header fields.
320
321NEW:
322
323    A 304 (Not Modified) response cannot contain a message-body; it is
324    always terminated by the first empty line after the header fields.
325
326
327Section 5., paragraph 1:
328OLD:
329
330    Except when excluded below, a recipient cache or origin server MUST
331    evaluate received request preconditions after it has successfully
332    performed its normal request checks and just before it would perform
333    the action associated with the request method.  A server MUST ignore
334    all received preconditions if its response to the same request
335    without those conditions would have been a status code other than a
336    2xx or 412 (Precondition Failed).  In other words, redirects and
337    failures take precedence over the evaluation of preconditions in
338    conditional requests.
339
340NEW:
341
342    Except when excluded below, a recipient cache or origin server MUST
343    evaluate received request preconditions after it has successfully
344    performed its normal request checks and just before it would perform
345    the action associated with the request method.  A server MUST ignore
346    all received preconditions if its response to the same request
347    without those conditions would have been a status code other than a
348    2xx (Successful) or 412 (Precondition Failed).  In other words,
349    redirects and failures take precedence over the evaluation of
350    preconditions in conditional requests.
351
352
353Section 5., paragraph 2:
354OLD:
355
356    A server that is not the origin server for the target resource and
357    cannot act as a cache for requests on the target resource MUST NOT
358    evaluate the conditional request header fields defined by this
359    specification, and MUST forward them if the request is forwarded,
360    since the generating client intends that they be evaluated by a
361    server that can provide a current representation.  Likewise, a server
362    MUST ignore the conditional request header fields defined by this
363    specification when received with a request method that does not
364    involve the selection or modification of a selected representation,
365    such as CONNECT, OPTIONS, or TRACE.
366
367NEW:
368
369    A server that is not the origin server for the target resource and
370    cannot act as a cache for requests on the target resource MUST NOT
371    evaluate the conditional request header fields defined by this
372    specification, and it MUST forward them if the request is forwarded,
373    since the generating client intends that they be evaluated by a
374    server that can provide a current representation.  Likewise, a server
375    MUST ignore the conditional request header fields defined by this
376    specification when received with a request method that does not
377    involve the selection or modification of a selected representation,
378    such as CONNECT, OPTIONS, or TRACE.
379
380
381Section 7.1., paragraph 1:
382OLD:
383
384    The "Hypertext Transfer Protocol (HTTP) Status Code Registry" located
385    at <http://www.iana.org/assignments/http-status-codes> has been
386    updated with the registrations below:
387
388NEW:
389
390    The "HTTP Status Codes" registry located at
391    <http://www.iana.org/assignments/http-status-codes> has been updated
392    with the registrations below:
393
394
395Section 7.2., paragraph 1:
396OLD:
397
398    HTTP header fields are registered within the "Message Headers"
399    registry maintained at
400    <http://www.iana.org/assignments/message-headers/>.
401
402NEW:
403
404    HTTP header fields are registered within the Message Header Field
405    Registry maintained at
406    <http://www.iana.org/assignments/message-headers/>.
407
408
409Section 7.2., paragraph 2:
410OLD:
411
412    This document defines the following HTTP header fields, so the
413    "Permanent Message Header Field Names" registry has been updated
414    accordingly (see [BCP90]).
415
416NEW:
417
418    This document defines the following HTTP header fields, so their
419    associated registry entries have been updated according to the
420    permanent registrations below (see [BCP90]):
421
422
423Section 8., paragraph 1:
424OLD:
425
426    This section is meant to inform developers, information providers,
427    and users of known security concerns specific to the HTTP conditional
428    request mechanisms.  More general security considerations are
429    addressed in HTTP messaging [RFC7230] and semantics [RFC7231].
430
431NEW:
432
433    This section is meant to inform developers, information providers,
434    and users of known security concerns specific to the HTTP conditional
435    request mechanisms.  More general security considerations are
436    addressed in the HTTP messaging [RFC7230] and semantics [RFC7231]
437    documents.
438
439
440Section 10.1., paragraph 3:
441OLD:
442
443    [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
444               Protocol (HTTP/1.1): Message Syntax and Routing",
445               draft-ietf-httpbis-p1-messaging-latest (work in progress),
446               May 2014.
447
448NEW:
449
450    [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
451               Protocol (HTTP/1.1): Message Syntax and Routing",
452               RFC 7230, May 2014.
453
454
455Section 10.1., paragraph 4:
456OLD:
457
458    [RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
459               Protocol (HTTP/1.1): Semantics and Content",
460               draft-ietf-httpbis-p2-semantics-latest (work in progress),
461               May 2014.
462
463NEW:
464
465    [RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
466               Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
467               May 2014.
468
469
470Section 10.1., paragraph 5:
471OLD:
472
473    [RFC7233]  Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
474               "Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
475               draft-ietf-httpbis-p5-range-latest (work in progress),
476               May 2014.
477
478NEW:
479
480    [RFC7233]  Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
481               "Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
482               RFC 7233, May 2014.
483
484
485Section 10.1., paragraph 6:
486OLD:
487
488    [RFC7234]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
489               Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
490               draft-ietf-httpbis-p6-cache-latest (work in progress),
491               May 2014.
492
493NEW:
494
495    [RFC7234]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
496               Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
497               RFC 7234, May 2014.
498
499
500Appendix A., paragraph 1:
501OLD:
502
503    The definition of validator weakness has been expanded and clarified.
504    (Section 2.1)
505
506NEW:
507
508    The definition of validator weakness has been expanded and clarified
509    (Section 2.1).
510
511
512Appendix A., paragraph 2:
513OLD:
514
515    Weak entity-tags are now allowed in all requests except range
516    requests.  (Sections 2.1 and 3.2)
517    The ETag header field ABNF has been changed to not use quoted-string,
518    thus avoiding escaping issues.  (Section 2.3)
519
520NEW:
521
522    Weak entity-tags are now allowed in all requests except range
523    requests.  (Sections 2.1 and 3.2.)
524 
525    The ETag header field ABNF has been changed to not use quoted-string,
526    thus avoiding escaping issues (Section 2.3).
527
528
529Appendix A., paragraph 3:
530OLD:
531
532    ETag is defined to provide an entity tag for the selected
533    representation, thereby clarifying what it applies to in various
534    situations (such as a PUT response).  (Section 2.3)
535
536NEW:
537
538    ETag is defined to provide an entity tag for the selected
539    representation, thereby clarifying what it applies to in various
540    situations (such as a PUT response) (Section 2.3).
541
542
543Appendix A., paragraph 4:
544OLD:
545
546    The precedence for evaluation of conditional requests has been
547    defined.  (Section 6)
548
549NEW:
550
551    The precedence for evaluation of conditional requests has been
552    defined (Section 6).
553
554
555Appendix B., paragraph 3:
556OLD:
557
558      OWS           = <OWS, see [RFC7230], Section 3.2.3>
559      obs-text      = <obs-text, see [RFC7230], Section 3.2.6>
560
561NEW:
562
563      OWS           = <OWS, defined in [RFC7230], Section 3.2.3>
564      obs-text      = <obs-text, defined in [RFC7230], Section 3.2.6>
565
566
567Appendix B., paragraph 4:
568OLD:
569
570    The rules below are defined in other parts:
571
572NEW:
573
574    The rule below is defined in [RFC7231]:
575
576
577Appendix B., paragraph 5:
578OLD:
579
580      HTTP-date     = <HTTP-date, see [RFC7231], Section 7.1.1.1>
581
582NEW:
583
584      HTTP-date     = <HTTP-date, defined in [RFC7231], Section 7.1.1.1>
585
586
587Section 1.2, paragraph 2:
588OLD:
589
590    HTTP-date = <HTTP-date, see [RFC7231], Section 7.1.1.1>
591
592NEW:
593
594    HTTP-date = <HTTP-date, defined in [RFC7231], Section 7.1.1.1>
595
596
597Section 1.2, paragraph 5:
598OLD:
599
600    OWS = <OWS, see [RFC7230], Section 3.2.3>
601
602NEW:
603
604    OWS = <OWS, defined in [RFC7230], Section 3.2.3>
605
606
607Section 1.2, paragraph 7:
608OLD:
609
610    obs-text = <obs-text, see [RFC7230], Section 3.2.6>
611    opaque-tag = DQUOTE *etagc DQUOTE
612
613NEW:
614
615    obs-text = <obs-text, defined in [RFC7230], Section 3.2.6>
616    opaque-tag = DQUOTE *etagc DQUOTE
617
Note: See TracBrowser for help on using the repository browser.