Re: YAC Proposal

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
>
>