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

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

refresh (#553)

  • Property svn:eol-style set to native
File size: 16.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 16, 2014                                  May 15, 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 16, 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 7.2., paragraph 2:
306OLD:
307
308    This document defines the following HTTP header fields, so the
309    "Permanent Message Header Field Names" registry has been updated
310    accordingly (see [BCP90]).
311
312NEW:
313
314    This document defines the following HTTP header fields, so their
315    associated registry entries have been updated according to the
316    permanent registrations below (see [BCP90]):
317
318
319Section 8., paragraph 1:
320OLD:
321
322    This section is meant to inform developers, information providers,
323    and users of known security concerns specific to the HTTP conditional
324    request mechanisms.  More general security considerations are
325    addressed in HTTP messaging [RFC7230] and semantics [RFC7231].
326
327NEW:
328
329    This section is meant to inform developers, information providers,
330    and users of known security concerns specific to the HTTP conditional
331    request mechanisms.  More general security considerations are
332    addressed in the HTTP messaging [RFC7230] and semantics [RFC7231]
333    documents.
334
335
336Section 10.1., paragraph 3:
337OLD:
338
339    [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
340               Protocol (HTTP/1.1): Message Syntax and Routing",
341               draft-ietf-httpbis-p1-messaging-latest (work in progress),
342               May 2014.
343
344NEW:
345
346    [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
347               Protocol (HTTP/1.1): Message Syntax and Routing",
348               RFC 7230, May 2014.
349
350
351Section 10.1., paragraph 4:
352OLD:
353
354    [RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
355               Protocol (HTTP/1.1): Semantics and Content",
356               draft-ietf-httpbis-p2-semantics-latest (work in progress),
357               May 2014.
358
359NEW:
360
361    [RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
362               Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
363               May 2014.
364
365
366Section 10.1., paragraph 5:
367OLD:
368
369    [RFC7233]  Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
370               "Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
371               draft-ietf-httpbis-p5-range-latest (work in progress),
372               May 2014.
373
374NEW:
375
376    [RFC7233]  Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
377               "Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
378               RFC 7233, May 2014.
379
380
381Section 10.1., paragraph 6:
382OLD:
383
384    [RFC7234]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
385               Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
386               draft-ietf-httpbis-p6-cache-latest (work in progress),
387               May 2014.
388
389NEW:
390
391    [RFC7234]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
392               Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
393               RFC 7234, May 2014.
394
395
396Appendix A., paragraph 1:
397OLD:
398
399    The definition of validator weakness has been expanded and clarified.
400    (Section 2.1)
401
402NEW:
403
404    The definition of validator weakness has been expanded and clarified
405    (Section 2.1).
406
407
408Appendix A., paragraph 2:
409OLD:
410
411    Weak entity-tags are now allowed in all requests except range
412    requests.  (Sections 2.1 and 3.2)
413    The ETag header field ABNF has been changed to not use quoted-string,
414    thus avoiding escaping issues.  (Section 2.3)
415
416NEW:
417
418    Weak entity-tags are now allowed in all requests except range
419    requests.  (Sections 2.1 and 3.2.)
420 
421    The ETag header field ABNF has been changed to not use quoted-string,
422    thus avoiding escaping issues (Section 2.3).
423
424
425Appendix A., paragraph 3:
426OLD:
427
428    ETag is defined to provide an entity tag for the selected
429    representation, thereby clarifying what it applies to in various
430    situations (such as a PUT response).  (Section 2.3)
431
432NEW:
433
434    ETag is defined to provide an entity tag for the selected
435    representation, thereby clarifying what it applies to in various
436    situations (such as a PUT response) (Section 2.3).
437
438
439Appendix A., paragraph 4:
440OLD:
441
442    The precedence for evaluation of conditional requests has been
443    defined.  (Section 6)
444
445NEW:
446
447    The precedence for evaluation of conditional requests has been
448    defined (Section 6).
449
450
451Appendix B., paragraph 3:
452OLD:
453
454      OWS           = <OWS, see [RFC7230], Section 3.2.3>
455      obs-text      = <obs-text, see [RFC7230], Section 3.2.6>
456
457NEW:
458
459      OWS           = <OWS, defined in [RFC7230], Section 3.2.3>
460      obs-text      = <obs-text, defined in [RFC7230], Section 3.2.6>
461
462
463Appendix B., paragraph 4:
464OLD:
465
466    The rules below are defined in other parts:
467
468NEW:
469
470    The rule below is defined in [RFC7231]:
471
472
473Appendix B., paragraph 5:
474OLD:
475
476      HTTP-date     = <HTTP-date, see [RFC7231], Section 7.1.1.1>
477
478NEW:
479
480      HTTP-date     = <HTTP-date, defined in [RFC7231], Section 7.1.1.1>
481
482
483Section 1.2, paragraph 2:
484OLD:
485
486    HTTP-date = <HTTP-date, see [RFC7231], Section 7.1.1.1>
487
488NEW:
489
490    HTTP-date = <HTTP-date, defined in [RFC7231], Section 7.1.1.1>
491
492
493Section 1.2, paragraph 5:
494OLD:
495
496    OWS = <OWS, see [RFC7230], Section 3.2.3>
497
498NEW:
499
500    OWS = <OWS, defined in [RFC7230], Section 3.2.3>
501
502
503Section 1.2, paragraph 7:
504OLD:
505
506    obs-text = <obs-text, see [RFC7230], Section 3.2.6>
507    opaque-tag = DQUOTE *etagc DQUOTE
508
509NEW:
510
511    obs-text = <obs-text, defined in [RFC7230], Section 3.2.6>
512    opaque-tag = DQUOTE *etagc DQUOTE
513
Note: See TracBrowser for help on using the repository browser.