Re: Cache control in trailers?

On Wed, Feb 3, 2021 at 2:29 PM Ryan Sleevi <ryan-ietf@sleevi.com> wrote:
[snip]
>
> The "commit the object at the end or destroy it" is precisely the issue, however. It's a new edge in the state machine, in which an object in the cache could be not-yet-committed, which then makes a number of assumptions potentially problematic. I agree that there are many ways to potentially tackle this, but I highlight it as an example of why it's not very exciting, and thus unlikely to be implemented (just as trailers are not supported in any of our layers beyond basic H/2 message framing, at which point, they get dropped).
>
> For example, consider a situation where there are multiple requests for the same resource. Request 1 comes in, opens up the resource, begins reading the resource while streaming the response into the file and to the caller. Request 2 for that resource comes in, sees that it's available in the cache (even though not fully completed), begins reading that response and streaming to the other caller. In the semantics described, the need for an explicit Commit stage prohibits this, in as much as it's not clear that Request 2 can reuse that resource, because Request 1 might change its mind at the end of the stream.
>

Yes, but there are ways of handling that. If Response to Request 1
indicates a clear signal at the start that it's possible that the
response could be truncated and that it shouldn't be cached unless it
was successfully entirely received, then there are options for Request
2, with the only-if-cached request directive being the obvious blunt
force approach. But response 2 could also be served with either a
status code or a response cache control directive that clearly
indicates that it is pulling from an incomplete cached representation
that could end up failing or truncated, and it could include its own
trailer to indicate its own status accordingly.

> This is akin to the problem others have raised, with respect to policy controls applied early-on/up-front.
>
> Equally, consider a situation where there is a pre-existing resource in the cache, and during opportunistic revalidation, a newer version is available. If that Request decides at the end to not cache, we've now doomed an otherwise usable resource, and need to commit to removing it from the cache.
>

That needn't be the case. The existing resource in the cache can
remain until the new representation is committed, and can even be
served while the new resource is being received and the commit is
pending.

Either way you're right that this non-trivially adds to the state
machine which definitely brings along a number of non-trivial
complexities.

- James

Received on Wednesday, 3 February 2021 23:29:29 UTC