- From: Jeff Pinner <jpinner@twitter.com>
- Date: Mon, 14 Jul 2014 14:20:00 -0700
- To: "K.Morgan@iaea.org" <K.Morgan@iaea.org>
- Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, Yoav Nir <ynir.ietf@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
>> The argument against doesn't make sense to me, embedded clients >> already have to deal with a 16-bit IP length field so the idea that >> they can't handle a 14-bit HTTP length field seems absurd. > > Your argument seems absurd :) > > The device certainly doesn't receive 2^16 bytes in a single packet. There are micro-controllers that don't even have enough RAM to hold that much data. Rather, it will deal with the data packet-by-packet, frame-by-frame. And why would the device need to buffer the entire HTTP frame in memory? How are the HTTP frames and different from the IP or TCP frames in terms of buffering requirements?
Received on Monday, 14 July 2014 21:20:27 UTC