- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Sat, 28 Oct 2017 03:16:58 +1300
- To: ietf-http-wg@w3.org
On 27/10/17 20:32, Andy Green wrote: > > > On 10/27/2017 02:59 PM, Amos Jeffries wrote: >> On 27/10/17 12:40, Andy Green wrote:> >>> The spec still needs to touch on the changes it is making to h2 DATA >>> frames, it assumes it is inheriting generic bidirectional transport >>> from h2, but it isn't. H2 DATA kills the stream if it comes outside >>> of whatever was told for content-length: on both sides, and eg h2spec >>> requires you to enforce that. So the spec requires changes in DATA >>> handling implementation for upgraded streams and should note it. >> >> AIUI, Content-Length remains optional in h2 as it was in 1.x. The h2 > > h2spec tests for these > > 8.1.2.6. Malformed Requests and Responses > ✔ 1: Sends a HEADERS frame with the "content-length" header > field which does not equal the DATA frame payload length > ✔ 2: Sends a HEADERS frame with the "content-length" header > field which does not equal the sum of the multiple DATA frames payload > length > Nod. Those conditions are applicable only *if* a content-length is sent. There is no requirement to send it. In cases where the payload/stream length is unknown or unknowable sending a Content-Length is the wrong thing to do - it would probably break things worse than omission. >> equivalent of Transfer-Encoding:chunked is being used by wss. Just a >> stream of DATA frames in both directions terminated by the END_STREAM >> flag instead of a specific Content-Length value. > > Well, that is banned in h2, but I guess you are right, if there is no > content-length: it can just end on END_STREAM and there's no problem... > it's my misunderstanding I guess. The behaviour semantic was preserved in h2 but the binary representation is much improved. That is why I used the words "h2 equivalent of ...". Amos
Received on Friday, 27 October 2017 14:17:28 UTC