Re: [Technical Errata Reported] RFC9111 (7695)

[Dron Rathore <[e-mail]>]

Hey Folks,

Requesting verification for the reported Errata 7695[1] for RFC
9111#section 4.3.2-4[2]. I am okay with moving the Errata to 9110
section-13.1.1 and section 13.1.4 which talks about If-Match and
If-Unmodified-Since header pertaining to cache with "MAY ignore" directive
based upon the input received.

[1]: https://www.rfc-editor.org/errata/eid7695
[2]: https://www.rfc-editor.org/rfc/rfc9111#section-4.3.2-4

Thanks
Dron Rathore

On Tue, Nov 7, 2023 at 9:46 AM RFC Errata System <[e-mail]>
wrote:

> The following errata report has been submitted for RFC9111,
> "HTTP Caching".
>
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7695
>
> --------------------------------------
> Type: Technical
> Reported by: Dron Rathore <[e-mail]>
>
> Section: 4.3.2-4
>
> Original Text
> -------------
>    The proper evaluation of conditional requests by a cache depends on
>    the received precondition header fields and their precedence.  In
>    summary, the If-Match and If-Unmodified-Since conditional header
>    fields are not applicable to a cache, and If-None-Match takes
>    precedence over If-Modified-Since.  See Section 13.2.2 of [HTTP] for
>    a complete specification of precondition precedence.
>
> Corrected Text
> --------------
>    The proper evaluation of conditional requests by a cache depends on
>    the received precondition header fields and their precedence.  In
>    summary, the If-Match and If-Unmodified-Since conditional header
>    fields are not applicable to a cache and hence such requests MUST
>    be forwarded to the origin, and If-None-Match takes precedence
>    over If-Modified-Since.  See Section 13.2.2 of [HTTP] for a complete
>    specification of precondition precedence.
>
> Notes
> -----
> Correction:
> "the If-Match and If-Unmodified-Since conditional header fields are not
> applicable
>  to a cache [and hence such requests MUST be forwarded to the origin]"
>
> This is based upon the reading of RFC 9111#section-4.3.2-3[1]:
>
>    A cache MUST NOT evaluate conditional header fields that only apply
>    to an origin server, occur in a request with semantics that cannot be
>    satisfied with a cached response, or occur in a request with a target
>    resource for which it has no stored responses; such preconditions are
>    likely intended for some other (inbound) server.
>
>
> Current RFC 9110#section-13.1.1-13[2], RFC 9110#section-13.2.2[3] and RFC
> 9111#section-4.3.2-4[4] does not explicitly provide clear direction to
> cache servers as to
> how to deal with If-Match and If-Unmodified-Since conditional headers[5].
>
> The correction intends to provide more clarity for If-Match and
> If-Unmodified-Since
> header as to how a cache server should handle conditional header which are
> meant
> for origin server based on the reading of above produced section of
> the RFC 9111#section-4.3.2-3.
>
> If cache nodes have to ignore If-Match and If-Unmodified-Since header as
> per
> RFC 9110#section-13.1.1-13 then in scenarios where they have a cached
> non-expired
> content representation which can be satisfied sans If-Match and
> If-Unmodified-Since
> headers the same will be returned back by cache and intermediary servers.
>
> Caching layers with multiple content representation cached in the network
> may
> return invalid response back causing higher requests errors when dealing
> with origin
> applicable conditional headers that are sent to intermediary cache nodes
> from
> edge cache nodes for cache hydration.
>
> Consider the below scenario:
>
> 1. A caching system consisting of 2 cache layers with 3 servers each,
> Server nodes "A" representing Edge cache nodes(A1, A2, A3),
> Server nodes "B" representing intermediary cache nodes(B1, B2, B3), and an
> origin server
>
> 2. All cache servers (A and B) make use of If-Match and
> If-Unmodified-Since to
> hydrate their own cached content representation as per RFC
> 9110#section-13.1.1-12 [6]
>
> 3. All cache servers make use of 5MiB chunk ranges for cache hydration of
> large
> files
>
> 4. Origin server contains a file foo with size 20MiB, with content
> representation Etag E1
>
> 5. A client C1 who sends a range request for file foo with range 10-20MiB
> to edge node A1
>
> 6. For initial set of requests sent by edge node A1 the representation E1
> gets
> cached on 2 of the intermediary nodes B1 and B2 (because of 2 requests for
> 5MiB chunk each)
>
> 6. Content representation for file foo changes to Etag E2 on origin
>
> 7. A client C2 who sends a range request for file foo with range 10-20MiB
> to edge node A2
>
> 8. Requests to edge node A2 which does not have a cached representation
> causes it
> to send 2 range requests for 5MiB each, in this case lets assume it is
> sent to
> intermediary cache nodes B1(range:10-15MiB) and B3(range:15-20MiB),
> B3 node faces cache-miss and hydrates its own cache from Range 15Mib-20MiB
> with content representation E2. B1 node already has a cached
> representation E1
> for requested range so it returns it back. A2 node which has now cached
> 10-15MiB E1
> representation received from B1 has to returns error and performs a cache
> reset for
> itself because of mixed representation for the whole user requested range..
>
> In such a case where intermediary cache severs/nodes may end up with
> multiple
> content representation an edge node who is trying to hydrate its own cache
> will find it hard to do so, i.e. the first 5MiB
> chunk may end up being served by intermediary cache nodes with
> representation
> E1 and the other half of the chunk by nodes who have a content
> representation
> E2. The error rates will be higher whenever content representation changes
> at
> the origin server for such range requests.
>
>
> [1]: https://www.rfc-editor.org/rfc/rfc9111#section-4.3.2-3
> [2]: https://www.rfc-editor.org/rfc/rfc9110#section-13.1.1-13
> [3]: https://www.rfc-editor.org/rfc/rfc9110#section-13.2.2
> [4]: https://www.rfc-editor.org/rfc/rfc9111#section-4.3.2-4
> [5]: https://github.com/httpwg/http-core/issues/1111
> [6]: https://www.rfc-editor.org/rfc/rfc9110#section-13.1.1-12
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". (If it is spam, it
> will be removed shortly by the RFC Production Center.) Please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> will log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC9111 (draft-ietf-httpbis-cache-19)
> --------------------------------------
> Title               : HTTP Caching
> Publication Date    : June 2022
> Author(s)           : R. Fielding, Ed., M. Nottingham, Ed., J. Reschke, Ed.
> Category            : INTERNET STANDARD
> Source              : HTTP
> Area                : Applications and Real-Time
> Stream              : IETF
> Verifying Party     : IESG
>
>