Re: Mixed schemes

they don't coalesce on h1, but they do coalesce on h2. The distinction
isn't about cleartext - h2 has coalescing rules :)

On Mon, Nov 21, 2016 at 10:28 PM, Erik Nygren <erik+ietf@nygren.org> wrote:

> Forbidding cross-scheme coalescing by default addresses my concern.  I'm
> happy for us to explore opt-in approaches in the future (eg, a SETTING).
>
> As for #1/#2, what do browsers typically do today for clear-text HTTP
> pconns that resolve to the same IP but have different origins / host
> headers? If they don't normally coalesce on cleartext, I think forbidding
> coalescing is fine here as well as the default.
>
> On Mon, Nov 21, 2016 at 5:04 PM, Patrick McManus <mcmanus@ducksong.com>
> wrote:
>
>> I really think we can do #1, but I won't object to #2.
>>
>> -P
>>
>>
>> On Sun, Nov 20, 2016 at 10:14 PM, Mark Nottingham <mnot@mnot.net> wrote:
>>
>>> Personally -- SGTM (including #2).
>>>
>>>
>>> > On 21 Nov. 2016, at 1:29 pm, Martin Thomson <martin.thomson@gmail.com>
>>> wrote:
>>> >
>>> > Patrick (perhaps indirectly) suggested that we can harness a Firefox
>>> bug here:
>>> >
>>> >  https://github.com/httpwg/http-extensions/pull/270
>>> >
>>> > That is, rather than mention that coalescing between https and http
>>> > might happen, forbid it instead.
>>> >
>>> > I'm fairly sure that this will address the concerns Erik had.  Maybe
>>> > too effectively; objections like this would be good to hear.
>>> >
>>> > I didn't add any text here about coalescing two http:// origins.  I
>>> > don't want to close this issue until we resolve that too.  Should we:
>>> >
>>> > 1. allow coalescing of two http:// origins by default
>>> > 2. forbid coalescing of two http:// origins without an explicit signal
>>> >
>>> > My preference is for option 2.
>>> >
>>> > Let's be perfectly clear, there's no inherent protocol reason why we
>>> > can't coalesce.  But this stems from an (over)abundance of caution.
>>> > We can develop explicit opt-in signals regarding coalescing if it came
>>> > to that ... #include <ORIGIN frame discussions>.
>>> >
>>>
>>> --
>>> Mark Nottingham   https://www.mnot.net/
>>>
>>>
>>>
>>
>