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

On 27/01/18 07:08, Lucas Pardue wrote:
> Hello,
> 
> �
> 
> I�ve been thinking about how a server can approach sending a body of
> unknown total size.
> 
> �
> 
> In HTTP/1.1, we had the chunked transfer coding. From RFC 7230 section 4.1:
> 
> �
> 
> �� The chunked transfer coding wraps the payload body in order to
> 
> �� transfer it as a series of chunks, each with its own size indicator,
> 
> �� followed by an OPTIONAL trailer containing header fields.� Chunked
> 
> �� enables content streams of unknown size to be transferred as a
> 
> �� sequence of length-delimited buffers, which enables the sender to
> 
> �� retain connection persistence and the recipient to know when it has
> 
> �� received the entire message.
> 
> �
> 
> In HTTP/2, RFC 7540 section 8.1 says
> 
> �
> 
> �� HTTP/2 uses DATA frames to carry message payloads.� The "chunked"
> 
> �� transfer encoding defined in Section�4.1 of [RFC7230]
> <https://tools.ietf.org/html/rfc7230#section-4.1> MUST NOT be
> 
> �� used in HTTP/2.
> 

Nod. chunked encoding == DATA frame. Double-encoding is only harmful, so
is prohibited.


> 
> RFC 7540 section 8.1.3 has an example where it shows how an HTTP/1.1
> chunked response could look in HTTP/2 frame form.
> 
> �
> 
> HTTP/1.1 200 OK����������������� HEADERS
> 
> ���� Content-Type: image/jpeg�� ==>���� - END_STREAM
> 
> ���� Transfer-Encoding: chunked�������� + END_HEADERS
> 
> ���� Trailer: Foo������������������������ :status = 200
> 
> ����������������������������������������� content-length = 123
> 
> ���� 123��������������������������������� content-type = image/jpeg
> 
> ���� {binary data}����������������������� trailer = Foo
> 
> ���� 0
> 
> ���� Foo: bar������������������������ DATA
> 
> ��������������������������������������� - END_STREAM
> 
> ����������������� ��������������������{binary data}
> 
> �
> 
> ������������������������������������� HEADERS
> 
> ��������������������������������������� + END_STREAM
> 
> ��������������������������������������� + END_HEADERS
> 
> ����������������������������������������� foo = bar
> 
> �
> 
> The HTTP/1.1 response does not contain a Content-Length header field
> (presumably because the length is unknown). The HTTP/2 format does
> include a content-length but I�d argue that the example now implies the
> length is now known before the payload is sent.
> 

Note that Section 8.1.2.6 makes it mandatory for intermediaries to fully
receive these infinite-length streams in their entirety before
forwarding onwards. So that they can meet the "MUST NOT forward"
requirement when Content-Length is present.


> 
> Would it be valid here, to omit the content-length in the HTTP/2 HEADERS?
> 

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.

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


AYJ

Received on Friday, 26 January 2018 21:51:13 UTC