- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Sat, 27 Jan 2018 10:50:39 +1300
- To: ietf-http-wg@w3.org
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