W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: CONTINUATION was: #540: "jumbo" frames

From: Roberto Peon <grmocg@gmail.com>
Date: Sat, 28 Jun 2014 13:47:59 -0700
Message-ID: <CAP+FsNfPVwscp0PpQLFgDO_ZKDZ0cf9pFgjjx4Pyd6nw_kh3SA@mail.gmail.com>
To: Jason Greene <jason.greene@redhat.com>
Cc: Greg Wilkins <gregw@intalio.com>, Willy Tarreau <w@1wt.eu>, Patrick McManus <pmcmanus@mozilla.com>, Johnny Graettinger <jgraettinger@chromium.org>, Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>, Mark Nottingham <mnot@mnot.net>, Simone Bordet <simone.bordet@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
When one is doing 1:1 proxying there is no real downside to allowing
transmission before the entire suite of headers has been received.
This is especially true if used for non-browser usecases.

When remuxing among multiple clients/servers, life is harder, and there are
a number of different tradeoffs.

-=R


On Sat, Jun 28, 2014 at 1:38 PM, Jason Greene <jason.greene@redhat.com>
wrote:

>
> On Jun 28, 2014, at 2:48 PM, Roberto Peon <grmocg@gmail.com> wrote:
>
> > If you're concerned that headers are being sent a byte-at-a-time
> (slowloris style), then you could do that with a regular headers frame
> anyway.
> > If you're concerned that the overhead of frames is blowing up the
> bandwidth, then that could happen with PING, SETTINGS, DATA, etc. and is
> not unique to HEADERS or HEADERS processing.
> > It is also point-to-point, and so any non-malicious client should be
> unaffected by malicious clients.
> >
> > The requirement to send END_HEADERS unless it is at max size adds a DoS
> vector because it makes it impossible for a proxy to forward anything or
> send anything until it has buffered the entire HEADERS, even when it has
> all of the information necessary to figure out to which server it should
> forward.
> >
> > It is better to allow a proxy to forward data if it can.
>
> True, although if it does that the HOL blocking will force it to buffer
> all the other streams, so its not reliably helpful to break things up like
> that.
>
>
> >
> > -=R
> >
> >
> >
> > On Sat, Jun 28, 2014 at 1:23 AM, Greg Wilkins <gregw@intalio.com> wrote:
> >
> > On 27 June 2014 22:16, Willy Tarreau <w@1wt.eu> wrote:
> > Would that be OK for every one ?
> >
> > It would help with my concern of Continuations being used as a DOS
> vector with 1 byte per frame, so long as you are proposing text that say a
> send MUST NOT have the END_HEADERS bit clear unless the frame is at max
> size?  Any receiving can treat non full frames without the END_HEADERS bit
> set as a protocol error?
> >
> > Note that it does not address my concern of code that is not used by
> 99.99% of users but that complicates the handling of every frame and will
> only get used/tested in a tiny minority of deployments.   Such code is
> asking to contain lurking bugs and exploits.... however I think my
> fundamental concern with continuations probably goes back to their jumbo
> frame nature and hpack's single state table... so we would need a big
> rewrite to address that.
> >
> > cheers
> >
> >
> >
> >
> > --
> > 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.
> >
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
>
Received on Saturday, 28 June 2014 20:48:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:31 UTC