W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2022

Re: Working Group Last Call for draft-ietf-httpbis-binary-message-01

From: Willy Tarreau <w@1wt.eu>
Date: Mon, 7 Feb 2022 09:24:56 +0100
To: Mark Nottingham <mnot@mnot.net>
Cc: Martin Thomson <mt@lowentropy.net>, Christopher Wood <caw@heapingbits.net>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20220207082456.GB10827@1wt.eu>
On Mon, Feb 07, 2022 at 05:52:22PM +1100, Mark Nottingham wrote:
> incomplete messages are part of the model, see:
>   https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#message.framing
> 
> Probably just a flag should do it.

I tend to think so. An alternate approach could be to mention a truncated
size in a final message (could allow to pad with zeroes or so and indicate
at the end what was padded). But that's more painful to deal with, especially
on intermediaries.

> > - I think it would be useful to be able to advertise a partial message, for
> >  example for remote analysis, or if we'd want a server to transfer some of
> >  its in-progress processing to another one. Maybe that would be done using
> >  byte-range, I don't know. But at least it ought to be suggested so that
> >  the solutions adopted remain clean and interoperable.
> 
> Hm. If it's a partial HTTP message, that should be self-documenting, no?

I'm not totally sure. It depends what we want to transport. Sending
a byte-range field as part of a forwarded message that was purposely
truncated for analysis is not the same as sending a partial message
that contained a byte-range field. Imagine for example that a logging
system wants to log all fields and the first few elements from the body,
and makes use of bhttp to pass the beginning of the request from an
edge gateway to the log server. Here we would need to alter the fields
to place a byte-range.

> > - depending on the targetted use cases, being able to also pass the HTTP
> >  version could make sense. For example, indicating and an incoming message
> >  comes from an HTTP/1.0 client tells the recipient that certain features
> >  cannot be used. Also for logging it can be useful. Wouldn't it be the
> >  right moment to register the ":version" pseudo-header field that was
> >  not needed for H2 ?
> 
> I think allowing some controlled capture of the message's context would be
> useful. E.g., information about the connection it occured upon, and about
> related messages -- either by reference or including values. In particular,
> knowing the target URI for a given response is often a very useful thing.

Yes, good point. Same for ALPN, and SNI maybe sometimes.

> However, I *don't* think it's a good idea to overload headers yet again for
> this purpose; keep it separate. Maybe just a once-per-message bag of
> key/value pairs with a separate registry controlling them?

Yes probably. In some (rare) cases we'll want to pass *both* a request
and a response. I'm thinking about cases where a cache would want to
share its contents with other nodes, or the case you mentioned above
about related messages. Most likely, being able to chain a request and
a response would address this. Alternately the carrier message would
have to pass two such representations.

Willy
Received on Monday, 7 February 2022 08:25:18 UTC

This archive was generated by hypermail 2.4.0 : Monday, 7 February 2022 08:25:19 UTC