On Mon, May 8, 2017 at 8:17 AM, Anne van Kesteren <[email protected]> wrote:
> >> 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). My mental model is inverted. A connection would be come ineligible for anonymous requests only when some kind of connection based auth was done to it (e.g. client certs, or ntlm). The presumption is that this does not happen often. In its absence there is only one kind of connection and it can carry anonymous and non anonymous requests. When some kind of connection based auth is triggered there are 2 classes of requests that have to deal with this a] a single request in flight (this is single because this is an h1-only-no-pipeline issue) b] other requests routed to the same host but not yet written out I suggest that if [a] is an anonymous request it needs to fail because [a] triggered the authentication. We can retry it on a clean connection, but because it itself is the trigger I don't see why that would make any progress. Maybe I'm misundertanding ekr here. members of [b] that are anonymous simply need to be late-bound to a different connection. They haven't been tried yet and aren't failed (perhaps that was part of the confusion?) _______________________________________________ dev-tech-network mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-network
