W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2017

Re: Issue: ORIGIN and Server Push [#355]

From: Mark Nottingham <mnot@mnot.net>
Date: Tue, 30 May 2017 17:04:23 +1000
To: ietf-http-wg@w3.org
Message-Id: <71105138-1BA0-48EA-95B6-4C8E647AC74F@mnot.net>

> On 30 May 2017, at 4:54 pm, Mark Nottingham <mnot@mnot.net> wrote:
> 
> I created a new issue:
>  https://github.com/httpwg/http-extensions/issues/355
> 
> #349 made me realise that, from the server's perspective, they don't have hard information about whether the client supports ORIGIN at the time they send the ORIGIN frame.
> 
> While they might gather this based upon the requests that the client subsequently sends, this isn't information you'd want to rely upon.
> 
> This is especially relevant to Server Push. Right now, ORIGIN is defined to affect what the client is able to push, but (as above), the server doesn't have a firm idea about the origins that are actually valid to use on the connection at any given time.
> 
> A number of potential solutions:
> 
> 1. The server just speculatively pushes and figures it out based upon the responses (i.e. no change)

Oh, and this could involve defining a specific stream error code for this situation. Right now, 7540 just specifies using PROTOCOL_ERROR.


> 2. We create an explicit signal from the client to the server (e.g., "I will process ORIGIN", probably a SETTING, or "I have processed ORIGIN", probably a frame)
> 
> 3. ORIGIN doesn't constrain Server Push
> 
> Note that 1 is not optimal (wasted bytes), and 3 might collide badly with future uses of ORIGIN.
> 
> 
> --
> Mark Nottingham   https://www.mnot.net/
> 
> 

--
Mark Nottingham   https://www.mnot.net/
Received on Tuesday, 30 May 2017 07:04:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:15:03 UTC