Resent-Date: Wed, 24 Aug 2016 04:27:11 +0000
Resent-Message-Id: <E1bcPmR-0003Zb-SF@frink.w3.org>
From: Mark Nottingham <mnot@mnot.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <F638033C-C1E0-447D-915E-A0B947629EA7@mnot.net>
Date: Wed, 24 Aug 2016 14:26:31 +1000
To: HTTP Working Group <ietf-http-wg@w3.org>
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Received-SPF: pass client-ip=216.86.168.182; envelope-from=mnot@mnot.net;
 helo=mxout-07.mxes.net
Subject: Server Push and Content Negotiation
Archived-At: <http://www.w3.org/mid/F638033C-C1E0-447D-915E-A0B947629EA7@mnot.net>
Resent-From: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list

The interaction of Content Negotiation and Server Push isn't really =
specified. Depending on how it's implemented, it could be quite tricky, =
because it seemingly requires the server to guess what the client would =
have sent, in order to negotiate upon it.

However, it becomes much simpler if we assume that the client SHOULD NOT =
check a `PUSH_PROMISE` request's headers to see whether or not it would =
have sent that request.

This means, for example, that if you `PUSH_PROMISE` the "wrong" =
`User-Agent`, `Accept-Encoding`, `User-Agent` or even `Cookie` header =
field, the client SHOULD still use the pushed response; all they're =
looking for is a matching request method and URL.

However, this does imply a few things:

* The pushed request and response MUST still "agree"; i.e., if you're =
using gzip encoding, `Accept-Encoding` and `Content-Encoding` should be =
pushed with appropriate values.
* The pushed response MUST have an appropriate `Vary` header field, if =
it is cacheable. This is so that the cache operates properly.

Additionally, the server needs to know what the base capabilities and =
preferences of the client are, to allow it to select the appropriate =
responses to push. To aid this, servers SHOULD create a PUSH_PROMISE's =
request by copying the values of the request header fields mentioned in =
the `Vary` response header field from the request that is identified by =
the `PUSH_PROMISE` frame's Stream ID.

So, for example, if the first request for a page had the following =
headers:

~~~
:method: GET
:scheme: https
:authority: www.example.com
:path: /
User-Agent: FooAgent/1.0
Accept-Encoding: gzip, br
Accept-Language: en, fr
Accept: text/html,s application/example, image/*
Cookie: abc=3D123
~~~

and the server wishes to push these response headers for `/style.css`:

~~~
:status: 200
Content-Type: text/css
Cache-Control: max-age=3D3600
Content-Encoding: gzip
Vary: Accept-Encoding
~~~

then it should use these headers for the `PUSH_PROMISE`:

~~~
:method: GET
:scheme: https
:authority: www.example.com
:path: /style.css
Accept-Encoding: gzip, br
~~~

This approach has its limits. For example, use of Client Hints might not =
be practical with server push (since in some circumstances, hints might =
change between the base page request and the request for what's been =
pushed).

I'd be tempted to go even further and say that PUSH_PROMISE headers =
SHOULD NOT contain `DNT`, `User-Agent`, `Cookie` or similar headers =
UNLESS they were specified in Vary.

What do people think -- is this worth specifying? How are =
implementations currently doing this?=20


--
Mark Nottingham   https://www.mnot.net/