On Sun, May 7, 2017 at 6:13 PM, Eric Rescorla 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
> need to tear down the connection and start two new ones, one with N and
> one with
req N ->
<- resp (200) N
:: N is done and gone - in caches and spread far and wide ::
req A ->
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?), 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.