Re: issue 23

No. Absolutely not.

You are making an assumption that user agents will be receiving
the TSR on a regular basis.  In almost all cases, that will not be true.
The TSR has no role in the consent dialog. The TSR isn't needed to protect
users.  Normal users don't need any response for tracking protection.
They just send DNT:1 and deal with consent dialogs when needed.

What the TSR supplies is information for regulators and for those who,
for whatever reason, have tracking visualization going on in an active state.
In other words, folks using a special extension that actively interferes
in the normal day-to-day interaction with web sites for the express
purpose of either reporting on site tracking, creating a whitelist, or
non-blacklist filtering of third-party requests.

TSR requests are unlikely to be a common case even if DNT is 100%
deployed and actively checked by every user. We have carefully designed
the protocol to enable caching of those responses for much longer
than a single session.

Server push was not designed to enhance caching!  What it does is reduce
latency for non-cached responses by anticipating some requests for which
a response is unlikely to be in the user agent cache.  For example,
sites that use generation-based identifiers can trigger a push when
the client requests a page without using a conditional GET matching
the current generation.  Also, server push enables user-specific
responses (notifications) when a user logs-into an authenticated site.

Server push would be a complete disaster if protocols were allowed
to require the sending of bits that the user agent does not need.
We'd rip it out of h2 if that ever becomes the case.

....Roy

> On Apr 1, 2017, at 1:30 AM, Mike O'Neill <michael.oneill@baycloud.com> wrote:
> 
> This is something I realised when thinking about issue 23.
> 
> The new version of HTTP , HTTP/2 (RFC7540) has a feature called "Server
> Push" https://tools.ietf.org/html/rfc7540#section-8.2
> 
> This lets servers pre-emptively send other resources when responding to a
> request.
> 
> "This can be  useful when the server knows the client will need to have
> those responses available in order to fully process the response to the
> original request".
> 
> Since the user agent may adjust behaviour based on the current Tracking
> Status Resource we should recommend that servers use Server Push.
> 
> The following text could be added at the end of 6.4.4 Caching:
> 
> To ensure that user agents always have the most recent Tracking Status
> Resource in their cache, servers SHOULD use the Server Push mechanism
> defined in [RFC7540] whenever a state-changing request may have changed it.
> 
> Send a PUSH_PROMISE frame with a minimal request for the TSR, aligning with
> the request generated in §3.4.2 Process response for Origin Policy.
> Begin delivering the response to the PUSH_PROMISE request.
> 
> 
>

Received on Saturday, 1 April 2017 19:04:51 UTC