http-headershttp2server-pushpush-promise

Does the Browser check conditional headers inside PUSH_PROMISE-frames?

I know that browsers can send RST_STREAM-frames to cancel serverpush.

Does it make sense to send Last-Modified or Etag headers inside the PUSH_PROMISE? Or is the validation of the to-be-pushed resources only based on their URI (as Simone Bordet answered to the following question two years ago)?

Does the browser cancel server push when a resource is in cache?

I couldn't find an exact answer to this question.

Solution

  • When a HTTP/2 server pushes a resource, it generates the PUSH_PROMISE frame to send to the client, and at the same time it creates a synthetic request that is processed as if the remote client sent it.

    Remember that the PUSH_PROMISE frame represent the request that the client would make for that resource, not the response.

    Typically, the content of the PUSH_PROMISE frame headers and the headers of the synthetic request are the same, but - depending on the implementations - it may not be the case.

    Headers Last-Modified or ETag only make sense in responses, so it would not make sense to add them to a PUSH_PROMISE frame.

    Whether it makes sense to add other request headers such as If-Modified-Since to the PUSH_PROMISE depends on whether the same headers are used for the synthetic request. If the same headers are used, as it's typically the case, then adding headers such as If-Modified-Since has only effects on the server-side processing: the server may generate a 304 Not Modified when processing the synthetic request.

    However, it would be strange for a server to send a PUSH_PROMISE for a resource, followed by a 304. If the server knows that the client already has the resource cached, it may as well skip sending the PUSH_PROMISE.

    Adding response headers such as Last-Modified to a PUSH_PROMISE frame does not make sense because a PUSH_PROMISE represents a request.

    Adding conditional request headers such as If-Modified-Since normally requires the server to have some knowledge about what resources were previously served to the client: it has to know whether a resource has already been served so that sending a 304 to the client for a pushed resource will make the client use the resource already present in its cache.