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

Re: Credentials and connection pools


On Mon, May 8, 2017 at 1:52 PM, Eric Rescorla  wrote:
> On Mon, May 8, 2017 at 12:36 AM, Anne van Kesteren  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. 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.

> Nit: scheme/host/port

Oops, bit optimistic there.

>> 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).

>> (With such a setup, there's probably not much advantage to TLS extensions
>> surrounding connection authentication. (I was thinking that if the server
>> could assert it would never use it, we could only coalesce then (and fail
>> later on if the server lied). Alternatively the client could assert it would
>> never need it.)
> This seems like something that would have an incredibly long deployment
> curve.

Yeah, I suspected as much. Happy that we have alternatives to consider.