Re: [Technical Errata Reported] RFC9111 (7695)

Hey Roy,

Thanks for the response and the explanation, I am okay with this errata
rejection. Just so that I understand it correctly, the bigger point you are
calling out is: A cache MAY choose to honor If-Match, If-Unmodified-Since
headers i.e. a cache does not necessarily have to a) return 412 on
validation
failure b) or forward the request to origin as per RFC
9111#section-4.3.2-3[1]

> 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).

IMHO we may still want to address what procedure/rules an
intermediary cache should follow/apply to avoid ending up in a split
scenario
as documented in my errata notes. In the current world of multi-cloud
architectures companies are employing where a cache mesh may pan across
multiple
cloud vendors it makes it harder to get consensus on what is and isn't a
valid
behavior across providers, such as in this case a combination of behaviors
may
be valid i.e. a) intermediary cache may return 412 b) intermediary cache
may
serve the cached content as-it-is and let the client validate it. c)
intermediary may choose to forward the request to origin. By definition as
far as
I understand If-Match and If-Unmodified-Since are strong validators;
leaving the
behavior optional causes disagreement which is harder to negotiate or work
around when dealing with multiple large scale vendors i.e. asking cloud
vendors to
align their cache logic with how other cloud vendors are treating
conditional
headers prove to not be a viable option.

I don't have an answer on what might be a better solution at the moment here
however I would love to hear your thoughts on this.

[1]: https://www.rfc-editor.org/rfc/rfc9111#section-4.3.2-3

Thanks
Dron Rathore


On Tue, Nov 7, 2023 at 12:45 PM Roy T. Fielding <fielding@gbiv.com> wrote:

> 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 <rfc-editor@rfc-editor.org>
> 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 <dron.rathore@gmail.com>
> >
> > 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
> >
>
>