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

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

minor editorial changes (#553)

  • Property svn:eol-style set to native
File size: 15.9 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 20, 2014                                  May 19, 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 20, 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 4.1., paragraph 2:
212OLD:
213
214    The server generating a 304 response MUST generate any of the
215    following header fields that would have been sent in a 200 (OK)
216    response to the same request: Cache-Control, Content-Location, Date,
217    ETag, Expires, and Vary.
218
219NEW:
220
221    The server generating a 304 (Not Modified) response MUST generate any
222    of the following header fields that would have been sent in a 200
223    (OK) response to the same request: Cache-Control, Content-Location,
224    Date, ETag, Expires, and Vary.
225
226
227Section 4.1., paragraph 3:
228OLD:
229
230    Since the goal of a 304 response is to minimize information transfer
231    when the recipient already has one or more cached representations, a
232    sender SHOULD NOT generate representation metadata other than the
233    above listed fields unless said metadata exists for the purpose of
234    guiding cache updates (e.g., Last-Modified might be useful if the
235    response does not have an ETag field).
236
237NEW:
238
239    Since the goal of a 304 (Not Modified) response is to minimize
240    information transfer when the recipient already has one or more
241    cached representations, a sender SHOULD NOT generate representation
242    metadata other than the above listed fields unless said metadata
243    exists for the purpose of guiding cache updates (e.g., Last-Modified
244    might be useful if the response does not have an ETag field).
245
246
247Section 4.1., paragraph 4:
248OLD:
249
250    Requirements on a cache that receives a 304 response are defined in
251    Section 4.3.4 of [RFC7234].  If the conditional request originated
252    with an outbound client, such as a user agent with its own cache
253    sending a conditional GET to a shared proxy, then the proxy SHOULD
254    forward the 304 response to that client.
255
256NEW:
257
258    Requirements on a cache that receives a 304 (Not Modified) response
259    are defined in Section 4.3.4 of [RFC7234].  If the conditional
260    request originated with an outbound client, such as a user agent with
261    its own cache sending a conditional GET to a shared proxy, then the
262    proxy SHOULD forward the 304 (Not Modified) response to that client.
263
264
265Section 4.1., paragraph 5:
266OLD:
267
268    A 304 response cannot contain a message-body; it is always terminated
269    by the first empty line after the header fields.
270
271NEW:
272
273    A 304 (Not Modified) response cannot contain a message-body; it is
274    always terminated by the first empty line after the header fields.
275
276
277Section 7.1., paragraph 1:
278OLD:
279
280    The "Hypertext Transfer Protocol (HTTP) Status Code Registry" located
281    at <http://www.iana.org/assignments/http-status-codes> has been
282    updated with the registrations below:
283
284NEW:
285
286    The "HTTP Status Codes" registry located at
287    <http://www.iana.org/assignments/http-status-codes> has been updated
288    with the registrations below:
289
290
291Section 7.2., paragraph 1:
292OLD:
293
294    HTTP header fields are registered within the "Message Headers"
295    registry maintained at
296    <http://www.iana.org/assignments/message-headers/>.
297
298NEW:
299
300    HTTP header fields are registered within the Message Header Field
301    Registry maintained at
302    <http://www.iana.org/assignments/message-headers/>.
303
304
305Section 8., paragraph 1:
306OLD:
307
308    This section is meant to inform developers, information providers,
309    and users of known security concerns specific to the HTTP conditional
310    request mechanisms.  More general security considerations are
311    addressed in HTTP "Message Syntax and Routing" [RFC7230] and
312    "Semantics and Content" [RFC7231].
313
314NEW:
315
316    This section is meant to inform developers, information providers,
317    and users of known security concerns specific to the HTTP conditional
318    request mechanisms.  More general security considerations are
319    addressed in the HTTP messaging [RFC7230] and semantics [RFC7231]
320    documents.
321
322
323Section 10.1., paragraph 3:
324OLD:
325
326    [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
327               Protocol (HTTP/1.1): Message Syntax and Routing",
328               draft-ietf-httpbis-p1-messaging-latest (work in progress),
329               May 2014.
330
331NEW:
332
333    [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
334               Protocol (HTTP/1.1): Message Syntax and Routing",
335               RFC 7230, May 2014.
336
337
338Section 10.1., paragraph 4:
339OLD:
340
341    [RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
342               Protocol (HTTP/1.1): Semantics and Content",
343               draft-ietf-httpbis-p2-semantics-latest (work in progress),
344               May 2014.
345
346NEW:
347
348    [RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
349               Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
350               May 2014.
351
352
353Section 10.1., paragraph 5:
354OLD:
355
356    [RFC7233]  Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
357               "Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
358               draft-ietf-httpbis-p5-range-latest (work in progress),
359               May 2014.
360
361NEW:
362
363    [RFC7233]  Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
364               "Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
365               RFC 7233, May 2014.
366
367
368Section 10.1., paragraph 6:
369OLD:
370
371    [RFC7234]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
372               Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
373               draft-ietf-httpbis-p6-cache-latest (work in progress),
374               May 2014.
375
376NEW:
377
378    [RFC7234]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
379               Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
380               RFC 7234, May 2014.
381
382
383Appendix A., paragraph 1:
384OLD:
385
386    The definition of validator weakness has been expanded and clarified.
387    (Section 2.1)
388
389NEW:
390
391    The definition of validator weakness has been expanded and clarified
392    (Section 2.1).
393
394
395Appendix A., paragraph 2:
396OLD:
397
398    Weak entity-tags are now allowed in all requests except range
399    requests.  (Sections 2.1 and 3.2)
400    The ETag header field ABNF has been changed to not use quoted-string,
401    thus avoiding escaping issues.  (Section 2.3)
402
403NEW:
404
405    Weak entity-tags are now allowed in all requests except range
406    requests.  (Sections 2.1 and 3.2.)
407 
408    The ETag header field ABNF has been changed to not use quoted-string,
409    thus avoiding escaping issues (Section 2.3).
410
411
412Appendix A., paragraph 3:
413OLD:
414
415    ETag is defined to provide an entity tag for the selected
416    representation, thereby clarifying what it applies to in various
417    situations (such as a PUT response).  (Section 2.3)
418
419NEW:
420
421    ETag is defined to provide an entity tag for the selected
422    representation, thereby clarifying what it applies to in various
423    situations (such as a PUT response) (Section 2.3).
424
425
426Appendix A., paragraph 4:
427OLD:
428
429    The precedence for evaluation of conditional requests has been
430    defined.  (Section 6)
431
432NEW:
433
434    The precedence for evaluation of conditional requests has been
435    defined (Section 6).
436
437
438Appendix B., paragraph 3:
439OLD:
440
441      OWS           = <OWS, see [RFC7230], Section 3.2.3>
442      obs-text      = <obs-text, see [RFC7230], Section 3.2.6>
443
444NEW:
445
446      OWS           = <OWS, defined in [RFC7230], Section 3.2.3>
447      obs-text      = <obs-text, defined in [RFC7230], Section 3.2.6>
448
449
450Appendix B., paragraph 4:
451OLD:
452
453    The rules below are defined in other parts:
454
455NEW:
456
457    The rule below is defined in [RFC7231]:
458
459
460Appendix B., paragraph 5:
461OLD:
462
463      HTTP-date     = <HTTP-date, see [RFC7231], Section 7.1.1.1>
464
465NEW:
466
467      HTTP-date     = <HTTP-date, defined in [RFC7231], Section 7.1.1.1>
468
469
470Section 1.2, paragraph 2:
471OLD:
472
473    HTTP-date = <HTTP-date, see [RFC7231], Section 7.1.1.1>
474
475NEW:
476
477    HTTP-date = <HTTP-date, defined in [RFC7231], Section 7.1.1.1>
478
479
480Section 1.2, paragraph 5:
481OLD:
482
483    OWS = <OWS, see [RFC7230], Section 3.2.3>
484
485NEW:
486
487    OWS = <OWS, defined in [RFC7230], Section 3.2.3>
488
489
490Section 1.2, paragraph 7:
491OLD:
492
493    obs-text = <obs-text, see [RFC7230], Section 3.2.6>
494    opaque-tag = DQUOTE *etagc DQUOTE
495
496NEW:
497
498    obs-text = <obs-text, defined in [RFC7230], Section 3.2.6>
499    opaque-tag = DQUOTE *etagc DQUOTE
500
Note: See TracBrowser for help on using the repository browser.