Re: YAC Proposal

IIRC several implementations spoke up with having an 8K limit. Now in my case I have a 50k limit (don’t ask!), however, since the continuations feature doesn’t let me set a limit our http/2 implementation would likely default to 16KB (at least when proxying), and enable the extension when raised. Then at least the 99.8% is handled without HOL problems.

Now, my preference would still be to fix continuations in some way that the HOL issues are mitigated, but I’ll take what I can get.

No idea on response limit. I can tell you that my implementation has no limit on response size. However when used as a proxy the request size takes over. Things are a bit different in HTTP/1.1 though because we can efficiently copy between streams. Can’t really do that in HTTP/2.

On Jul 2, 2014, at 7:42 PM, Roberto Peon <grmocg@gmail.com> wrote:

> I wonder how many servers don't. I don't know of any major servers with such a cap, but I'm surely in the dark.
> Do we know how many place a cap on the size of response headers?
> 
> If just about everything supports it, why would it be an extension?
> -=R
> 
> 
> On Wed, Jul 2, 2014 at 5:38 PM, Jason Greene <jason.greene@redhat.com> wrote:
> Sure every server that supports > 16KB of compressed header data will implement the extension, or perhaps another extension :) Either way the end result is the same.
> 
> On Jul 2, 2014, at 7:33 PM, Roberto Peon <grmocg@gmail.com> wrote:
> 
> > Is the extension guaranteed to be supported everywhere?
> > If not, then HTTP2 doesn't offer HTTP1's semantics.
> > -=R
> >
> >
> > On Wed, Jul 2, 2014 at 5:32 PM, Jason Greene <jason.greene@redhat.com> wrote:
> > Compatibility isn’t really affected here. You simply use the extension if you wish to accept > 16KB of compressed header data. HTTP/1.1 servers were not required to support it any more than they are today.
> >
> > On Jul 2, 2014, at 7:21 PM, Roberto Peon <grmocg@gmail.com> wrote:
> >
> > > One cannot remove continuation without addressing backwards compatibility with HTTP/1.1 deployments sending large headers.
> > >
> > > The status quo, or a variation which improves the state machine around continuation (e.g. by moving the flags to the last frame of the headers block) makes the most sense to me
> > > -=R
> > >
> > >
> > > On Wed, Jul 2, 2014 at 4:22 PM, Nicholas Hurley <hurley@todesschaf.org> wrote:
> > > This sounds like a non-starter, to me. As mentioned in the other thread, I prefer either the status quo, or failing that a stateless CONTINUATION. This seems worse to me than either of those options. With a stateless CONTINUATION, in the rare occasions when I'll encounter a compressed header block > 16k, I can roll back just one step in my HPACK compression, and then continue on sending an uncompressed form of the headers. With CONTINUATION as an extension, when the other side doesn't advertise support, I would either have to either roll back the entire HPACK state that I changed when trying to compress the headers and generate a RST_STREAM (likely synthesizing an 413 or some other error in the process for my own side), or I'd have to send a GOAWAY, and dial back. Neither of those options is in any way more appealing than stateless CONTINUATION (which I'm still not entirely sold on to begin with!)
> > >
> > > --
> > > Peace,
> > >   -Nick
> > >
> > >
> > > On Wed, Jul 2, 2014 at 12:51 PM, <K.Morgan@iaea.org> wrote:
> > > I'd like to propose yet another option to Mark's list of options for dealing with the "CONTINUATION issue".
> > >
> > > Make it an extension.
> > >
> > > In NYC several people mentioned that if we add extensibility, we should have an extension(s) right from the start that are used.  CONTINUATION IMO is a good option for an extension.
> > >
> > > Here is the CONTINUATION extension draft:
> > > http://www.ietf.org/id/draft-johndoe-http2-large-header-blocks-00.txt
> > >
> > > Here is the pull request to remove CONTINUATION from the core h2 draft:
> > > https://github.com/http2/http2-spec/pull/547
> > >
> > > -keith
> > >
> > > This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.
> > >
> > >
> > >
> >
> > --
> > Jason T. Greene
> > WildFly Lead / JBoss EAP Platform Architect
> > JBoss, a division of Red Hat
> >
> >
> 
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
> 
> 

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat

Received on Thursday, 3 July 2014 01:06:53 UTC