McManus and I talked offline, and I think we agree: 1. It is not currently possible to have two outstanding on the wire requests with different auth semantics:
- People don't do H1 pipelining so the outstanding requests can be late-bound to the right connection. - H2 prohibits renegotiation (though we might in future have to worry about TLS 1.3 post-handshake auth or Nick Sullivan's proposed extensions). 2. With both H1 and H2, you *do* need to store unacknowledged requests so you can replay them in the face of a variety of transport issues. -Ekr On Mon, May 8, 2017 at 7:44 AM, Eric Rescorla <[email protected]> wrote: > > > On Mon, May 8, 2017 at 6:57 AM, Patrick McManus <[email protected]> > wrote: > >> >> On Mon, May 8, 2017 at 8:33 AM, Eric Rescorla <[email protected]> wrote: >> >>> We cannot always retry. E.g., with fetch() using streams the user >>> > agent cannot reproduce the body (by design, to use less memory; >>> > therefore also fails on most redirects and HTTP authentication). >>> > >>> >>> Hmm.... This seems like a separate topic, but as you describe it, this >>> has >>> the >>> potential to interact very badly with TLS 1.3 0-RTT (and QUIC too) which >>> both >>> depend on the assumption that 0-RTT data can fail and have to be replayed >>> semantically. >> >> >> >> I don't think this is a fetch() level problem - those are both basically >> transport issues with unacknowledged data and the transport is always going >> to need a copy of that information to accommodate packet loss.. 0-rtt fail >> is really just a twist on loss from a replay pov. Our definition of >> transport has moved up a bit in the stack from socket buffers, but it >> hasn't made it to fetch() yet :) >> > > Right. I think in this case it's the semantic layer of HTTP (i.e., the one > that spans h1/h2/h2s/h2q) > > -Ekr > > > _______________________________________________ dev-tech-network mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-network
