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

Hi Lucas,

I don't think capsules are a good fit here. Our deployment involves
traditional HTTP intermediaries that speak standards-compliant HTTP between
each other, except that we want to add a little bit more information. This
is the very reason that HTTP was made to be extensible, to allow adding
features without having to build your own custom protocol like PROXY. For
example PROXY would be a huge performance hit because it would conceptually
require falling back to h1 and we see significant gains from the connection
reuse properties of h2 and h3.

David

On Mon, Jul 25, 2022 at 1:03 PM Lucas Pardue <lucaspardue.24.7@gmail.com>
wrote:

> 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
>
>
>>