Re: METADATA frames for HTTP/2 and HTTP/3

Hi Biren,



On Fri, Jul 22, 2022 at 8:56 PM Biren Roy <birenroy@google.com> wrote:

>
>
> On Thu, Jul 14, 2022 at 11:40 AM Lucas Pardue <lucaspardue.24.7@gmail.com>
> wrote:
>
>> Hey,
>>
>>
>> On Thu, 14 Jul 2022, 16:32 Cory Benfield, <cory@lukasa.co.uk> wrote:
>>
>>> Hi Bence,
>>>
>>> I’ve read through the draft. The proposal seems straightforward enough.
>>>
>>> I’m surprised by the usage of HPACK, though. The document implies (but
>>> does not state) that the METADATA frames use the same HPACK encoder/decoder
>>> pair as the regular HTTP/2 streams. I read this implication through the
>>> forbidding of HPACK/QPACK messages containing any operation that would
>>> change the state.
>>>
>>> This seems like it both makes it easy to accidentally fail to comply
>>> with the spec (by not carefully reading that one clause) and reduces the
>>> efficiency of the compression (by forbidding the use of the dynamic table).
>>> Has thought been given to establishing a separate HPACK encoder/decoder for
>>> METADATA frames? That would make it easy to avoid needing to negotiate the
>>> frames, and would also let you take advantage of the dynamic table for more
>>> efficient encoding of the metadata.
>>>
>>> As a protocol extension, my feedback is that this seems to be a solution
>>> in search of a problem. This certainly adds protocol capabilities, but
>>> without specifying any intended use-cases it doesn’t do a good job of
>>> justifying why headers are unsuitable for the task. I think I’d like to
>>> hear the folks with more insight into HTTP’s semantic layer chime in as to
>>> whether they think this is a good fit. As an extension to HTTP/2 I think it
>>> fits well.
>>>
>>
>> I'll echo the points Cory made.
>>
>> I'd push the use case queation further and ask why would I use METADATA
>> frames rather than the capsule protocol to do the equivalent thing? I
>> expect you probably already have an answer to that,  so explaning the
>> tradeoffs might help.
>>
>
> I'm not very familiar with the capsule protocol, but there seem to be two
> major differences: 1) we are looking for a mechanism for conveying
> information hop-by-hop, and it looks like capsule protocol is end-to-end;
> 2) we wanted something that does not affect, or is not affected by existing
> HTTP semantics. Unless I'm missing something, it doesn't seem possible to
> interleave the capsule protocol with a regular HTTP transaction.
>

I'd say this comes back to better understanding use-cases and whether there
is general applicability. If the idea is to create a special single hop
relationship between two elements, then that's a common design pattern. For
example, the PROXY protocol [1].

It sounds like your use case intermixes the actual request/response HEADERS
and DATA with METADATA frames that have little to do with the HTTP
request/response semantics. That's fine. Other ways to do this involve just
mixing in fields directly into the messages themselves, which suffers from
the problem that you have limited points during the entire interaction to
do so. Either way, there is usually a "special relationship" between the
client and server that are doing this handling, which is transparent to the
end-user client or origin server.

My suggestion to use the capsule protocol as an alternative is then a
strawman idea that one can use encapsulation to avoid intermixing of
messages and per hop metadata. For instance, a front end server that
receives a request on an HTTP/2 stream would not forward it on directly,
but instead issue a FOO request that enables the capsule protocol for the
single hop. HTTP headers, HTTP content, and extra metadata are then
encapsulated in new capsule types. The recipient of capsules either
consumes the capsule (i.e. the metadata intended for it) or decapsulates
the HTTP message back into a format to pass to a conventional HTTP
recipient.

Cheers
Lucas

[1] - https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt


>