On Mon, May 8, 2017 at 5:17 AM, Anne van Kesteren <[email protected]> wrote:
> On Mon, May 8, 2017 at 1:52 PM, Eric Rescorla <[email protected]> wrote: > > On Mon, May 8, 2017 at 12:36 AM, Anne van Kesteren <[email protected]> > wrote: > >> How is that sufficient? How does Servo derive an implementation strategy > >> from that that's not different from that of other browsers in ways that > can > >> be observed by web sites? > > > > Way is this an imperative? I should think the requirement was merely > that it > > not break Web sites. > > And if that requirement is to remain true, we should document what > sites can come to depend upon. Sure, but that's a much weaker invariant than cannot be observed. > 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? > >> When a connection is anonymous-request-tainted and the server tries to > >> authenticate the connection, the client fails that process. This would > be a > >> potentially breaking change. > > > > I know that this is what McManus was suggesting, but if you mean that > fail > > causes the fetch to fail, that seems unnecessary. We could just simulate > > network error and retry on a different, non-tainted, connection I should > > think. > > 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. -Ekr _______________________________________________ dev-tech-network mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-network
