Re: [Masque] Dropping HTTP/1.x requirement for CONNECT-UDP

[Ian Swett <[e-mail]>]

I agree that I think we need all 3 versions and didn't intend my message to
indicate that an h2 version shouldn't be created, but rather that I expect
an h1 may be used quite widely.

In terms of MITMs, David Schinazi pointed out that MITMs which block QUIC
may also block CONNECT-UDP, and time will tell on that.



On Thu, Mar 25, 2021 at 2:14 PM Alex Chernyakhovsky <[e-mail]>
wrote:

> Hi Spencer,
>
> Can you please double-check if if all the instances of h1, h2, h3 you
> wrote are correct? I'm having trouble parsing your message.
>
> I also want to add that I don't think restricting ourselves to h1 if h3
> fails makes much sense. h2 has benefits, and IMO we should use them over h1
> if h3 is unavailable.
>
> Sincerely,
> -Alex
>
>
> On Thu, Mar 25, 2021 at 10:06 AM Spencer Dawkins at IETF <
> [e-mail]> wrote:
>
>> I'm actually following up on something Ian said earlier ...
>>
>> On Thu, Mar 25, 2021 at 8:42 AM Mirja Kuehlewind <mirja.kuehlewind=
>> [e-mail]> wrote:
>>
>>> I agree. I thought that the mapping is actually relatively straight
>>> forward though. With H2 you can have one CONNECT per stream (and no
>>> datagram support). For H1 you can only have one CONNECT per connection and
>>> you would open multiple TCP/HTTP connections for each forwarding request
>>> separately.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *From: *Masque <[e-mail]> on behalf of Alex
>>> Chernyakhovsky <achernya=[e-mail]>
>>> *Date: *Wednesday, 24. March 2021 at 02:11
>>> *To: *Ian Swett <[e-mail]>
>>> *Cc: *David Schinazi <[e-mail]>, Mark Nottingham <
>>> [e-mail]>, Roy Fielding <[e-mail]>, Tommy Pauly <
>>> [e-mail]>, MASQUE <[e-mail]>
>>> *Subject: *Re: [Masque] Dropping HTTP/1.x requirement for CONNECT-UDP
>>>
>>>
>>>
>>> I don't think aligning h1 and h2 makes sense. h2 is closer to h3 than it
>>> is to h1.
>>>
>>>
>>>
>>> Sincerely,
>>>
>>> -Alex
>>>
>>>
>>>
>>> On Tue, Mar 23, 2021 at 7:25 PM Ian Swett <[e-mail]> wrote:
>>>
>>> IMO it makes sense to align the h1 and h2 designs, since they're both
>>> fallbacks we'd rather not use.  If h1+h2 lands after h3 in a different doc,
>>> I don't see a problem with that, but I'm also fine with them being in a
>>> single document.
>>>
>>>
>>>
>>> In a surprising number of cases where h3 is blocked, h2 is blocked as
>>> well(ie: Corp MITMs) and users will end up on h1.  Additionally, h1 is
>>> still widely used behind load balancers/proxies.  As such, by the time this
>>> becomes RFC, I wouldn't be surprised if there's more usage of it over h1
>>> than h2.
>>>
>>> I know there's a conceptual reason for having mappings for h3, h2, and
>> h1, but if Ian's experience here is typical, how bad would it be if the
>> recommendation was to fall back from h3 to h1?
>>
>> If h2 doesn't work on a path now, do we want to encourage those operators
>> to allow h2 and continue to block h3, rather than encouraging people to
>> allow h3?
>>
>> Best,
>>
>> Spencer
>>
>>>
>>>
>>> I don't think the CONNECT-UDP design for h2 and h3 needs to share
>>> framing, given h3 has datagrams and doesn't need frames transmitted on
>>> streams to transmit UDP?
>>>
>>>
>>>
>>> On Tue, Mar 23, 2021 at 6:42 PM David Schinazi <[e-mail]>
>>> wrote:
>>>
>>> Or we could have one document now that describes CONNECT-UDP over h2 and
>>> h3, and a separate document that defines CONNECT-UDP over h1 later?
>>>
>>> I'm not saying CONNECT-UDP should never support HTTP/1.1, I'm just
>>> saying that maybe we don't need to design that yet.
>>>
>>>
>>>
>>> Thoughts?
>>>
>>> David
>>>
>>>
>>>
>>> On Mon, Mar 22, 2021 at 7:57 PM Tommy Pauly <[e-mail]> wrote:
>>>
>>> Yes, that’s what I recall as well.
>>>
>>> David, can we still go down the path of using frames in HTTP/3 and
>>> HTTP/2, while letting CONNECT-UDP have a more degenerate case for HTTP/1.1?
>>>
>>> Tommy
>>>
>>> > On Mar 22, 2021, at 7:53 PM, Mark Nottingham <[e-mail]> wrote:
>>> >
>>> > My recollection is that this was discussed at length during
>>> chartering, and the resolution was that we'd make it version-independent,
>>> like other methods. If you want to re-visit that, I think we'd need to ask
>>> the whole HTTP WG, not just a couple of people.
>>> >
>>> > Cheers,
>>> >
>>> >
>>> >> On 23 Mar 2021, at 9:39 am, Tommy Pauly <[e-mail]> wrote:
>>> >>
>>> >> While I understand the desire for this, I’m concerned about making a
>>> method that only works with some versions.
>>> >>
>>> >> From
>>> https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#methods
>>> <https://protect2.fireeye.com/v1/url?k=57aa9374-0831aa71-57aad3ef-86d2114eab2f-8a67a28437e1dc6d&q=1&e=cd2d81ff-d165-41ed-836c-128d76921781&u=https%3A%2F%2Fhttpwg.org%2Fhttp-core%2Fdraft-ietf-httpbis-semantics-latest.html%23methods>
>>> :
>>> >>
>>> >> HTTP defines a number of generic extension points that can be used to
>>> introduce capabilities to the protocol without introducing a new version,
>>> including methods, status codes, field names, and further extensibility
>>> points within defined fields, such as authentication schemes and
>>> cache-directives (see Cache-Control extensions in Section 5.2.3 of
>>> [Caching]). Because the semantics of HTTP are not versioned, these
>>> extension points are persistent; the version of the protocol in use does
>>> not affect their semantics.
>>> >>
>>> >> Version-independent extensions are discouraged from depending on or
>>> interacting with the specific version of the protocol in use. When this is
>>> unavoidable, careful consideration needs to be given to how the extension
>>> can interoperate across versions.
>>> >>
>>> >> I’d like to hear the opinions of Mark and Roy on this.
>>> >>
>>> >> Tommy
>>> >>
>>> >>> On Mar 22, 2021, at 3:21 PM, Alex Chernyakhovsky <achernya=
>>> [e-mail]> wrote:
>>> >>>
>>> >>> I think this makes a lot of sense. As it stands today, anyone
>>> wishing to add UDP support would have to make changes to their
>>> client/server anyway -- I feel like the complexity we'd take on by
>>> continuing to support HTTP/1.1 and older isn't beneficial since we wouldn't
>>> be able to interoperate with existing implementations with the new
>>> features. Requiring HTTP/2 or newer lets us rely on a lot of nice things
>>> that have been added (like multiplexing) and not have to re-invent them in
>>> HTTP/1.1 just for UDP.
>>> >>>
>>> >>> Sincerely,
>>> >>> -Alex
>>> >>>
>>> >>> On Thu, Mar 18, 2021 at 6:12 PM David Schinazi <
>>> [e-mail]> wrote:
>>> >>> Hi MASQUE enthusiasts,
>>> >>>
>>> >>> The CONNECT-UDP draft currently states "The CONNECT-UDP method is
>>> defined for all versions of HTTP." While supporting HTTP/3 is our top
>>> priority, and supporting HTTP/2 is necessary because of networks that block
>>> UDP, I'm not sure supporting versions of HTTP before 2 is useful.
>>> Additionally, it constrains our design space as HTTP/1.1 does not have the
>>> HTTP framing layer that HTTP/2 and HTTP/3 have. I would like to drop
>>> support for HTTP/1.1, 1.0 and 0.9.
>>> >>>
>>> >>> Does anyone object to dropping the requirement to support versions
>>> of HTTP before 2?
>>> >>>
>>> >>> Thanks,
>>> >>> David
>>> >>> --
>>> >>> Masque mailing list
>>> >>> [e-mail]
>>> >>> https://www.ietf.org/mailman/listinfo/masque
>>> >>> --
>>> >>> Masque mailing list
>>> >>> [e-mail]
>>> >>> https://www.ietf.org/mailman/listinfo/masque
>>> >>
>>> >
>>> > --
>>> > Mark Nottingham   https://www.mnot.net/
>>> <https://protect2.fireeye.com/v1/url?k=0c525adb-53c963de-0c521a40-86d2114eab2f-69a3e42f0cf4ffba&q=1&e=cd2d81ff-d165-41ed-836c-128d76921781&u=https%3A%2F%2Fwww.mnot.net%2F>
>>> >
>>> > --
>>> > Masque mailing list
>>> > [e-mail]
>>> > https://www.ietf.org/mailman/listinfo/masque
>>>
>>> --
>>> Masque mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/masque
>>>
>>> --
>>> Masque mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/masque
>>>
>>