QPACK settings in HTTP

[MikeBishop]

On #1143, @martinthomson said:

if -http depends on -qcram, I think that we need to define configuration parameters in -qcram and explain how the settings are used to set these parameters in -http. Right now the drafts are tightly coupled.

He's probably correct, but there appear to be enough ripple effects that I'd prefer to handle this change separately.

[MikeBishop]

We can't really avoid them being tightly coupled -- at the very least, QPACK is defined for the payload of the HEADERS and PUSH_PROMISE frames. Those are used for HTTP concepts, so they can't very well be defined by the QPACK spec.

Another dependency that currently exists: HTTP has to reserve the unidirectional streams that QPACK needs. And that's probably okay, as there's an existing dependency we can't get rid of.

There is an intriguing (scary) possibility there, though.... If there were a stream header on unidirectional streams and new types could be added by extensions, QPACK could simply register the new stream types it wants. One less tight coupling, but one more extension point.

[martinthomson]

You see, I like that idea. QPACK defines its requirements in terms of streams and HPACK uses those. It's a nice directed dependency arrangement. The service it provides (uncompressed HEADERS -> compressed HEADERS) is provided, but only if hq provides some settings and some streams. We might want to avoid having to put a type header on bidirectional streams though; no sense in being arbitrarily flexible.

BTW, think of what the CERTIFICATE frame stuff might do with its own stream...

[MikeBishop]

The more I think about this, the more appealing it becomes, actually. Then the weird state machine from H2 with Server Push simply becomes one more type of extension-owned unidirectional stream, and if we wanted to pull Push out into an extension on its own, we could. Let me sketch this out, and we'll see how crazy it winds up being.

[LPardue]

In a nutshell are you suggesting: bidirectional streams are used to provide 'core' HTTP request/response semantics. Unidirectional streams SHOULD be used for extensibility?

…

On Sat, 19 May 2018, 00:12 Mike Bishop, ***@***.***> wrote: The more I think about this, the more appealing it becomes, actually. Then the weird state machine from H2 with Server Push simply becomes one more type of extension-owned unidirectional stream, and if we wanted to pull Push out into an extension on its own, we could. Let me sketch this out, and we'll see how crazy it winds up being. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1323 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGRFtQiFwgs5AE7oNi2LB3nrYsUG5Ftsks5tz1VkgaJpZM4TiFAS> .