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

INTRODUCTION, paragraph 1:
OLD:

 HTTPbis Working Group                                   R. Fielding, Ed.
 Internet-Draft                                                     Adobe
 Obsoletes: 2616 (if approved)                            J. Reschke, Ed.
 Intended status: Standards Track                              greenbytes
 Expires: November 15, 2014                                  May 14, 2014

NEW:

 Internet Engineering Task Force (IETF)                  R. Fielding, Ed.
 Request for Comments: 7232                                         Adobe
 Obsoletes: 2616                                          J. Reschke, Ed.
 Category: Standards Track                                     greenbytes
 ISSN: 2070-1721                                                 May 2014


INTRODUCTION, paragraph 2:
OLD:

       Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests
                 draft-ietf-httpbis-p4-conditional-latest

NEW:

       Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests


INTRODUCTION, paragraph 5:
OLD:

 Editorial Note (To be removed by RFC Editor)
 
    Discussion of this draft takes place on the HTTPBIS working group
    mailing list (ietf-http-wg@w3.org), which is archived at
    <http://lists.w3.org/Archives/Public/ietf-http-wg/>.
 
    The current issues list is at
    <http://tools.ietf.org/wg/httpbis/trac/report/3> and related
    documents (including fancy diffs) can be found at
    <http://tools.ietf.org/wg/httpbis/>.
 
    _This is a temporary document for the purpose of tracking the
    editorial changes made during the AUTH48 (RFC publication) phase._
 
 Status of This Memo

NEW:

 Status of This Memo


INTRODUCTION, paragraph 6:
OLD:

    This Internet-Draft is submitted in full conformance with the
    provisions of BCP 78 and BCP 79.

NEW:

    This is an Internet Standards Track document.


INTRODUCTION, paragraph 7:
OLD:

    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF).  Note that other groups may also distribute
    working documents as Internet-Drafts.  The list of current Internet-
    Drafts is at http://datatracker.ietf.org/drafts/current/.

NEW:

    This document is a product of the Internet Engineering Task Force
    (IETF).  It represents the consensus of the IETF community.  It has
    received public review and has been approved for publication by the
    Internet Engineering Steering Group (IESG).  Further information on
    Internet Standards is available in Section 2 of RFC 5741.


INTRODUCTION, paragraph 8:
OLD:

    Internet-Drafts are draft documents valid for a maximum of six months
    and may be updated, replaced, or obsoleted by other documents at any
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."
    This Internet-Draft will expire on November 15, 2014.

NEW:

    Information about the current status of this document, any errata,
    and how to provide feedback on it may be obtained at
    http://www.rfc-editor.org/info/rfc7232.


Section 2., paragraph 1:
OLD:

    This specification defines two forms of metadata that are commonly
    used to observe resource state and test for preconditions:
    modification dates (Section 2.2) and opaque entity tags
    (Section 2.3).  Additional metadata that reflects resource state has
    been defined by various extensions of HTTP, such as Web Distributed
    Authoring and Versioning (WebDAV, [RFC4918]), that are beyond the
    scope of this specification.  A resource metadata value is referred
    to as a "validator" when it is used within a precondition.

NEW:

    This specification defines two forms of metadata that are commonly
    used to observe resource state and test for preconditions:
    modification dates (Section 2.2) and opaque entity tags
    (Section 2.3).  Additional metadata that reflects resource state has
    been defined by various extensions of HTTP, such as Web Distributed
    Authoring and Versioning (WebDAV) [RFC4918], that are beyond the
    scope of this specification.  A resource metadata value is referred
    to as a "validator" when it is used within a precondition.


Section 2.1., paragraph 3:
OLD:

    A strong validator might change for reasons other than a change to
    the representation data, such as when a semantically significant part
    of the representation metadata is changed (e.g., Content-Type), but
    it is in the best interests of the origin server to only change the
    value when it is necessary to invalidate the stored responses held by
    remote caches and authoring tools.

NEW:

    A strong validator might change for reasons other than a change to
    the representation data, such as when a semantically significant part
    of the representation metadata is changed (e.g., Content-Type), but
    it is in the best interests of the origin server to change only the
    value when it is necessary to invalidate the stored responses held by
    remote caches and authoring tools.


Section 2.2.2., paragraph 5:
OLD:

    o  The validator is about to be used by a client in an If-Modified-
       Since, If-Unmodified-Since, or If-Range header field, because the
       client has a cache entry for the associated representation, and

NEW:

    o  The validator is about to be used by a client in an If-Modified-
       Since or If-Unmodified-Since header field, because the client has
       a cache entry, or If-Range for the associated representation, and


Section 3.1., paragraph 8:
OLD:

    An origin server MUST NOT perform the requested method if a received
    If-Match condition evaluates to false; instead, the origin server
    MUST respond with either a) the 412 (Precondition Failed) status code
    or b) one of the 2xx (Successful) status codes if the origin server
    has verified that a state change is being requested and the final
    state is already reflected in the current state of the target
    resource (i.e., the change requested by the user agent has already
    succeeded, but the user agent might not be aware of it, perhaps
    because the prior response was lost or a compatible change was made
    by some other user agent).  In the latter case, the origin server
    MUST NOT send a validator header field in the response unless it can
    verify that the request is a duplicate of an immediately prior change
    made by the same user agent.

NEW:

    An origin server MUST NOT perform the requested method if a received
    If-Match condition evaluates to false; instead, the origin server
    MUST respond with either: a) the 412 (Precondition Failed) status
    code or b) one of the 2xx (Successful) status codes if the origin
    server has verified that a state change is being requested and the
    final state is already reflected in the current state of the target
    resource (i.e., the change requested by the user agent has already
    succeeded, but the user agent might not be aware of it, perhaps
    because the prior response was lost or a compatible change was made
    by some other user agent).  In the latter case, the origin server
    MUST NOT send a validator header field in the response unless it can
    verify that the request is a duplicate of an immediately prior change
    made by the same user agent.


Section 3.3., paragraph 5:
OLD:

    A recipient MUST ignore If-Modified-Since if the request contains an
    If-None-Match header field; the condition in If-None-Match is
    considered to be a more accurate replacement for the condition in If-
    Modified-Since, and the two are only combined for the sake of
    interoperating with older intermediaries that might not implement If-
    None-Match.

NEW:

    A recipient MUST ignore If-Modified-Since if the request contains an
    If-None-Match header field; the condition in If-None-Match is
    considered to be a more accurate replacement for the condition in If-
    Modified-Since and the two are only combined for the sake of
    interoperating with older intermediaries that might not implement If-
    None-Match.


Section 3.5., paragraph 1:
OLD:

    The "If-Range" header field provides a special conditional request
    mechanism that is similar to the If-Match and If-Unmodified-Since
    header fields but that instructs the recipient to ignore the Range
    header field if the validator doesn't match, resulting in transfer of
    the new selected representation instead of a 412 response.  If-Range
    is defined in Section 3.2 of [RFC7233].

NEW:

    The "If-Range" header field provides a special conditional request
    mechanism that is similar to the If-Match and If-Unmodified-Since
    header fields but that instructs the recipient to ignore the Range
    header field if the validator doesn't match, resulting in transfer of
    the new selected representation instead of a 412 (Precondition
    Failed) response.  If-Range is defined in Section 3.2 of [RFC7233].


Section 4.1., paragraph 2:
OLD:

    The server generating a 304 response MUST generate any of the
    following header fields that would have been sent in a 200 (OK)
    response to the same request: Cache-Control, Content-Location, Date,
    ETag, Expires, and Vary.

NEW:

    The server generating a 304 (Not Modified) response MUST generate any
    of the following header fields that would have been sent in a 200
    (OK) response to the same request: Cache-Control, Content-Location,
    Date, ETag, Expires, and Vary.


Section 4.1., paragraph 3:
OLD:

    Since the goal of a 304 response is to minimize information transfer
    when the recipient already has one or more cached representations, a
    sender SHOULD NOT generate representation metadata other than the
    above listed fields unless said metadata exists for the purpose of
    guiding cache updates (e.g., Last-Modified might be useful if the
    response does not have an ETag field).

NEW:

    Since the goal of a 304 (Not Modified) response is to minimize
    information transfer when the recipient already has one or more
    cached representations, a sender SHOULD NOT generate representation
    metadata other than the above listed fields unless said metadata
    exists for the purpose of guiding cache updates (e.g., Last-Modified
    might be useful if the response does not have an ETag field).


Section 4.1., paragraph 4:
OLD:

    Requirements on a cache that receives a 304 response are defined in
    Section 4.3.4 of [RFC7234].  If the conditional request originated
    with an outbound client, such as a user agent with its own cache
    sending a conditional GET to a shared proxy, then the proxy SHOULD
    forward the 304 response to that client.

NEW:

    Requirements on a cache that receives a 304 (Not Modified) response
    are defined in Section 4.3.4 of [RFC7234].  If the conditional
    request originated with an outbound client, such as a user agent with
    its own cache sending a conditional GET to a shared proxy, then the
    proxy SHOULD forward the 304 (Not Modified) response to that client.


Section 4.1., paragraph 5:
OLD:

    A 304 response cannot contain a message-body; it is always terminated
    by the first empty line after the header fields.

NEW:

    A 304 (Not Modified) response cannot contain a message-body; it is
    always terminated by the first empty line after the header fields.


Section 5., paragraph 1:
OLD:

    Except when excluded below, a recipient cache or origin server MUST
    evaluate received request preconditions after it has successfully
    performed its normal request checks and just before it would perform
    the action associated with the request method.  A server MUST ignore
    all received preconditions if its response to the same request
    without those conditions would have been a status code other than a
    2xx or 412 (Precondition Failed).  In other words, redirects and
    failures take precedence over the evaluation of preconditions in
    conditional requests.

NEW:

    Except when excluded below, a recipient cache or origin server MUST
    evaluate received request preconditions after it has successfully
    performed its normal request checks and just before it would perform
    the action associated with the request method.  A server MUST ignore
    all received preconditions if its response to the same request
    without those conditions would have been a status code other than a
    2xx (Successful) or 412 (Precondition Failed).  In other words,
    redirects and failures take precedence over the evaluation of
    preconditions in conditional requests.


Section 7.1., paragraph 1:
OLD:

    The "Hypertext Transfer Protocol (HTTP) Status Code Registry" located
    at <http://www.iana.org/assignments/http-status-codes> has been
    updated with the registrations below:

NEW:

    The "HTTP Status Codes" registry located at
    <http://www.iana.org/assignments/http-status-codes> has been updated
    with the registrations below:


Section 7.2., paragraph 1:
OLD:

    HTTP header fields are registered within the "Message Headers"
    registry maintained at
    <http://www.iana.org/assignments/message-headers/>.

NEW:

    HTTP header fields are registered within the Message Header Field
    Registry maintained at
    <http://www.iana.org/assignments/message-headers/>.


Section 7.2., paragraph 2:
OLD:

    This document defines the following HTTP header fields, so the
    "Permanent Message Header Field Names" registry has been updated
    accordingly (see [BCP90]).

NEW:

    This document defines the following HTTP header fields, so their
    associated registry entries have been updated according to the
    permanent registrations below (see [BCP90]):


Section 8., paragraph 1:
OLD:

    This section is meant to inform developers, information providers,
    and users of known security concerns specific to the HTTP conditional
    request mechanisms.  More general security considerations are
    addressed in HTTP messaging [RFC7230] and semantics [RFC7231].

NEW:

    This section is meant to inform developers, information providers,
    and users of known security concerns specific to the HTTP conditional
    request mechanisms.  More general security considerations are
    addressed in the HTTP messaging [RFC7230] and semantics [RFC7231]
    documents.


Section 10.1., paragraph 3:
OLD:

    [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
               Protocol (HTTP/1.1): Message Syntax and Routing",
               draft-ietf-httpbis-p1-messaging-latest (work in progress),
               May 2014.

NEW:

    [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
               Protocol (HTTP/1.1): Message Syntax and Routing",
               RFC 7230, May 2014.


Section 10.1., paragraph 4:
OLD:

    [RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
               Protocol (HTTP/1.1): Semantics and Content",
               draft-ietf-httpbis-p2-semantics-latest (work in progress),
               May 2014.

NEW:

    [RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
               Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
               May 2014.


Section 10.1., paragraph 5:
OLD:

    [RFC7233]  Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
               "Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
               draft-ietf-httpbis-p5-range-latest (work in progress),
               May 2014.

NEW:

    [RFC7233]  Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
               "Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
               RFC 7233, May 2014.


Section 10.1., paragraph 6:
OLD:

    [RFC7234]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
               Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
               draft-ietf-httpbis-p6-cache-latest (work in progress),
               May 2014.

NEW:

    [RFC7234]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
               Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
               RFC 7234, May 2014.


Appendix A., paragraph 1:
OLD:

    The definition of validator weakness has been expanded and clarified.
    (Section 2.1)

NEW:

    The definition of validator weakness has been expanded and clarified
    (Section 2.1).


Appendix A., paragraph 2:
OLD:

    Weak entity-tags are now allowed in all requests except range
    requests.  (Sections 2.1 and 3.2)
    The ETag header field ABNF has been changed to not use quoted-string,
    thus avoiding escaping issues.  (Section 2.3)

NEW:

    Weak entity-tags are now allowed in all requests except range
    requests.  (Sections 2.1 and 3.2.)
 
    The ETag header field ABNF has been changed to not use quoted-string,
    thus avoiding escaping issues (Section 2.3).


Appendix A., paragraph 3:
OLD:

    ETag is defined to provide an entity tag for the selected
    representation, thereby clarifying what it applies to in various
    situations (such as a PUT response).  (Section 2.3)

NEW:

    ETag is defined to provide an entity tag for the selected
    representation, thereby clarifying what it applies to in various
    situations (such as a PUT response) (Section 2.3).


Appendix A., paragraph 4:
OLD:

    The precedence for evaluation of conditional requests has been
    defined.  (Section 6)

NEW:

    The precedence for evaluation of conditional requests has been
    defined (Section 6).


Appendix B., paragraph 3:
OLD:

      OWS           = <OWS, see [RFC7230], Section 3.2.3>
      obs-text      = <obs-text, see [RFC7230], Section 3.2.6>

NEW:

      OWS           = <OWS, defined in [RFC7230], Section 3.2.3>
      obs-text      = <obs-text, defined in [RFC7230], Section 3.2.6>


Appendix B., paragraph 4:
OLD:

    The rules below are defined in other parts:

NEW:

    The rule below is defined in [RFC7231]:


Appendix B., paragraph 5:
OLD:

      HTTP-date     = <HTTP-date, see [RFC7231], Section 7.1.1.1>

NEW:

      HTTP-date     = <HTTP-date, defined in [RFC7231], Section 7.1.1.1>


Section 1.2, paragraph 2:
OLD:

    HTTP-date = <HTTP-date, see [RFC7231], Section 7.1.1.1>

NEW:

    HTTP-date = <HTTP-date, defined in [RFC7231], Section 7.1.1.1>


Section 1.2, paragraph 5:
OLD:

    OWS = <OWS, see [RFC7230], Section 3.2.3>

NEW:

    OWS = <OWS, defined in [RFC7230], Section 3.2.3>


Section 1.2, paragraph 7:
OLD:

    obs-text = <obs-text, see [RFC7230], Section 3.2.6>
    opaque-tag = DQUOTE *etagc DQUOTE

NEW:

    obs-text = <obs-text, defined in [RFC7230], Section 3.2.6>
    opaque-tag = DQUOTE *etagc DQUOTE