- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Sat, 12 Jul 2014 15:03:19 +1200
- To: ietf-http-wg@w3.org
On 12/07/2014 1:23 p.m., Roberto Peon wrote: > h2-13 can be fragmented, but not interleaved. Those are different things! > -=R > non-interleaving and fragmenting mean nothing ... On 12/07/2014 2:59 a.m., Roberto Peon wrote: > IIRC we've seen response headers as large as 12mb, > at which point we said: OK, lets have a 2G limit (effectively infinite), > because clearly we can't predict this. > > -=R ... when attempting to manage such large headers. Each status-quo fragment is only 16KB after all. Easily enough to buffer right? Ability to know and reject the total up front is crucial. The simplest and best way to do that is with atomic large frames. Avoiding the penalty imposition of coping with inifinity on all implementations we (Greg et al) have the SETTINGS limit. Amos > > On Fri, Jul 11, 2014 at 4:27 PM, Greg Wilkins wrote: > >> >> In summary the case put against this proposal is that some think 31 bits >> might be too large. >> >> There has also been a concern put about header fragmentation, but h2-13 >> cannot be fragmented either, so that is really not a point against this >> proposal. >> >> Other than that, I thought we were pretty close to consensus. None of >> the counter proposals made have come close to the near consensus shown in >> this thread. >> >> I think we are missing a good opportunity to settle many issues and move >> on. >> >> >> >> >> >> On 12 July 2014 06:15, Poul-Henning Kamp wrote: >> >>> In message Roberto Peon writes: >>> >>>> As I mentioned before, IIRC we've seen response headers as large as 12mb, >>>> at which point we said: OK, lets have a 2G limit (effectively infinite), >>>> because clearly we can't predict this. >>> >>> So there are two questions we need to ask ourselves: >>> >>> 1. Should the protocol support this case ? >>> >>> 2. By default or by configuration ? >>> >>> 3. Who should suffer most ? >>> >>> My answers are: Yes, configuration and sender. >>> >>> Yes, because it is stupid to make a protocol with arbitrary limitations. >>> >>> Configuration because we should not force all HTTP/2.0 implementations >>> to over-reserve memory on the off-chance that they ever see one of >>> these requests. >>> >>> Sender, because in particular in a case like this, it is important to >>> give the receiver advance notice that exceptional memory management >>> will be required. >>> >>> >>> -- >>> 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. >>> >> >> >> >> -- >> Greg Wilkins <gregw@intalio.com> >> http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that >> scales >> http://www.webtide.com advice and support for jetty and cometd. >> >
Received on Saturday, 12 July 2014 03:03:51 UTC