Ignore:
Timestamp:
13/05/14 14:35:29 (7 years ago)
Author:
julian.reschke@…
Message:

punctuation, title case etc (#553)

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/auth48/rfc7232.abdiff.txt

    r2668 r2669  
    9797
    9898
    99 Section 10., paragraph 0:
    100 OLD:
    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 
    140 NEW:
    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 
    18199Section 2., paragraph 1:
    182100OLD:
     
    186104    modification dates (Section 2.2) and opaque entity tags
    187105    (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.
     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.
    192110
    193111NEW:
     
    267185
    268186
    269 Section 2.2.2., paragraph 12:
    270 OLD:
    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 
    282 NEW:
    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 
    295 Section 2.3., paragraph 4:
    296 OLD:
    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 
    303 NEW:
    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 
    311 Section 2.3.1., paragraph 3:
    312 OLD:
    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 
    321 NEW:
    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 
    331 Section 2.3.2., paragraph 1:
    332 OLD:
    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 
    337 NEW:
    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 
    343 Section 2.3.2., paragraph 4:
    344 OLD:
    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 
    349 NEW:
    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 
    355 Section 2.3.2., paragraph 6:
    356 OLD:
    357 
    358  2.3.3.  Example: Entity-tags Varying on Content-Negotiated Resources
    359 
    360 NEW:
    361 
    362  2.3.3.  Example: Entity-Tags Varying on Content-Negotiated Resources
    363 
    364 
    365 Section 3.4, paragraph 12:
    366 OLD:
    367 
    368  2.4.  When to Use Entity-tags and Last-Modified Dates
    369 
    370 NEW:
    371 
    372  2.4.  When to Use Entity-Tags and Last-Modified Dates
    373 
    374 
    375187Section 3.1., paragraph 8:
    376188OLD:
    377189
    378190    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
     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
    382194    has verified that a state change is being requested and the final
    383195    state is already reflected in the current state of the target
     
    407219
    408220
    409 Section 304, paragraph 3:
    410 OLD:
    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 
    418 NEW:
    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 
    427 Section 3.3., paragraph 8:
    428 OLD:
    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 
    435 NEW:
    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 
    443 Section 3.4., paragraph 5:
    444 OLD:
    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 
    452 NEW:
    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 
    461 Section 3.4., paragraph 9:
    462 OLD:
    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 
    481 NEW:
    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.
     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.
    499239
    500240
     
    504244    The "If-Range" header field provides a special conditional request
    505245    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].
     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].
    510250
    511251NEW:
     
    519259
    520260
    521 Section 4.1., paragraph 1:
    522 OLD:
    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 
    534 NEW:
    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 
    547261Section 4.1., paragraph 2:
    548262OLD:
     
    609323    A 304 (Not Modified) response cannot contain a message-body; it is
    610324    always terminated by the first empty line after the header fields.
    611 
    612 
    613 Section 4.2., paragraph 1:
    614 OLD:
    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 
    623 NEW:
    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.
    631325
    632326
Note: See TracChangeset for help on using the changeset viewer.