- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 30 May 2017 17:04:23 +1000
- To: ietf-http-wg@w3.org
> 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