On Mon, May 8, 2017 at 2:33 PM, Eric Rescorla <[email protected]> wrote: > On Mon, May 8, 2017 at 5:17 AM, Anne van Kesteren <[email protected]> wrote: >> And likely will depend on given how >> HTTP/2 push works. Part of the reason I'm raising this is because >> folks are running into issues with the current model. If we change the >> model but don't make sure that all browsers adopt it, developers will >> still end up running into issues. > > Hmm... Can you describe more about what issues developers of Web sites > are running into?
One thing that is reported to happen is that the user navigates to /, then that pushes /x and /y as well. The browser then requests /x without credentials and doesn't end up using the pushed resource. But you're probably right that this in essence doesn't depend on the connection as pushes are request/response bound. There's also a more general concern that's often aired about using multiple connections to begin with in an HTTP/2 world, but I'm not really sure how to qualify that concern. It seems to me that as long as HTTP/2 goes over TCP, having multiple connections might actually be beneficial at times. Nevertheless, connections can be observed and recommending a model for them doesn't seem like a bad idea to me. Having some kind of contract as to how they work helps folks who define things like preconnect. Since if that doesn't know about the full key used for establishing a connection, you can end up just opening connections that go without use and neither party really knows why. >> 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. Ouch. Filed https://github.com/whatwg/fetch/issues/538. -- https://annevankesteren.nl/ _______________________________________________ dev-tech-network mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-network
