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