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

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

add RFC7232-to-be (#553)

File size: 35.5 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 10., paragraph 0:
100OLD:
101
102    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
103      1.1.  Conformance and Error Handling . . . . . . . . . . . . . .  4
104      1.2.  Syntax Notation  . . . . . . . . . . . . . . . . . . . . .  4
105    2.  Validators . . . . . . . . . . . . . . . . . . . . . . . . . .  5
106      2.1.  Weak versus Strong . . . . . . . . . . . . . . . . . . . .  5
107      2.2.  Last-Modified  . . . . . . . . . . . . . . . . . . . . . .  7
108        2.2.1.  Generation . . . . . . . . . . . . . . . . . . . . . .  7
109        2.2.2.  Comparison . . . . . . . . . . . . . . . . . . . . . .  8
110      2.3.  ETag . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
111        2.3.1.  Generation . . . . . . . . . . . . . . . . . . . . . . 10
112        2.3.2.  Comparison . . . . . . . . . . . . . . . . . . . . . . 10
113        2.3.3.  Example: Entity-tags Varying on Content-Negotiated
114                Resources  . . . . . . . . . . . . . . . . . . . . . . 11
115      2.4.  When to Use Entity-tags and Last-Modified Dates  . . . . . 12
116    3.  Precondition Header Fields . . . . . . . . . . . . . . . . . . 13
117      3.1.  If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 13
118      3.2.  If-None-Match  . . . . . . . . . . . . . . . . . . . . . . 14
119      3.3.  If-Modified-Since  . . . . . . . . . . . . . . . . . . . . 15
120      3.4.  If-Unmodified-Since  . . . . . . . . . . . . . . . . . . . 16
121      3.5.  If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 18
122    4.  Status Code Definitions  . . . . . . . . . . . . . . . . . . . 18
123      4.1.  304 Not Modified . . . . . . . . . . . . . . . . . . . . . 18
124      4.2.  412 Precondition Failed  . . . . . . . . . . . . . . . . . 18
125    5.  Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . 19
126    6.  Precedence . . . . . . . . . . . . . . . . . . . . . . . . . . 19
127    7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 21
128      7.1.  Status Code Registration . . . . . . . . . . . . . . . . . 21
129      7.2.  Header Field Registration  . . . . . . . . . . . . . . . . 21
130    8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 22
131    9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 22
132    10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
133      10.1. Normative References . . . . . . . . . . . . . . . . . . . 23
134      10.2. Informative References . . . . . . . . . . . . . . . . . . 23
135    Appendix A.  Changes from RFC 2616 . . . . . . . . . . . . . . . . 23
136    Appendix B.  Imported ABNF . . . . . . . . . . . . . . . . . . . . 24
137    Appendix C.  Collected ABNF  . . . . . . . . . . . . . . . . . . . 24
138    Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
139
140NEW:
141
142    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
143      1.1.  Conformance and Error Handling . . . . . . . . . . . . . .  4
144      1.2.  Syntax Notation  . . . . . . . . . . . . . . . . . . . . .  4
145    2.  Validators . . . . . . . . . . . . . . . . . . . . . . . . . .  5
146      2.1.  Weak versus Strong . . . . . . . . . . . . . . . . . . . .  5
147      2.2.  Last-Modified  . . . . . . . . . . . . . . . . . . . . . .  7
148        2.2.1.  Generation . . . . . . . . . . . . . . . . . . . . . .  7
149        2.2.2.  Comparison . . . . . . . . . . . . . . . . . . . . . .  8
150      2.3.  ETag . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
151        2.3.1.  Generation . . . . . . . . . . . . . . . . . . . . . . 10
152        2.3.2.  Comparison . . . . . . . . . . . . . . . . . . . . . . 10
153        2.3.3.  Example: Entity-Tags Varying on Content-Negotiated
154                Resources  . . . . . . . . . . . . . . . . . . . . . . 11
155      2.4.  When to Use Entity-Tags and Last-Modified Dates  . . . . . 12
156    3.  Precondition Header Fields . . . . . . . . . . . . . . . . . . 13
157      3.1.  If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 13
158      3.2.  If-None-Match  . . . . . . . . . . . . . . . . . . . . . . 14
159      3.3.  If-Modified-Since  . . . . . . . . . . . . . . . . . . . . 15
160      3.4.  If-Unmodified-Since  . . . . . . . . . . . . . . . . . . . 16
161      3.5.  If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 18
162    4.  Status Code Definitions  . . . . . . . . . . . . . . . . . . . 18
163      4.1.  304 Not Modified . . . . . . . . . . . . . . . . . . . . . 18
164      4.2.  412 Precondition Failed  . . . . . . . . . . . . . . . . . 18
165    5.  Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . 19
166    6.  Precedence . . . . . . . . . . . . . . . . . . . . . . . . . . 19
167    7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 21
168      7.1.  Status Code Registration . . . . . . . . . . . . . . . . . 21
169      7.2.  Header Field Registration  . . . . . . . . . . . . . . . . 21
170    8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 22
171    9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 22
172    10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
173      10.1. Normative References . . . . . . . . . . . . . . . . . . . 23
174      10.2. Informative References . . . . . . . . . . . . . . . . . . 23
175    Appendix A.  Changes from RFC 2616 . . . . . . . . . . . . . . . . 23
176    Appendix B.  Imported ABNF . . . . . . . . . . . . . . . . . . . . 24
177    Appendix C.  Collected ABNF  . . . . . . . . . . . . . . . . . . . 24
178    Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
179
180
181Section 2., paragraph 1:
182OLD:
183
184    This specification defines two forms of metadata that are commonly
185    used to observe resource state and test for preconditions:
186    modification dates (Section 2.2) and opaque entity tags
187    (Section 2.3).  Additional metadata that reflects resource state has
188    been defined by various extensions of HTTP, such as WebDAV [RFC4918],
189    that are beyond the scope of this specification.  A resource metadata
190    value is referred to as a "validator" when it is used within a
191    precondition.
192
193NEW:
194
195    This specification defines two forms of metadata that are commonly
196    used to observe resource state and test for preconditions:
197    modification dates (Section 2.2) and opaque entity tags
198    (Section 2.3).  Additional metadata that reflects resource state has
199    been defined by various extensions of HTTP, such as Web Distributed
200    Authoring and Versioning (WebDAV) [RFC4918], that are beyond the
201    scope of this specification.  A resource metadata value is referred
202    to as a "validator" when it is used within a precondition.
203
204
205Section 2.1., paragraph 3:
206OLD:
207
208    A strong validator might change for reasons other than a change to
209    the representation data, such as when a semantically significant part
210    of the representation metadata is changed (e.g., Content-Type), but
211    it is in the best interests of the origin server to only change the
212    value when it is necessary to invalidate the stored responses held by
213    remote caches and authoring tools.
214
215NEW:
216
217    A strong validator might change for reasons other than a change to
218    the representation data, such as when a semantically significant part
219    of the representation metadata is changed (e.g., Content-Type), but
220    it is in the best interests of the origin server to change only the
221    value when it is necessary to invalidate the stored responses held by
222    remote caches and authoring tools.
223
224
225Section 2.1., paragraph 6:
226OLD:
227
228    In contrast, a "weak validator" is representation metadata that might
229    not change for every change to the representation data.  This
230    weakness might be due to limitations in how the value is calculated,
231    such as clock resolution or an inability to ensure uniqueness for all
232    possible representations of the resource, or due to a desire by the
233    resource owner to group representations by some self-determined set
234    of equivalency rather than unique sequences of data.  An origin
235    server SHOULD change a weak entity-tag whenever it considers prior
236    representations to be unacceptable as a substitute for the current
237    representation.  In other words, a weak entity-tag ought to change
238    whenever the origin server wants caches to invalidate old responses.
239
240NEW:
241
242    In contrast, a "weak validator" is representation metadata that might
243    not change for every change to the representation data.  This
244    weakness might be due to limitations in how the value is calculated,
245    such as clock resolution, an inability to ensure uniqueness for all
246    possible representations of the resource, or a desire of the resource
247    owner to group representations by some self-determined set of
248    equivalency rather than unique sequences of data.  An origin server
249    SHOULD change a weak entity-tag whenever it considers prior
250    representations to be unacceptable as a substitute for the current
251    representation.  In other words, a weak entity-tag ought to change
252    whenever the origin server wants caches to invalidate old responses.
253
254
255Section 2.2.2., paragraph 5:
256OLD:
257
258    o  The validator is about to be used by a client in an If-Modified-
259       Since, If-Unmodified-Since header field, because the client has a
260       cache entry, or If-Range for the associated representation, and
261
262NEW:
263
264    o  The validator is about to be used by a client in an If-Modified-
265       Since or If-Unmodified-Since header field, because the client has
266       a cache entry, or If-Range for the associated representation, and
267
268
269Section 2.2.2., paragraph 12:
270OLD:
271
272    This method relies on the fact that if two different responses were
273    sent by the origin server during the same second, but both had the
274    same Last-Modified time, then at least one of those responses would
275    have a Date value equal to its Last-Modified time.  The arbitrary 60-
276    second limit guards against the possibility that the Date and Last-
277    Modified values are generated from different clocks, or at somewhat
278    different times during the preparation of the response.  An
279    implementation MAY use a value larger than 60 seconds, if it is
280    believed that 60 seconds is too short.
281
282NEW:
283
284    This method relies on the fact that if two different responses were
285    sent by the origin server during the same second, but both had the
286    same Last-Modified time, then at least one of those responses would
287    have a Date value equal to its Last-Modified time.  The arbitrary 60-
288    second limit guards against the possibility that the Date and Last-
289    Modified values are generated from different clocks or at somewhat
290    different times during the preparation of the response.  An
291    implementation MAY use a value larger than 60 seconds, if it is
292    believed that 60 seconds is too short.
293
294
295Section 2.3., paragraph 4:
296OLD:
297
298       Note: Previously, opaque-tag was defined to be a quoted-string
299       ([RFC2616], Section 3.11), thus some recipients might perform
300       backslash unescaping.  Servers therefore ought to avoid backslash
301       characters in entity tags.
302
303NEW:
304
305       Note: Previously, opaque-tag was defined to be a quoted-string
306       ([RFC2616], Section 3.11); thus, some recipients might perform
307       backslash unescaping.  Servers therefore ought to avoid backslash
308       characters in entity tags.
309
310
311Section 2.3.1., paragraph 3:
312OLD:
313
314    An origin server SHOULD send ETag for any selected representation for
315    which detection of changes can be reasonably and consistently
316    determined, since the entity-tag's use in conditional requests and
317    evaluating cache freshness ([RFC7234]) can result in a substantial
318    reduction of HTTP network traffic and can be a significant factor in
319    improving service scalability and reliability.
320
321NEW:
322
323    An origin server SHOULD send an ETag for any selected representation
324    for which detection of changes can be reasonably and consistently
325    determined, since the entity-tag's use in conditional requests and
326    evaluating cache freshness ([RFC7234]) can result in a substantial
327    reduction of HTTP network traffic and can be a significant factor in
328    improving service scalability and reliability.
329
330
331Section 2.3.2., paragraph 1:
332OLD:
333
334    There are two entity-tag comparison functions, depending on whether
335    the comparison context allows the use of weak validators or not:
336
337NEW:
338
339    There are two entity-tag comparison functions, depending on whether
340    or not the comparison context allows the use of weak validators:
341
342
343Section 2.3.2., paragraph 4:
344OLD:
345
346    The example below shows the results for a set of entity-tag pairs,
347    and both the weak and strong comparison function results:
348
349NEW:
350
351    The example below shows the results for a set of entity-tag pairs and
352    both the weak and strong comparison function results:
353
354
355Section 2.3.2., paragraph 6:
356OLD:
357
358 2.3.3.  Example: Entity-tags Varying on Content-Negotiated Resources
359
360NEW:
361
362 2.3.3.  Example: Entity-Tags Varying on Content-Negotiated Resources
363
364
365Section 3.4, paragraph 12:
366OLD:
367
368 2.4.  When to Use Entity-tags and Last-Modified Dates
369
370NEW:
371
372 2.4.  When to Use Entity-Tags and Last-Modified Dates
373
374
375Section 3.1., paragraph 8:
376OLD:
377
378    An origin server MUST NOT perform the requested method if a received
379    If-Match condition evaluates to false; instead the origin server MUST
380    respond with either: a) the 412 (Precondition Failed) status code;
381    or, b) one of the 2xx (Successful) status codes if the origin server
382    has verified that a state change is being requested and the final
383    state is already reflected in the current state of the target
384    resource (i.e., the change requested by the user agent has already
385    succeeded, but the user agent might not be aware of it, perhaps
386    because the prior response was lost or a compatible change was made
387    by some other user agent).  In the latter case, the origin server
388    MUST NOT send a validator header field in the response unless it can
389    verify that the request is a duplicate of an immediately prior change
390    made by the same user agent.
391
392NEW:
393
394    An origin server MUST NOT perform the requested method if a received
395    If-Match condition evaluates to false; instead, the origin server
396    MUST respond with either: a) the 412 (Precondition Failed) status
397    code or b) one of the 2xx (Successful) status codes if the origin
398    server has verified that a state change is being requested and the
399    final state is already reflected in the current state of the target
400    resource (i.e., the change requested by the user agent has already
401    succeeded, but the user agent might not be aware of it, perhaps
402    because the prior response was lost or a compatible change was made
403    by some other user agent).  In the latter case, the origin server
404    MUST NOT send a validator header field in the response unless it can
405    verify that the request is a duplicate of an immediately prior change
406    made by the same user agent.
407
408
409Section 304, paragraph 3:
410OLD:
411
412    An origin server MUST NOT perform the requested method if the
413    condition evaluates to false; instead, the origin server MUST respond
414    with either a) the 304 (Not Modified) status code if the request
415    method is GET or HEAD; or, b) the 412 (Precondition Failed) status
416    code for all other request methods.
417
418NEW:
419
420    An origin server MUST NOT perform the requested method if the
421    condition evaluates to false; instead, the origin server MUST respond
422    with either a) the 304 (Not Modified) status code if the request
423    method is GET or HEAD or b) the 412 (Precondition Failed) status code
424    for all other request methods.
425
426
427Section 3.3., paragraph 8:
428OLD:
429
430    If-Modified-Since is typically used for two distinct purposes: 1) to
431    allow efficient updates of a cached representation that does not have
432    an entity-tag; and, 2) to limit the scope of a web traversal to
433    resources that have recently changed.
434
435NEW:
436
437    If-Modified-Since is typically used for two distinct purposes: 1) to
438    allow efficient updates of a cached representation that does not have
439    an entity-tag and 2) to limit the scope of a web traversal to
440    resources that have recently changed.
441
442
443Section 3.4., paragraph 5:
444OLD:
445
446    A recipient MUST ignore If-Unmodified-Since if the request contains
447    an If-Match header field; the condition in If-Match is considered to
448    be a more accurate replacement for the condition in If-Unmodified-
449    Since and the two are only combined for the sake of interoperating
450    with older intermediaries that might not implement If-Match.
451
452NEW:
453
454    A recipient MUST ignore If-Unmodified-Since if the request contains
455    an If-Match header field; the condition in If-Match is considered to
456    be a more accurate replacement for the condition in If-Unmodified-
457    Since, and the two are only combined for the sake of interoperating
458    with older intermediaries that might not implement If-Match.
459
460
461Section 3.4., paragraph 9:
462OLD:
463
464    An origin server that receives an If-Unmodified-Since header field
465    MUST evaluate the condition prior to performing the method
466    (Section 5).  The origin server MUST NOT perform the requested method
467    if the selected representation's last modification date is more
468    recent than the date provided in the field-value; instead the origin
469    server MUST respond with either: a) the 412 (Precondition Failed)
470    status code; or, b) one of the 2xx (Successful) status codes if the
471    origin server has verified that a state change is being requested and
472    the final state is already reflected in the current state of the
473    target resource (i.e., the change requested by the user agent has
474    already succeeded, but the user agent might not be aware of that
475    because the prior response message was lost or a compatible change
476    was made by some other user agent).  In the latter case, the origin
477    server MUST NOT send a validator header field in the response unless
478    it can verify that the request is a duplicate of an immediately prior
479    change made by the same user agent.
480
481NEW:
482
483    An origin server that receives an If-Unmodified-Since header field
484    MUST evaluate the condition prior to performing the method
485    (Section 5).  The origin server MUST NOT perform the requested method
486    if the selected representation's last modification date is more
487    recent than the date provided in the field-value; instead the origin
488    server MUST respond with either a) the 412 (Precondition Failed)
489    status code or b) one of the 2xx (Successful) status codes if the
490    origin server has verified that a state change is being requested and
491    the final state is already reflected in the current state of the
492    target resource (i.e., the change requested by the user agent has
493    already succeeded, but the user agent might not be aware of that
494    because the prior response message was lost or a compatible change
495    was made by some other user agent).  In the latter case, the origin
496    server MUST NOT send a validator header field in the response unless
497    it can verify that the request is a duplicate of an immediately prior
498    change made by the same user agent.
499
500
501Section 3.5., paragraph 1:
502OLD:
503
504    The "If-Range" header field provides a special conditional request
505    mechanism that is similar to the If-Match and If-Unmodified-Since
506    header fields but instructs the recipient to ignore the Range header
507    field if the validator doesn't match, resulting in transfer of the
508    new selected representation instead of a 412 response.  If-Range is
509    defined in Section 3.2 of [RFC7233].
510
511NEW:
512
513    The "If-Range" header field provides a special conditional request
514    mechanism that is similar to the If-Match and If-Unmodified-Since
515    header fields but that instructs the recipient to ignore the Range
516    header field if the validator doesn't match, resulting in transfer of
517    the new selected representation instead of a 412 (Precondition
518    Failed) response.  If-Range is defined in Section 3.2 of [RFC7233].
519
520
521Section 4.1., paragraph 1:
522OLD:
523
524    The 304 (Not Modified) status code indicates that a conditional GET
525    or HEAD request has been received and would have resulted in a 200
526    (OK) response if it were not for the fact that the condition has
527    evaluated to false.  In other words, there is no need for the server
528    to transfer a representation of the target resource because the
529    request indicates that the client, which made the request
530    conditional, already has a valid representation; the server is
531    therefore redirecting the client to make use of that stored
532    representation as if it were the payload of a 200 (OK) response.
533
534NEW:
535
536    The 304 (Not Modified) status code indicates that a conditional GET
537    or HEAD request has been received and would have resulted in a 200
538    (OK) response if it were not for the fact that the condition
539    evaluated to false.  In other words, there is no need for the server
540    to transfer a representation of the target resource because the
541    request indicates that the client, which made the request
542    conditional, already has a valid representation; the server is
543    therefore redirecting the client to make use of that stored
544    representation as if it were the payload of a 200 (OK) response.
545
546
547Section 4.1., paragraph 2:
548OLD:
549
550    The server generating a 304 response MUST generate any of the
551    following header fields that would have been sent in a 200 (OK)
552    response to the same request: Cache-Control, Content-Location, Date,
553    ETag, Expires, and Vary.
554
555NEW:
556
557    The server generating a 304 (Not Modified) response MUST generate any
558    of the following header fields that would have been sent in a 200
559    (OK) response to the same request: Cache-Control, Content-Location,
560    Date, ETag, Expires, and Vary.
561
562
563Section 4.1., paragraph 3:
564OLD:
565
566    Since the goal of a 304 response is to minimize information transfer
567    when the recipient already has one or more cached representations, a
568    sender SHOULD NOT generate representation metadata other than the
569    above listed fields unless said metadata exists for the purpose of
570    guiding cache updates (e.g., Last-Modified might be useful if the
571    response does not have an ETag field).
572
573NEW:
574
575    Since the goal of a 304 (Not Modified) response is to minimize
576    information transfer when the recipient already has one or more
577    cached representations, a sender SHOULD NOT generate representation
578    metadata other than the above listed fields unless said metadata
579    exists for the purpose of guiding cache updates (e.g., Last-Modified
580    might be useful if the response does not have an ETag field).
581
582
583Section 4.1., paragraph 4:
584OLD:
585
586    Requirements on a cache that receives a 304 response are defined in
587    Section 4.3.4 of [RFC7234].  If the conditional request originated
588    with an outbound client, such as a user agent with its own cache
589    sending a conditional GET to a shared proxy, then the proxy SHOULD
590    forward the 304 response to that client.
591
592NEW:
593
594    Requirements on a cache that receives a 304 (Not Modified) response
595    are defined in Section 4.3.4 of [RFC7234].  If the conditional
596    request originated with an outbound client, such as a user agent with
597    its own cache sending a conditional GET to a shared proxy, then the
598    proxy SHOULD forward the 304 (Not Modified) response to that client.
599
600
601Section 4.1., paragraph 5:
602OLD:
603
604    A 304 response cannot contain a message-body; it is always terminated
605    by the first empty line after the header fields.
606
607NEW:
608
609    A 304 (Not Modified) response cannot contain a message-body; it is
610    always terminated by the first empty line after the header fields.
611
612
613Section 4.2., paragraph 1:
614OLD:
615
616    The 412 (Precondition Failed) status code indicates that one or more
617    conditions given in the request header fields evaluated to false when
618    tested on the server.  This response code allows the client to place
619    preconditions on the current resource state (its current
620    representations and metadata) and thus prevent the request method
621    from being applied if the target resource is in an unexpected state.
622
623NEW:
624
625    The 412 (Precondition Failed) status code indicates that one or more
626    conditions given in the request header fields evaluated to false when
627    tested on the server.  This response code allows the client to place
628    preconditions on the current resource state (its current
629    representations and metadata) and, thus, prevent the request method
630    from being applied if the target resource is in an unexpected state.
631
632
633Section 5., paragraph 1:
634OLD:
635
636    Except when excluded below, a recipient cache or origin server MUST
637    evaluate received request preconditions after it has successfully
638    performed its normal request checks and just before it would perform
639    the action associated with the request method.  A server MUST ignore
640    all received preconditions if its response to the same request
641    without those conditions would have been a status code other than a
642    2xx or 412 (Precondition Failed).  In other words, redirects and
643    failures take precedence over the evaluation of preconditions in
644    conditional requests.
645
646NEW:
647
648    Except when excluded below, a recipient cache or origin server MUST
649    evaluate received request preconditions after it has successfully
650    performed its normal request checks and just before it would perform
651    the action associated with the request method.  A server MUST ignore
652    all received preconditions if its response to the same request
653    without those conditions would have been a status code other than a
654    2xx (Successful) or 412 (Precondition Failed).  In other words,
655    redirects and failures take precedence over the evaluation of
656    preconditions in conditional requests.
657
658
659Section 5., paragraph 2:
660OLD:
661
662    A server that is not the origin server for the target resource and
663    cannot act as a cache for requests on the target resource MUST NOT
664    evaluate the conditional request header fields defined by this
665    specification, and MUST forward them if the request is forwarded,
666    since the generating client intends that they be evaluated by a
667    server that can provide a current representation.  Likewise, a server
668    MUST ignore the conditional request header fields defined by this
669    specification when received with a request method that does not
670    involve the selection or modification of a selected representation,
671    such as CONNECT, OPTIONS, or TRACE.
672
673NEW:
674
675    A server that is not the origin server for the target resource and
676    cannot act as a cache for requests on the target resource MUST NOT
677    evaluate the conditional request header fields defined by this
678    specification, and it MUST forward them if the request is forwarded,
679    since the generating client intends that they be evaluated by a
680    server that can provide a current representation.  Likewise, a server
681    MUST ignore the conditional request header fields defined by this
682    specification when received with a request method that does not
683    involve the selection or modification of a selected representation,
684    such as CONNECT, OPTIONS, or TRACE.
685
686
687Section 7.1., paragraph 1:
688OLD:
689
690    The "Hypertext Transfer Protocol (HTTP) Status Code Registry" located
691    at <http://www.iana.org/assignments/http-status-codes> has been
692    updated with the registrations below:
693
694NEW:
695
696    The "HTTP Status Codes" registry located at
697    <http://www.iana.org/assignments/http-status-codes> has been updated
698    with the registrations below:
699
700
701Section 7.2., paragraph 1:
702OLD:
703
704    HTTP header fields are registered within the "Message Headers"
705    registry maintained at
706    <http://www.iana.org/assignments/message-headers/>.
707
708NEW:
709
710    HTTP header fields are registered within the Message Header Field
711    Registry maintained at
712    <http://www.iana.org/assignments/message-headers/>.
713
714
715Section 7.2., paragraph 2:
716OLD:
717
718    This document defines the following HTTP header fields, so the
719    "Permanent Message Header Field Names" registry has been updated
720    accordingly (see [BCP90]).
721
722NEW:
723
724    This document defines the following HTTP header fields, so their
725    associated registry entries have been updated according to the
726    permanent registrations below (see [BCP90]):
727
728
729Section 8., paragraph 1:
730OLD:
731
732    This section is meant to inform developers, information providers,
733    and users of known security concerns specific to the HTTP conditional
734    request mechanisms.  More general security considerations are
735    addressed in HTTP messaging [RFC7230] and semantics [RFC7231].
736
737NEW:
738
739    This section is meant to inform developers, information providers,
740    and users of known security concerns specific to the HTTP conditional
741    request mechanisms.  More general security considerations are
742    addressed in the HTTP messaging [RFC7230] and semantics [RFC7231]
743    documents.
744
745
746Section 10.1., paragraph 3:
747OLD:
748
749    [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
750               Protocol (HTTP/1.1): Message Syntax and Routing",
751               draft-ietf-httpbis-p1-messaging-latest (work in progress),
752               May 2014.
753
754NEW:
755
756    [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
757               Protocol (HTTP/1.1): Message Syntax and Routing",
758               RFC 7230, May 2014.
759
760
761Section 10.1., paragraph 4:
762OLD:
763
764    [RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
765               Protocol (HTTP/1.1): Semantics and Content",
766               draft-ietf-httpbis-p2-semantics-latest (work in progress),
767               May 2014.
768
769NEW:
770
771    [RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
772               Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
773               May 2014.
774
775
776Section 10.1., paragraph 5:
777OLD:
778
779    [RFC7233]  Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
780               "Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
781               draft-ietf-httpbis-p5-range-latest (work in progress),
782               May 2014.
783
784NEW:
785
786    [RFC7233]  Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
787               "Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
788               RFC 7233, May 2014.
789
790
791Section 10.1., paragraph 6:
792OLD:
793
794    [RFC7234]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
795               Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
796               draft-ietf-httpbis-p6-cache-latest (work in progress),
797               May 2014.
798
799NEW:
800
801    [RFC7234]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
802               Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
803               RFC 7234, May 2014.
804
805
806Appendix A., paragraph 1:
807OLD:
808
809    The definition of validator weakness has been expanded and clarified.
810    (Section 2.1)
811
812NEW:
813
814    The definition of validator weakness has been expanded and clarified
815    (Section 2.1).
816
817
818Appendix A., paragraph 2:
819OLD:
820
821    Weak entity-tags are now allowed in all requests except range
822    requests.  (Sections 2.1 and 3.2)
823    The ETag header field ABNF has been changed to not use quoted-string,
824    thus avoiding escaping issues.  (Section 2.3)
825
826NEW:
827
828    Weak entity-tags are now allowed in all requests except range
829    requests.  (Sections 2.1 and 3.2.)
830 
831    The ETag header field ABNF has been changed to not use quoted-string,
832    thus avoiding escaping issues (Section 2.3).
833
834
835Appendix A., paragraph 3:
836OLD:
837
838    ETag is defined to provide an entity tag for the selected
839    representation, thereby clarifying what it applies to in various
840    situations (such as a PUT response).  (Section 2.3)
841
842NEW:
843
844    ETag is defined to provide an entity tag for the selected
845    representation, thereby clarifying what it applies to in various
846    situations (such as a PUT response) (Section 2.3).
847
848
849Appendix A., paragraph 4:
850OLD:
851
852    The precedence for evaluation of conditional requests has been
853    defined.  (Section 6)
854
855NEW:
856
857    The precedence for evaluation of conditional requests has been
858    defined (Section 6).
859
860
861Appendix B., paragraph 3:
862OLD:
863
864      OWS           = <OWS, see [RFC7230], Section 3.2.3>
865      obs-text      = <obs-text, see [RFC7230], Section 3.2.6>
866
867NEW:
868
869      OWS           = <OWS, defined in [RFC7230], Section 3.2.3>
870      obs-text      = <obs-text, defined in [RFC7230], Section 3.2.6>
871
872
873Appendix B., paragraph 4:
874OLD:
875
876    The rules below are defined in other parts:
877
878NEW:
879
880    The rule below is defined in [RFC7231]:
881
882
883Appendix B., paragraph 5:
884OLD:
885
886      HTTP-date     = <HTTP-date, see [RFC7231], Section 7.1.1.1>
887
888NEW:
889
890      HTTP-date     = <HTTP-date, defined in [RFC7231], Section 7.1.1.1>
891
892
893Section 1.2, paragraph 2:
894OLD:
895
896    HTTP-date = <HTTP-date, see [RFC7231], Section 7.1.1.1>
897
898NEW:
899
900    HTTP-date = <HTTP-date, defined in [RFC7231], Section 7.1.1.1>
901
902
903Section 1.2, paragraph 5:
904OLD:
905
906    OWS = <OWS, see [RFC7230], Section 3.2.3>
907
908NEW:
909
910    OWS = <OWS, defined in [RFC7230], Section 3.2.3>
911
912
913Section 1.2, paragraph 7:
914OLD:
915
916    obs-text = <obs-text, see [RFC7230], Section 3.2.6>
917    opaque-tag = DQUOTE *etagc DQUOTE
918
919NEW:
920
921    obs-text = <obs-text, defined in [RFC7230], Section 3.2.6>
922    opaque-tag = DQUOTE *etagc DQUOTE
923
Note: See TracBrowser for help on using the repository browser.