Re: [Technical Errata Reported] RFC9111 (7695)

["Roy T. Fielding" <[e-mail]>]

The suggestion is not a desired solution for the problematic text.

This part is not an error in the specification. Even when If-Match and
If-Unmodified-Since are not applicable to a cache, their presence
does not imply that the request must be forwarded to the origin.
It will depend on other factors in the request and how/where
the cache has been configured.

The errata comments assume that cache == cache server, whereas
RFC9111 defines a cache in general. Caches are not required to
forward requests -- they choose to do so when that is necessary
to fulfill their purpose.

OTOH, what might be an error in RFC9111 is the general statement that

   If-Match and If-Unmodified-Since conditional header
   fields are not applicable to a cache

given that both header fields are defined in RFC9110 as a
cache MAY ignore, not MUST ignore. The reason it is a MAY ignore
here is because HTTP defined this as a feature back in 1996 or so.
Hierarchical cache meshes can use conditional GET mechanisms
to backfill partially cached entries, even if the origin would
have offered a different representation, and they might choose
to do so with If-Match (instead of If-Range) if they do not want
the content transferred when updated (i.e., they will remove
their cache entry instead).

This is a deliberate feature -- a choice being made by the client.
If the client does not want this feature, they won't send If-Match
or If-Unmodified-Since on a GET request. They will send If-Range.
This does not result in an invalid response being returned; it is
exactly the response that was requested and was defined as being
valid by the origin server that supplied it in the first place.

Likewise, RFC9110 section 13.2.2 is somewhat misleading
because it attempts to summarize the MUST requirements without
also noting that recipients MAY process If-Match and
If-Unmodified-Since on GET.

So, I understand why the reporter considers this to be errata,
but this isn't a viable solution.

....Roy


> On Nov 7, 2023, at 9:42 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
>