- From: Roberto Peon <grmocg@gmail.com>
- Date: Fri, 11 Jul 2014 18:23:04 -0700
- To: Greg Wilkins <gregw@intalio.com>
- Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, Jason Greene <jason.greene@redhat.com>, HTTP Working Group <ietf-http-wg@w3.org>, Martin Thomson <martin.thomson@gmail.com>
- Message-ID: <CAP+FsNcJLzx9RSQazfBE+sZZJh_3yk+ymDH-5dyAbtbPqhGj0Q@mail.gmail.com>
h2-13 can be fragmented, but not interleaved. Those are different things! -=R On Fri, Jul 11, 2014 at 4:27 PM, Greg Wilkins <gregw@intalio.com> 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 <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 Saturday, 12 July 2014 01:23:32 UTC