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 <phk@phk.freebsd.dk> wrote: > In message < > CAP+FsNdoESu1GyRwyU5GCQGXFxXaHNfi92d13K86gHxxwFYEJg@mail.gmail.com> > , 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 Friday, 11 July 2014 23:27:34 UTC