On Mon, May 8, 2017 at 12:36 AM, Anne van Kesteren <[email protected]> wrote:
> On Sunday, May 7, 2017 at 10:12:20 PM UTC+2, Patrick McManus wrote: > > an authenticated connection is the moral equivalent of having credentials > > on every request on that conn.. so its non-sensical to have an anonymous > > request on a authenticated connection. (so yes, if its anonymous it would > > need to be on a non authenticated connection.. I'm not sure fetch needs > to > > say that - its sufficient to define an anonymous request as lacking > > credentials I would think) > > 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. > > but that doesn't mean we need to ban the mingling of authenticated and > non > > authenticated on the same connection when we aren't using connection > based > > auth (which is approximately all the time outside some enterprise cases). > > Sure, then the question becomes what the new policy would be. > > > Let me try a description of the new model to see if we're on the same > page. The connection pool which holds all connections is global for the > user agent. A connection is keyed in part on a set of (domain, port) > tuples, one of which needs to match. > Nit: scheme/host/port A connection can become authenticated. This can happen at any point for the > duration of the connection, except when the connection is > anonymous-request-tainted. > > A connection can become anonymous-request-tainted when you send an > anonymous request over it. If a connection is authenticated the client > won't send an anonymous request over it and instead open a new connection. > > 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. So basically, authenticated and anonymous-request-tainted would be mutually > exclusive and also part of the connection key. > > (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. -Ekr _______________________________________________ > dev-tech-network mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-tech-network > _______________________________________________ dev-tech-network mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-network
