New draft: Maintaining HTTP Integrity Fields in Cached Responses

[Antun Jurkovic <[e-mail]>]

Hi all,

I have submitted an individual Internet-Draft proposing focused
maintenance to RFC 9111:

Maintaining HTTP Integrity Fields in Cached and Cache-Generated Responses
draft-jurkovikj-http-integrity-cache-00
https://datatracker.ietf.org/doc/draft-jurkovikj-http-integrity-cache/

RFC 9111 defines general rules for updating stored response fields,
combining partial responses, and constructing responses from cached
state. Content-Digest and Repr-Digest, defined by RFC 9530, and
Unencoded-Digest, currently defined by
draft-ietf-httpbis-unencoded-digest, apply to specific message content
or representation data.

Applying those general cache rules without accounting for the
semantics of these Integrity fields can associate a digest value with
data different from the data over which it was calculated.

The draft proposes a narrow invariant: a cache preserves the
association between an Integrity field member and its defined input,
recomputes the member over the resulting input, or removes it.

It applies this rule during:

- freshening using 304 and HEAD responses;
- partial-response combination;
- construction of 304 and 206 responses, and responses to HEAD
requests, from stored state; and
- content-coding transformations.

The draft defines no new HTTP field, status code, cache directive,
validator, or digest algorithm. It is intended to update RFC 9111.

I would particularly appreciate feedback on three questions:

1. Is a focused document updating RFC 9111 the right standards vehicle
for these cache-maintenance rules? If so, should the formal Updates
relationship be limited to RFC 9111?

2. Is the preserve, recompute, or remove invariant correct, and are
the proposed association witnesses sufficiently constrained?

For Repr-Digest, the draft permits a matching strong entity tag as a
witness only within the same representation-selection context and not
after a transformation changes the complete coded representation data.

For Unencoded-Digest, it additionally requires the complete effective
decoding configuration to remain unchanged.

3. Are there deployed caches that use a successful HEAD response to
update a stored GET response while retaining its stored content under
RFC 9111 Section 4.3.5, rather than invalidating the stored response
or retrieving a complete response with GET?

This is an individual proposal seeking technical review. I am not
requesting Working Group adoption at this stage.

Thanks,
Antun Jurkovikj