If a request with auth 1 is made, and the response is cache-control: public or some other shareable cache directive, then any subsequent requests with auth 2 will return directly from the client side cache.
This can cause push promises to be cancelled if auth1 expires. To fix this, there should be a mechanism that forces the auth2 request through to the server.
To do this, the http2-cache.js could store the original authorization field for the request in the cache entries for all subsequently delivered push promises (note, these push promises may or may not already have that authorization header attached). If it is not present in the push promise request, then it should add the value. Part 2) when a application initiated request does not match the authorization field, then the client side cache should send the request regardless of cache-control: public or other shareable cache directive
also asked for an etag to be put on the new auth request with the data from the old auth request, such that a 304 can result in not needing to update the cache
If a request with auth 1 is made, and the response is
cache-control: public
or some other shareable cache directive, then any subsequent requests with auth 2 will return directly from the client side cache.This can cause push promises to be cancelled if auth1 expires. To fix this, there should be a mechanism that forces the auth2 request through to the server.
To do this, the http2-cache.js could store the original authorization field for the request in the cache entries for all subsequently delivered push promises (note, these push promises may or may not already have that authorization header attached). If it is not present in the push promise request, then it should add the value. Part 2) when a application initiated request does not match the authorization field, then the client side cache should send the request regardless of cache-control: public or other shareable cache directive