- From: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Date: Mon, 14 Jul 2014 21:24:06 +0000
- To: Jeff Pinner <jpinner@twitter.com>
- cc: "K.Morgan@iaea.org" <K.Morgan@iaea.org>, Yoav Nir <ynir.ietf@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
In message <CA+pLO_guorbucMmC0j+Y2-u0DZFPjUs8STkhuAdsR2sYE+F2ig@mail.gmail.com>, Jeff Pinner writ es: >>> 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? Many of the "tiny" TCP stacks only have a single packet buffer, and the MTU varies from ethernets 1500 down to the historical minimum MTU of 296 often used on ad-hoc mesh-networks. (that's actually an argument for using 256 - size of frame header for the limit) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Received on Monday, 14 July 2014 21:24:29 UTC