From:  Anne van Kesteren <>
Date:  08 May 2017 20:55:22 Hong Kong Time

Re: Credentials and connection pools


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?