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

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.

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

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

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

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

Received on Monday, 7 February 2022 07:01:40 UTC