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

My .02 - 

> On 7 Feb 2022, at 5:10 pm, Willy Tarreau <w@1wt.eu> wrote:
> 
> - 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 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.

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

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

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,

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

Received on Monday, 7 February 2022 06:52:49 UTC