
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: December 8, 2014                                   June 6, 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                                                June 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 December 8, 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.


INTRODUCTION, paragraph 14:
OLD:

    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
      1.1.  Conformance and Error Handling . . . . . . . . . . . . . .  4
      1.2.  Syntax Notation  . . . . . . . . . . . . . . . . . . . . .  4
    2.  Validators . . . . . . . . . . . . . . . . . . . . . . . . . .  5
      2.1.  Weak versus Strong . . . . . . . . . . . . . . . . . . . .  5
      2.2.  Last-Modified  . . . . . . . . . . . . . . . . . . . . . .  7
        2.2.1.  Generation . . . . . . . . . . . . . . . . . . . . . .  7
        2.2.2.  Comparison . . . . . . . . . . . . . . . . . . . . . .  8
      2.3.  ETag . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
        2.3.1.  Generation . . . . . . . . . . . . . . . . . . . . . . 10
        2.3.2.  Comparison . . . . . . . . . . . . . . . . . . . . . . 10
        2.3.3.  Example: Entity-Tags Varying on Content-Negotiated
                Resources  . . . . . . . . . . . . . . . . . . . . . . 11
      2.4.  When to Use Entity-Tags and Last-Modified Dates  . . . . . 12
    3.  Precondition Header Fields . . . . . . . . . . . . . . . . . . 13
      3.1.  If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 13
      3.2.  If-None-Match  . . . . . . . . . . . . . . . . . . . . . . 14
      3.3.  If-Modified-Since  . . . . . . . . . . . . . . . . . . . . 15
      3.4.  If-Unmodified-Since  . . . . . . . . . . . . . . . . . . . 16
      3.5.  If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 18
    4.  Status Code Definitions  . . . . . . . . . . . . . . . . . . . 18
      4.1.  304 Not Modified . . . . . . . . . . . . . . . . . . . . . 18
      4.2.  412 Precondition Failed  . . . . . . . . . . . . . . . . . 18
    5.  Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . 19
    6.  Precedence . . . . . . . . . . . . . . . . . . . . . . . . . . 19
    7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 21
      7.1.  Status Code Registration . . . . . . . . . . . . . . . . . 21
      7.2.  Header Field Registration  . . . . . . . . . . . . . . . . 21
    8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 22
    9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 22
    10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
      10.1. Normative References . . . . . . . . . . . . . . . . . . . 23
      10.2. Informative References . . . . . . . . . . . . . . . . . . 23
    Appendix A.  Changes from RFC 2616 . . . . . . . . . . . . . . . . 23
    Appendix B.  Imported ABNF . . . . . . . . . . . . . . . . . . . . 24
    Appendix C.  Collected ABNF  . . . . . . . . . . . . . . . . . . . 24
    Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

NEW:

    1. Introduction ....................................................4
       1.1. Conformance and Error Handling .............................4
       1.2. Syntax Notation ............................................4
    2. Validators ......................................................5
       2.1. Weak versus Strong .........................................5
       2.2. Last-Modified ..............................................7
            2.2.1. Generation ..........................................7
            2.2.2. Comparison ..........................................8
       2.3. ETag .......................................................9
            2.3.1. Generation .........................................10
            2.3.2. Comparison .........................................10
            2.3.3. Example: Entity-Tags Varying on
                   Content-Negotiated Resources .......................11
       2.4. When to Use Entity-Tags and Last-Modified Dates ...........12
    3. Precondition Header Fields .....................................13
       3.1. If-Match ..................................................13
       3.2. If-None-Match .............................................14
       3.3. If-Modified-Since .........................................16
       3.4. If-Unmodified-Since .......................................17
       3.5. If-Range ..................................................18
    4. Status Code Definitions ........................................18
       4.1. 304 Not Modified ..........................................18
       4.2. 412 Precondition Failed ...................................19
    5. Evaluation .....................................................19
    6. Precedence .....................................................20
    7. IANA Considerations ............................................22
       7.1. Status Code Registration ..................................22
       7.2. Header Field Registration .................................22
    8. Security Considerations ........................................22
    9. Acknowledgments ................................................23
    10. References ....................................................24
       10.1. Normative References .....................................24
       10.2. Informative References ...................................24
    Appendix A. Changes from RFC 2616 .................................25
    Appendix B. Imported ABNF .........................................25
    Appendix C. Collected ABNF ........................................26
    Index .............................................................27


Section 1., paragraph 2:
OLD:

    Conditional GET requests are the most efficient mechanism for HTTP
    cache updates [RFC7234].  Conditionals can also be applied to state-
    changing methods, such as PUT and DELETE, to prevent the "lost
    update" problem: one client accidentally overwriting the work of
    another client that has been acting in parallel.

NEW:

    Conditional GET requests are the most efficient mechanism for HTTP
    cache updates [RFC7234].  Conditionals can also be applied to
    state-changing methods, such as PUT and DELETE, to prevent the "lost
    update" problem: one client accidentally overwriting the work of
    another client that has been acting in parallel.


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, If-Unmodified-Since, or If-Range header field,
       because the client has a cache entry for the associated
       representation, and


Section 2.2.2., paragraph 12:
OLD:

    This method relies on the fact that if two different responses were
    sent by the origin server during the same second, but both had the
    same Last-Modified time, then at least one of those responses would
    have a Date value equal to its Last-Modified time.  The arbitrary 60-
    second limit guards against the possibility that the Date and Last-
    Modified values are generated from different clocks or at somewhat
    different times during the preparation of the response.  An
    implementation MAY use a value larger than 60 seconds, if it is
    believed that 60 seconds is too short.

NEW:

    This method relies on the fact that if two different responses were
    sent by the origin server during the same second, but both had the
    same Last-Modified time, then at least one of those responses would
    have a Date value equal to its Last-Modified time.  The arbitrary
    60-second limit guards against the possibility that the Date and
    Last-Modified values are generated from different clocks or at
    somewhat different times during the preparation of the response.  An
    implementation MAY use a value larger than 60 seconds, if it is
    believed that 60 seconds is too short.


Section 2.3.2., paragraph 3:
OLD:

    o  Weak comparison: two entity-tags are equivalent if their opaque-
       tags match character-by-character, regardless of either or both
       being tagged as "weak".

NEW:

    o  Weak comparison: two entity-tags are equivalent if their
       opaque-tags match character-by-character, regardless of either or
       both being tagged as "weak".


Section 2.4., paragraph 8:
OLD:

    o  SHOULD send the Last-Modified value in non-subrange cache
       validation requests (using If-Modified-Since) if only a Last-
       Modified value has been provided by the origin server.

NEW:

    o  SHOULD send the Last-Modified value in non-subrange cache
       validation requests (using If-Modified-Since) if only a
       Last-Modified value has been provided by the origin server.


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.3., paragraph 9:
OLD:

    When used for cache updates, a cache will typically use the value of
    the cached message's Last-Modified field to generate the field value
    of If-Modified-Since.  This behavior is most interoperable for cases
    where clocks are poorly synchronized or when the server has chosen to
    only honor exact timestamp matches (due to a problem with Last-
    Modified dates that appear to go "back in time" when the origin
    server's clock is corrected or a representation is restored from an
    archived backup).  However, caches occasionally generate the field
    value based on other data, such as the Date header field of the
    cached message or the local clock time that the message was received,
    particularly when the cached message does not contain a Last-Modified
    field.

NEW:

    When used for cache updates, a cache will typically use the value of
    the cached message's Last-Modified field to generate the field value
    of If-Modified-Since.  This behavior is most interoperable for cases
    where clocks are poorly synchronized or when the server has chosen to
    only honor exact timestamp matches (due to a problem with
    Last-Modified dates that appear to go "back in time" when the origin
    server's clock is corrected or a representation is restored from an
    archived backup).  However, caches occasionally generate the field
    value based on other data, such as the Date header field of the
    cached message or the local clock time that the message was received,
    particularly when the cached message does not contain a Last-Modified
    field.


Section 3.3., paragraph 10:
OLD:

    When used for limiting the scope of retrieval to a recent time
    window, a user agent will generate an If-Modified-Since field value
    based on either its own local clock or a Date header field received
    from the server in a prior response.  Origin servers that choose an
    exact timestamp match based on the selected representation's Last-
    Modified field will not be able to help the user agent limit its data
    transfers to only those changed during the specified window.

NEW:

    When used for limiting the scope of retrieval to a recent time
    window, a user agent will generate an If-Modified-Since field value
    based on either its own local clock or a Date header field received
    from the server in a prior response.  Origin servers that choose an
    exact timestamp match based on the selected representation's
    Last-Modified field will not be able to help the user agent limit its
    data transfers to only those changed during the specified window.


Section 3.4., paragraph 5:
OLD:

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

NEW:

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


Section 10.1., paragraph 0:
OLD:

 10.  References
 10.1.  Normative References

NEW:

 10.  References
 
 10.1.  Normative References


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),
               June 2014.

NEW:

    [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
               Protocol (HTTP/1.1): Message Syntax and Routing",
               RFC 7230, June 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),
               June 2014.

NEW:

    [RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
               Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
               June 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),
               June 2014.

NEW:

    [RFC7233]  Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
               "Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
               RFC 7233, June 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),
               June 2014.

NEW:

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


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)


Section 1.2, paragraph 10:
OLD:

    3
       304 Not Modified (status code)  18

NEW:

    3
       304 Not Modified (status code)  19


Section 1.2, paragraph 13:
OLD:

    G
       Grammar
          entity-tag  9
          ETag  9
          etagc  9
          If-Match  13
          If-Modified-Since  15
          If-None-Match  14
          If-Unmodified-Since  16
          Last-Modified  7
          opaque-tag  9
          weak  9

NEW:

    G
       Grammar
          entity-tag  9
          ETag  9
          etagc  9
          If-Match  13
          If-Modified-Since  15
          If-None-Match  14
          If-Unmodified-Since  17
          Last-Modified  7
          opaque-tag  9
          weak  9


Section 1.2, paragraph 14:
OLD:

    I
       If-Match header field  13
       If-Modified-Since header field  15
       If-None-Match header field  14
       If-Unmodified-Since header field  16

NEW:

    I
       If-Match header field  13
       If-Modified-Since header field  16
       If-None-Match header field  14
       If-Unmodified-Since header field  17

