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? > 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. 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. 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.) _______________________________________________ dev-tech-network mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-network
