[Technical Errata Reported] RFC9111 (7695)

[RFC Errata System <[e-mail]>]

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