On Sun, May 7, 2017 at 3:31 PM, Patrick McManus <[email protected]> wrote:
> > On Sun, May 7, 2017 at 6:13 PM, Eric Rescorla <[email protected]> wrote: > >> >> So, what happens if from the client's perspective we have N, A, HR. At >> this point we >> need to re-issue N on a new connection so it doesn't contaminate A. We >> may actually >> need to tear down the connection and start two new ones, one with N and >> one with >> A. >> > > req N -> > <- resp (200) N > :: N is done and gone - in caches and spread far and wide :: > req A -> > <- HR > close conn and fail A I suppose > > or are you thinking of some scenario where N and A are both outstanding > with no replies? We don't have such a scenario right now (pipelines are > dead, and you can't do this in h2, how else would it happen?), > I was thinking of pipelining, but why would you fail A, rather than treating it as connection termination and restarting? -Ekr but if we did I would agree you would need to treat it as a reset and > replay them on different conns until you figured out what the HR applied > to. So whatever the h2 extension is that makes something like this happen > should take that into account - but we've gotten a bit afield from the > original question, > > >> >> That said, I'm also worried that there are misguided servers which bind >>>> HTTP-level authentication >>>> to the TLS connection. Those servers are going to have a bad day if we >>>> coalesce... Do we know >>>> that there aren't any? >>>> >>>> >>> 'any' is not a standard the web can ever meet :). You're concerned that >>> cookies on transaction 1 will be implicitly applied to transaction 2 even >>> though 2 doesn't have cookies? That would be a pretty big bug I think we >>> would have already seen - but that's basically what the change would boil >>> down to. >>> >> >> Not just cookies. Say, for instance, usernames and passwords. Maybe it >> doesn't happen. >> > > I trolling just a tad with the cookie line - cause its the 99.9% use case > here. If we had reason to think that traditional auth was broken I guess we > could design around that - but I haven't seen a case of that. > > > _______________________________________________ dev-tech-network mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-network
