Re: [whatwg/fetch] Define behavior in the presence of TLS Early Data (#888)

> This is something that I think browsers should be able to determine on their own. The spec can say "if the user agent sends the request in early data, ..." as necessary.

Yeah, in retrospect, I probably phrased it wrong. The spec shouldn't be prescribing when a browser will use early data. The spec should be prescribing when the browser must not use early data, allowing but not requiring it to be used in any other case.

* Fetch requests that were fired by scripts `destination == ""` MUST NOT use early data unless the script specifically enables it, in which case they MAY but are not require dot do so.
* Fetch requests with non-empty destination (that is, ones that were fired by forms, links, or page subresources) MAY use TLS Early Data as long as they are GET requests.

> The idea being that the browser retries?

Yeah, exactly.

> That might not be feasible for requests with streamed bodies. That would need some work.

My immediate instinct was that this shouldn't be a problem, since the size of an early data payload should always be a bit smaller than [TCP MSS](https://en.wikipedia.org/wiki/Maximum_segment_size) anyway (otherwise, it wouldn't be zero-round-trip, because it would have to go through a TCP ACK cycle). But that's not actually helpful. The server isn't guaranteed to fire its 425 Too Early response immediately upon receiving the early data payload (if it was able to, it would have ["ignored the extension and and returned a regular 1RTT response"](https://tools.ietf.org/html/rfc8446#section-4.2.10) instead). A browser that sends early data needs to be prepared to recreate the entire request.

So the best answer is probably not using TLS Early Data if the request has a streaming body. Having one little round trip off of a large data transfer doesn't seem worth it anyway.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/888#issuecomment-479645244