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

Issue 789599 link

Starred by 8 users
Status: Assigned
Owner:
vasilvv@chromium.org
Cc:
█ svaldez@chromium.org
davidben@chromium.org
rch@chromium.org
█ ianswett@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Feature



Sign in to add a comment

Implement 425 Too Early

Project Member Reported by vasilvv@chromium.org, Nov 29 2017 
https://tools.ietf.org/html/draft-ietf-httpbis-replay-02 describes an HTTP error code that allows the origin to reject a 0-RTT request and to instruct the browser to resend the request as 1-RTT.

We should implement this error code so that both QUIC and TLS 1.3 can use it.  The draft is in the working group last call, and I do not expect any substantial changes to the behavior.

The spec does not say what the user agent is supposed to do when the 425 is sent in response to a non-0-RTT response.  Firefox appears to have went with "only handle it if the server has accepted 0-RTT": https://bugzilla.mozilla.org/show_bug.cgi?id=1406908 -- this seems reasonable.

I have some implementation thoughts I'll write down here later.

Comment 1 by davidben@chromium.org, Nov 29 2017 

I think the most natural place to implement this is in HttpNetworkTransaction, which already has a lot of other retry logic. That's where we're anticipating putting the TLS 1.3 0-RTT retry. I think Steven already has some in-progress code for this, actually. Adding 425 in there should be fairly straightforward I expect?

Though the QUIC code is probably going to need some work since you all retry at a different layer.

Comment 2 by mmenke@chromium.org, Nov 29 2017 

I don't think HttpNetworkTransaction currently knows when we used a 0-RTT method to send a request?

Comment 3 by mmenke@chromium.org, Nov 29 2017 

I agree that's the right layer, just think there may be a little more involved here than retrying on all 425s.  We could retry on any 425, though then we might break the 1 in 10 million requests that currently receive a 425 response in the wild.

Comment 4 by davidben@chromium.org, Nov 29 2017 

Right, on the QUIC side a lot more work is needed because all of their 0-RTT logic needs to get lifted up. On the TLS 1.3 side, we're putting 0-RTT in there to begin with, because that's the only place it can go.

Comment 5 by rch@google.com, Nov 30 2017 

Should we add a method to HttpStream to expose if the request was sent as early data (over 0-RTT)?

Comment 6 by davidben@chromium.org, Nov 30 2017 

rch: It's late over in CAM, but let's sync up sometime. Steven and I were going to write something up for you, but we never ended up doing that. :-) The changes are quite a bit more involved than that.

Comment 7 by rch@chromium.org, Nov 30 2017 

Heh. Makes sense. Drop something on my calendar?

Comment 8 by efoo@chromium.org, Jul 6

Components: Internals>Network

Comment 9 by efoo@chromium.org, Jul 6

Components: -Internals>Network>HTTP
►

Sign in to add a comment