RE: Sending responses with unknown body size in HTTP/2

Hi Amos,

Thanks for the reply!

> Valid yes. Section 8.1.2.3 "MAY send a Content-Length header". So the
> inverse is also logically true, SHOULD not send one - especially in the
> case where length is unknown.

> Senders are not obliged to send Content-Length for HTTP/2, they can
> simply END_STREAM on a DATA frame.

That's what I was thinking, good to hear others interpret the same way.


>> When thinking through this problem a while back, I had thought that in
>> the HTTP/2 case it would be possible to append the content-length as a
>> trailer but I convinced myself that was also invalid due to a number of
>> other HTTP semantic rules.

>Which ones? IMO it is valid, though only useful for the message
> integrity checking.

Well, RFC7230 section 4.1.2 says:

   A sender MUST NOT generate a trailer that contains a field necessary
   for message framing (e.g., Transfer-Encoding and Content-Length),
   routing (e.g., Host), request modifiers (e.g., controls and
   conditionals in Section 5 of [RFC7231]), authentication (e.g., see
   [RFC7235] and [RFC6265]), response control data (e.g., see Section
   7.1 of [RFC7231]), or determining how to process the payload (e.g.,
   Content-Encoding, Content-Type, Content-Range, and Trailer).

I originally had a design where I sent a 206 Partial Reponse. In the leading HEADERS I had a content-length and in the trailing headers I had a content-range and a signature (draft-cavage-http-signatures-09). However, after rereading the above statement and combining it with RFC section 4.1 I came to the conclusion that not only was that design invalid but that the selection of headers that *are* allowed in a trailer is actually quite small. Especially in HTTP/2 where chunked encoding is not permitted.

I'd love to know if my evaluation was incorrect, which would allow me to return to the original design.

Regards
Lucas


-----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
immediately.
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to
this.
-----------------------------

Received on Saturday, 27 January 2018 00:02:03 UTC