Server Push and Conditional Requests

Thinking about how Server Push interacts with conditional requests <http://httpwg.org/specs/rfc7232.html>, I can see three interesting modes of operation, outlined below.


1. If-Match / If-Unmodified-Since

If the server has immediate access to the response being pushed (e.g., if the server is authoritative for it, or it is fresh in cache), it might want to send conditional headers in the `PUSH_PROMISE` request, to give the client the earliest possible chance to send a `RST_STREAM` (since the promised stream might be delayed due to priorities, etc.).

The most obvious way to do this with existing headers is using `If-Match` and/or `If-Unmodified-Since`; if the validator matches what the client has, it can send a `RST_STREAM`; otherwise, they can wait for the full response (which will presumably have validators matching those sent in the request).

~~~
:method: GET
:scheme: https
:authority: www.example.com
:path: /images/1234.jpg
Host: www.example.com
If-Match: "abcdef"
~~~

Here, when a client receives these headers in a `PUSH_PROMISE`, it can send a `RST_STREAM` if it has a fresh cached response for `https://www.example.com/images/1234.jpg` with the `ETag` "abcdef". If it does not do so, the server will continue to push the successful (`2xx`) response (since the `ETag` does in fact match what is pushed).


2.  If-None-Match / If-Modified-Since

If the server does not have a fresh local copy of the response, but does have access to a stale one (in the meaning of RFC7234), it can `PUSH_PROMISE` with `If-None-Match` and/or `If-Modified-Since`:

~~~
:method: GET
:scheme: https
:authority: www.example.com
:path: /images/5678.jpg
Host: www.example.com
If-None-Match: "lmnop"
~~~

That way, the client again has an opportunity to send `RST_STREAM` if it already has a fresh copy with that validator in cache. 

Once the server has obtained a fresh (possibly validated) response, it can either push a `304 (Not Modified)` response in the case that the `ETag` hasn't changed, or a successful (`2xx`) response if it has.

Note that if the client has a fresh copy in cache, but the server does not, the client can still use the fresh copy; it has not been invalidated just because the server has not kept its copy fresh.


3. 304 (Not Modified) without a Conditional

If the server believes that the client does have a stale but valid copy in its cache (e.g., through the use of a cache digest), it can send a `PUSH_PROMISE` followed by a pushed `304 (Not Modified)` response to revalidate that cached response, thereby making it fresh in the client's cache.

If the server has a local copy of the response that it wishes to use, it can send the PUSH_PROMISE with an `If-None-Match` and/or `If-Modified-Since` conditional, as above. 

However, if it does not, it will still be desirable to generate the `PUSH_PROMISE` as soon as possible, so as to avoid the race described in RFC7540, Section 8.2.1.

To allow this, a request without a conditional can be sent:

~~~
:method: GET
:scheme: https
:authority: www.example.com
:path: /images/9012.jpg
Host: www.example.com
~~~

When the response body is available to the server, it can send a `304 (Not Modified)` if it believes that the client already holds a copy (fresh or stale); however, it MUST include the validators to allow the client to confirm this. For example:

~~~
:status: 304
ETag: "abc123"
Date: Tue, 3 Sep 2016 04:34:12 GMT
Content-Type: image/jpeg
Cache-Control: max-age=3600
~~~

In this case, if the client's cached response does not have the same `ETag` it SHOULD make a request to obtain a fresh response.

On the other hand, if the server determines that the client does not have the appropriate cached response, it can send the full, successful (`2xx`) response:

~~~
:status: 200
ETag: "abc123"
Date: Tue, 3 Sep 2016 04:34:12 GMT
Content-Type: image/jpeg
Cache-Control: max-age=3600

[ body ]
~~~

Note that this approach relies upon an _implicit conditional_ in the PUSH_PROMISE request. If felt necessary, this can be made explicit, for example by defining a new conditional header `If-In-Digest`.



Which of these do people think are interesting to specify, implement and use? Are there problems, or other approaches we should be considering?

Cheers,

--
Mark Nottingham   https://www.mnot.net/

Received on Wednesday, 24 August 2016 04:26:56 UTC