New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 604748 link

Starred by 4 users
Status: Archived
Owner: ----
Closed: Sep 2017
Cc:
█ xunji...@chromium.org
b...@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

SDCH should treat server-pushed data as if it was cached

Project Member Reported by rdsmith@chromium.org, Apr 19 2016 
The SDCH protocol requires that if a request is sent with Avail-Dictionary, the response must either be SDCH encoded or include an X-SDCH-Encode: 0 header.  This won't work for server-pushed responses, which are done without seeing the request that the push will (eventually) be matched with in the client, and hence cannot be SDCH encoded (though as a server-side workaround, they can unilaterally include X-SDCH-Encode: 0).  

This problem can be fixed in several ways:
* Pushed responses could be put in the network cache.
* The mechanism that matches pushed responses to requests could be made SDCH aware and add the X-SDCH-Encode: 0 header to the response.
* Some mechanism to determine if a response was the result of a server push could be included and the SDCH filter could add a check to that to the cache check.  (SDCH includes special code to bypass this check in the case of cached responses, which were not served to a network request that includes Avail-Dictionary.)

At the moment, the third option is considered the best.

Comment 1 by mmenke@chromium.org, Apr 21 2016 

SDCH-encoding pushed responses just seems like a bad idea.  The server has no idea when we're planning on evicting an SDCH dictionary, even if we advertised it seconds ago.  I'd say we should explicitly disallow SDCH in pushed responses, and return errors on then, to avoid any potential races.

If we're committed to improving SDCH support, I'd be fine with something that had clear, documented, specified behavior here, but I think there's other SDCH work that's higher priority.

Comment 2 by rdsmith@chromium.org, Apr 21 2016 

I wasn't suggesting SDCH encoding pushed responses; I was suggesting doing something such that SDCH didn't reject non-SDCH encoded pushed responses, which (unless we kill SDCH) I think is worth doing.  Sorry if that wasn't clear.

Comment 3 by aaronlink@google.com, Apr 21 2016 

I agree that SDCH-encoding pushed response is weird. The problem is that Chrome currently does the wrong thing precisely when a server does *not* SDCH-encode a pushed response (but Chrome expected it to).

Comment 4 by mmenke@chromium.org, Jun 13 2016 

I wonder if we can get rid of the expectation that if we advertise SDCH, the server will use it, now that we only support SDCH over HTTPS.  Seems like now, you need an SSL MitM to break SDCH, which makes it less of a problem.

Comment 5 by rdsmith@chromium.org, Jun 14 2016 

I didn't see any CL going by restricting it to HTTPS, and I don't see that in the code.  Are you sure we're restricted to HTTPS?

Comment 6 by xunji...@chromium.org, Sep 13 2017

Status: Archived (was: Untriaged)
SDCH has been disabled in Chrome since M59. For more details please see
Issue 690070 and blink-dev@ thread linked there.

The code is removed in  Issue 762686 .

Archiving this bug.
►

Sign in to add a comment