Push and Cache Interaction

[MikeBishop]

This is okay for now, but it should be improved eventually to talk about browser state separately from the cache. IOW, define push as part of the browser history (prehistory) because this is entirely separate from a cache (even if they use the same storage handles).

Originally posted by @royfielding in #3407

@MikeBishop:

Push isn't part of the cache, but it does use the definition of "cacheable" -- do you think it should be pointing elsewhere?

@mnot:

This is a very murky area, still.

[mnot]

I would be very concerned if H3 started defining push in a way that's more specific / different to H2. If we're going to "clean up" push, it should be done across the board, and by the HTTP wg.

[mnot]

See also whatwg/fetch#354

[larseggert]

This sounds like a design issue, but I defer to the HTTP folks to categorize it.

[MikeBishop]

I agree; I think my ideal outcome here would be to leave it as-is, or failing that, for another document to have appropriate text I can point to. The issue exists mostly to ensure we didn't lose Roy's unaddressed comment when I merged the PR.

[LPardue]

I think this is out of scope for the work in QUIC WG.

[royfielding]

My comment was intended to be editorial for QUIC, but it is also critical to understand from an implementation perspective (regardless of protocol).

When a browser makes a request and receives a 2xx response, that response is not "part of the cache". It is part of the working state (hypertext workspace) for the user agent (windows/tabs/history). The response may also be cached, but the working state is not subject to cache controls or freshness. The same should be true for push or it won't be usable for non-cached session-specific content.

I don't need QUIC to redefine that. It's actually something that should be defined by user agents (Fetch). What I need is for the HTTP/3 text to be consistent with the existing distinction between the working state of a user agent and the terminology for a cache. They are distinct on purpose. We should probably reinforce that in http-core as well, beyond the brief section in Caching.

I'd prefer that we keep this open (editorial) until I get a chance to review the next draft version.

[MikeBishop]

@royfielding, have you had a chance to review the draft?

[MikeBishop]

@royfielding, it's been a month since I last asked and six since you last commented. You can re-open or file a new issue if you review the draft and find something.

[royfielding]

I honestly don't know if the changes fixed anything or not. The sections on push don't seem to prevent storage aside from the cache, so that's fine.

I did spot a different issue related to push requirements that I can add separately.