Subject: [httpwg/http-extensions] ORIGIN and Server Push (#355)

From: HTTP issue updates <[email-masked]>
Date: Mon, 29 May 2017 23:52:05 -0700

#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)
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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/355