HTTP extension mechanisms

[LPardue]

The HTTP/QUIC mapping document is missing consideration for HTTP/2 extension mechanisms. This is part of the charter text:

This mapping will accommodate the extension mechanisms defined in the HTTP/2 specification.

RFC 7540 (https://tools.ietf.org/html/rfc7540#section-5.5) defines three extension mechanisms, lets order these as:

1. New frame types
2. New error codes
3. New settings

I can see how 1 and 2 might work out, following Mike's example of augmenting existing definitions and allowing for things that exist in the HTTP/2 and HTTP/QUIC spaces to be managed somewhat independently. A concrete use case I have is the ALTSVC frame (especially when used on stream 0), so I'm happy to contribute towards this issue with some guidance.

3 has some problems related to proposed SETTINGS changes.

Finally, extensions that could change of semantics are a bit problematic (does it change the HTTP or the QUIC semantic, if that either of those is even possible). Additionally, the negotiation of these is trickier given the additional negotation concerns of QUIC (0-RTT etc).

[MikeBishop]

I don't read the charter text as requiring that every individual extension work unmodified in HTTP/QUIC, simply that equivalent extension mechanisms exist. If people feel differently, we may need broader discussion to reach consensus on that part first.

I suspect 3 will work out the same way that 1 already works -- modify the registry to have additional columns saying whether the setting is supported in HTTP/2 or HTTP/QUIC, and if so, the specification that describes how it works. That will take some text.

For 2, an extension can define new error codes, but we're currently making no guarantees that the same error code can be applied in both places. We'll have to think about how much consistency we want. HTTP/QUIC will probably accommodate semantic-changing extensions the same way HTTP/2 did -- by stating that peers can implement whatever modifications they want via explicit agreement.

[LPardue]

I agree with your assessment of the charter text. It's an accommodation of H2 extensions, not a guarantee of like-for-like. I confused myself with some of the changes to the treatment of stream IDS. Rereading the HTTP/QUIC spec, I can see that stream 3 is still reserved. So an ALTSVC frame for "H2 stream 0" would be sent on stream 3. Presumably an ALTSVC frame for "H2 stream > 0" simply maps to the appropriate response control stream. Here's a can of worms idea, which is likely a non-starter but I'll throw it out there. Would the QUIC core transport itself support extension frames? If it did, how about the creation of QUIC extension frames to elide H2 extension frames? For example, a new ALTSVC frame for QUIC. This could allow other mappings to indicate other services (pretend that it's not called HTTP Alternative Services :) ).

[MikeBishop]

QUIC frames, unlike HTTP frames, do not include a length field – you have to understand every frame you see, or it's a fatal error. So, not as easily. We could define an “OTHER” frame or something like that, which includes a length. But there's no obvious advantage to doing Alt-Svc in the transport layer. For connection migration, the ability to advertise that a session may be seamlessly continued at another endpoint (in either direction) might be interesting, but we're not there yet.

…

Sent from my Windows 10 phone From: Lucas Pardue<mailto:notifications@github.com> Sent: Friday, January 27, 2017 7:39 PM To: quicwg/base-drafts<mailto:base-drafts@noreply.github.com> Cc: Mike Bishop<mailto:Michael.Bishop@microsoft.com>; Comment<mailto:comment@noreply.github.com> Subject: Re: [quicwg/base-drafts] HTTP extension mechanisms (#242) I agree with your assessment of the charter text. It's an accommodation of H2 extensions, not a guarantee of like-for-like. I confused myself with some of the changes to the treatment of stream IDS. Rereading the HTTP/QUIC spec, I can see that stream 3 is still reserved. So an ALTSVC frame for "H2 stream 0" would be sent on stream 3. Presumably an ALTSVC frame for "H2 stream > 0" simply maps to the appropriate response control stream. Here's a can of worms idea, which is likely a non-starter but I'll throw it out there. Would the QUIC core transport itself support extension frames? If it did, how about the creation of QUIC extension frames to elide H2 extension frames? For example, a new ALTSVC frame for QUIC. This could allow other mappings to indicate other services (pretend that it's not called HTTP Alternative Services :) ). On 27 Jan 2017 01:40, "Mike Bishop" <notifications@github.com> wrote: I don't read the charter text as requiring that every individual extension work unmodified in HTTP/QUIC, simply that equivalent extension mechanisms exist. If people feel differently, we may need broader discussion to reach consensus on that part first. I suspect 3 will work out the same way that 1 already works -- modify the registry to have additional columns saying whether the setting is supported in HTTP/2 or HTTP/QUIC, and if so, the specification that describes how it works. That will take some text. For 2, an extension can define new error codes, but we're currently making no guarantees that the same error code can be applied in both places. We'll have to think about how much consistency we want. HTTP/QUIC will probably accommodate semantic-changing extensions the same way HTTP/2 did -- by stating that peers can implement whatever modifications they want via explicit agreement. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#242 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGRFtfyWaL1jLNhHIS-UncHbKEK3gHO8ks5rWUsFgaJpZM4LuXmB> . — You are receiving this because you commented. Reply to this email directly, view it on GitHub<#242 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AEE2hY35n30MNFZzq21NV5ATlZu-Q5tWks5rWo5QgaJpZM4LuXmB>.

[LPardue]

Thanks for the illumination. I'll put a pin in my ALTSVC thoughts for now, more important things to focus on.

It seems like there is some text to add around HTTP extensions, should we keep this issue open to track that?

[LPardue]

(Edit: fix broken hyperlinks and wrong RFC ref)

I've reread the section "Existing Frame Types" and have been left a bit muddled.

The intent seems to be to redefine the the Frame Type Registry table defined in RFC7540. However, the IANA managed Frame Type Registry includes the additional ALTSVC frame, that was registered in RFC7838.

Although Alt-Svc is a HTTP/2 extension, it seems a bit unfair to leave it out at this stage. Doing so would mean we need an RFC7838 "Update" doc in order to support its use with QUIC. Perhaps that was the intent?

[MikeBishop]

Yeah, I've debated whether to include that here. It's a dead simple mapping -- 0=>3, everything else the same. But updating 7838 in the HTTP/QUIC spec feels a bit weird, too. Maybe I should just spin up a separate I-D for ALTSVC frames.

[martinthomson]

I think that it's past time to acknowledge that this isn't anything like h2. We should do two things:

1. port h2 extensions that matter (like ALTSVC)

2. provide advice for porting h2 extensions

Yeah, that sucks, but we can't provide the same guarantees for extensions, so we can't guarantee that extensions will be be the same.

[MikeBishop]

That's more or less the direction I'm heading in #363, though I've still got the joint IANA frame type / setting registry. Have a section that talks about where we're similar and where we're different. There's already advice on porting extensions, though it could probably be expanded.

Are you advocating we simply leave the HTTP/2 registry alone and start fresh?

[martinthomson]

That's what I'm advocating :) But I've been advocating that for a while.

[mnot]

+1 to starting fresh from me.

Is this really closed?

[MikeBishop]

Closed because there's text addressing it in -02. The "split registries" has a separate issue, which is not closed.