On Mon, May 8, 2017 at 2:39 PM, Patrick McManus <[email protected]> wrote: > On Mon, May 8, 2017 at 8:17 AM, Anne van Kesteren <[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). > > 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.
Yes, that's exactly what I wrote down. I still don't understand why you keep saying it's different. > 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?) Okay, so instead of failing the connection you fail just the request. Are you also saying that only HTTP/1 can have authenticated connections at this point? -- https://annevankesteren.nl/ _______________________________________________ dev-tech-network mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-network
