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

From: Mark Nottingham <[email-masked]>
Date: Fri, 4 Feb 2022 13:25:49 +1100

This message begins Working Group Last Call for draft-ietf-httpbis-binary-message-01, 'Binary Representation of HTTP Messages'.

  https://datatracker.ietf.org/doc/draft-ietf-httpbis-binary-message/

Please read the document, raise issues if you find any, and indicate on-list whether you support its publication.

WGLC will end on 4 March 2022.

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: Wenbo Zhu <[email-masked]>
Date: Sat, 5 Feb 2022 09:10:28 -0800

I only have a few comments.

The use cases are certainly there, i.e. " encoding of HTTP messages that
can be conveyed outside of an HTTP protocol". We have done this for a long
time, in many forms but all encoded with protocol buffers
<https://en.wikipedia.org/wiki/Protocol_Buffers>.

I wonder if an http-wg version of "ASN.1" definition is needed here. We
certainly won't switch to bhttp anytime soon, and there will likely be
performance gaps too to adopt such a new encoding.

When streaming is needed, a new wire protocol will likely be needed in
order to tunnel bhttp.

On Thu, Feb 3, 2022 at 6:29 PM Mark Nottingham <[email-masked]> wrote:

> This message begins Working Group Last Call for
> draft-ietf-httpbis-binary-message-01, 'Binary Representation of HTTP
> Messages'.
>
> Please read the document, raise issues if you find any, and indicate
> on-list whether you support its publication.
>

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 07 Feb 2022 09:08:04 +1100

> performance gaps too to adopt such a new encoding. 

That's a strong claim.  Is there something in the design that suggests to you a performance deficit?

> When streaming is needed, a new wire protocol will likely be needed in 

How so?  Maybe I'm not understanding your comment, but the format supports streaming.

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 7 Feb 2022 06:37:36 +0100

> Please read the document, raise issues if you find any, and indicate on-list whether you support its publication.

There's a mistake here:

  3.5. Response Control Data

  The control data for a request message ...
                         ^^^^^^^
                         response

Other than that I do support publication, I think it can be useful.

Willy

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 7 Feb 2022 06:44:42 +0100

> That's a strong claim.  Is there something in the design that suggests to you

I agree with Martin here, my understanding is that it requires the same
job as translating H1 to H2, without the cost of looking up fields in
the HPACK table nor encoding the output. This looks like a single-stream,
simplified H2, and as such I do not see any particular performance issue
here.

Willy

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 7 Feb 2022 07:10:11 +0100

>   https://datatracker.ietf.org/doc/draft-ietf-httpbis-binary-message/

I'm having three other comments:

- I don't see any way to advertise input truncation. I.e. a sender sends
  indeterminate-length data (i.e. HTTP/1.1 chunks or H2 DATA), and the
  connection or stream is suddenly shut. The only way I'm seeing to
  indicate this here is by putting a zero-sized chunk, which will not
  reflect what really happened (i.e. shutdown before zero chunk normally
  indicates a truncated message and it's important not to process it or
  cache it). The same issue exists with known-length content, where it
  seems impossible to feed data in multiple parts as they arrive without
  switching to indeterminate-length which seems to semantically represent
  chunks (hence will probably implicitly cause content-length to be ignored).

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

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

Willy

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 7 Feb 2022 17:52:22 +1100

My .02 - 

> On 7 Feb 2022, at 5:10 pm, Willy Tarreau <[email-masked]> wrote:
> 

I think this is a very good idea; 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.

>  the solutions adopted remain clean and interoperable.

Hm. If it's a partial HTTP message, that should be self-documenting, no?

>  right moment to register the ":version" pseudo-header field that was

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.

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?

Cheers,

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 07 Feb 2022 18:01:06 +1100

Hi Willy,

On Mon, Feb 7, 2022, at 17:10, Willy Tarreau wrote:
> - I don't see any way to advertise input truncation. 

The focus of the design is to convey valid messages, so I'm not inclined to describe how to do this.

However, you might convey an invalid message that contains all of the information you received with a simple trick if you have a communication channel that marks the end of a message.  That is, you aren't using the format itself to self-delimit.  Most uses of this will be carried in a protocol that has its own means of delimiting messages (like HTTP!), so it's not that hard to do.

If you are streaming messages from some source, then when you detect truncation, you will have N bytes of data to transmit.  Whatever version of the encoding you are using, you will need to supply a length prefix before you write out those bytes.  Generally, you do that on a complete chunk of the message, so that the length prefix M == length(message).  Here, you can write out a length prefix M = N + 1, send the N bytes you got, and then end your message at the higher layer.  Any value M > N should do.

This assumes that you are translating from some other source.  If you get a message/bhttp message that is truncated, it will generally include a length prefix that is too long, making truncation evident.  If not, because the truncation occurred between header and body or other natural breaks, you can send a single non-zero byte for the length of the next piece and then end the message prematurely.

The receiver will view the message as being invalid and truncated, but if it needs to look at the data, it has access to all of the data that you received.

>   the solutions adopted remain clean and interoperable.

Byte ranges are another way you could transfer pieces of a message, sure.

>   right moment to register the ":version" pseudo-header field that was

If your protocol allows for meta-information, that might be a better place to put that sort of thing, though I don't have any specific problem with you adding proprietary header fields (they don't need to be pseudo-fields).

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 7 Feb 2022 09:24:56 +0100

On Mon, Feb 07, 2022 at 05:52:22PM +1100, Mark Nottingham wrote:
> incomplete messages are part of the model, see:

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.

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

> 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

---

From: David Schinazi <[email-masked]>
Date: Mon, 7 Feb 2022 11:28:17 -0800

fully* supportive, not sully - sorry.

On Mon, Feb 7, 2022 at 11:27 AM David Schinazi <[email-masked]>
wrote:

> Hi everyone,
>
> I've reviewed this document, and while I'm sully supportive of the general
> direction, I think it could benefit from a bit more editorial work before
> publication. I've filed a few issues (see below) but overall I think the
> format section needs to be more precise about the meaning of all the fields.
>
> Thanks,
> David
>
> https://github.com/httpwg/http-extensions/issues/1943
> https://github.com/httpwg/http-extensions/issues/1944
> https://github.com/httpwg/http-extensions/issues/1945
> https://github.com/httpwg/http-extensions/issues/1946
> https://github.com/httpwg/http-extensions/issues/1947
> https://github.com/httpwg/http-extensions/issues/1948
>

---

From: David Schinazi <[email-masked]>
Date: Mon, 7 Feb 2022 11:27:43 -0800

Hi everyone,

Thanks,
David