On Mon, May 8, 2017 at 2:39 PM, Patrick McManus wrote:
> On Mon, May 8, 2017 at 8:17 AM, Anne van Kesteren 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?