Re: Options for CONTINUATION-related issues

If it isn't there already, it certainly deserves to be!

I suspect that that wiki will end up being an interesting work product
itself-- recording why one doesn't go down a particular path, or why
another path is chosen is useful.
-=R


On Thu, Jul 17, 2014 at 11:23 AM, Jason Greene <jason.greene@redhat.com>
wrote:

> Yes that was in my original email about the option (which was included in
> the reply):
>
> > >> Cons:
> > >> - As with all other length limited proposals, sender has to rewind
> encoder state to that of last sent frame.
>
>
> I was just focusing on the differentiation of the pros though.
>
> I didn’t bother to add it to the wiki, just because I wasn’t sure there
> would be any interest to go this way. I can definitely do that though just
> in case.
>
> On Jul 17, 2014, at 1:09 PM, Roberto Peon <grmocg@gmail.com> wrote:
>
> > The list you have here didn't mention that any length requirement also
> requires the compressor to be able to rewind state, which is most decidedly
> non-trivial, and is a great way to require memory over-commitment.
> > These are considered with pros/cons/requirements in the wiki link that
> Mark sent out a few days back-- it would be good to refer to that doc
> (and/or modify it), as it is likely to better capture all pros/cons.
> > Certainly it is more reliable than my memory :)
> >
> > -=R
> >
> >
> > On Thu, Jul 17, 2014 at 10:04 AM, Jason Greene <jason.greene@redhat.com>
> wrote:
> >
> > On Jul 16, 2014, at 11:44 PM, Mark Nottingham <mnot@mnot.net> wrote:
> >
> > >
> > > On 17 Jul 2014, at 1:42 am, Jason Greene <jason.greene@redhat.com>
> wrote:
> > >
> > >>
> > >> On Jul 16, 2014, at 9:53 AM, Greg Wilkins <gregw@intalio.com> wrote:
> > >>
> > >>>
> > >>> On 16 July 2014 17:08, Mark Nottingham <mnot@mnot.net> wrote:
> > >>> Are there any other realistic (i.e., capable of achieving consensus,
> NOT just your favourite approach) options that we should be considering?
> > >>>
> > >>> hmmmm I am probably being unrealistic.... but let's tilt at this
> windmill
> > >>>
> > >>> c) Remove CONTINUATION from the specification, allow HEADERS to be
> fragmented and add a new setting that advises the maximum header set size
> (i.e,. uncompressed) a peer is willing to receive (but might not imply
> PROTOCOL_ERROR or STREAM_ERROR on receipt).
> > >>
> > >> I have a fourth option to add to the mix which is based on all of the
> feedback I have seen.
> > >>
> > >> AFAICT there is only one limited use-case that can not be covered by
> the recent move to allow large frames. That is the ability to split a frame
> into chunks so that a 1:1 proxy doesn’t have to buffer.
> > >>
> > >> We could have a more narrow form of CONTINUATION:
> > >>
> > >> - The sum of all continuation frames can not exceed max_frame_size.
> > >
> > > The default of max_frame_size is 16k; that means that a server can't
> ever send more than 16k (or 32k, depending on whether you intend to include
> HEADERS in the max) of response headers without some adjustment by the
> browser…
> >
> > Right. The thinking there is that 99.8% of headers are < 16K, so this is
> more than enough, and when you have a .2% you can just bump the frame size.
> >
> > If you compare CONTINUATION to Large Frames, they are actually very
> similar.
> >
> > They both:
> > - Can send very large headers
> > - Block other streams until completion
> > - Support writing to the wire in chunks
> >
> > Continuations adds:
> > - 16MB -> Unlimited headers
> > - Ability to write in chunks without knowing the total compressed length
> >
> > The former is not really desirable and causes #551.
> > The latter offers very limited value, in that a 1:1 proxy can re-encode
> the frame using different hpack state and send the data across in piecemeal.
> >
> > So this option is simply saying we can address that particular use-case,
> if deemed important, by supporting fragmentation of the HEADERS frame. We
> don’t have to span frames to accomplish the need. By not spanning frames we
> solve #551, and also eliminate the DOS exposure concern which has been
> brought up against a header size limit solution.
> >
> > >
> > >
> > >> Since this use case is avoiding buffering, they may not know the
> exact size has exceeded the max until the Nth continuation is sent.
> Therefore:
> > >>
> > >> - Add a discard flag on the last HEADER/CONTINUATION frame, which
> instructs the endpoint to discard the request and all buffered data.
> > >
> > > Why not just reset the stream?
> >
> > The only benefit in not reseting the stream is just notifying the server
> that a request wasn’t sent because it was too big. Although I agree its of
> limited value. It was a concern brought up against size limits, that a
> server does not know when a request is too big. I personally disagree with
> the concern, I just was describing one way it could be handled.
> >
> > >
> > >
> > >> Pros:
> > >> - Addresses 551
> > >> - There is only one max setting
> > >> - Encourages reduction of gigantic headers
> > >> - As a side-effect of the discard flag, it provides a client the
> ability to inform the server that a request was too large and would have
> generated a 431 (not really significant but it came up in a thread and
> worth mentioning)
> > >>
> > >> Cons:
> > >> - As with all other length limited proposals, sender has to rewind
> encoder state to that of last sent frame.
> > >
> > > Cheers,
> > >
> > >
> > > --
> > > Mark Nottingham   https://www.mnot.net/
> > >
> > >
> > >
> > >
> >
> > --
> > 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
>
>