Re: #541: CONTINUATION

On Mon, Jul 7, 2014 at 3:27 PM, Poul-Henning Kamp <phk@phk.freebsd.dk>
wrote:

> In message <
> CAEn92TqRUkns8FLC_cLZ1xbh1iNpVexixZtawR1M7A5Eg8n-8g@mail.gmail.com>,
> Johnny Graetting
> er writes:
> >--001a11c1bbc0fda6b704fda1e67e
> >Content-Type: text/plain; charset=UTF-8
> >>
> >> I thought about server visibility along these lines:
> >>
> >> In the case where the server is producing the basis for subsequent
> >> requests (ie: links on a web-page), It is reasonable to expect the
> >> web-designer to either theoretically or through tests confirm that
> >> the links pass muster.
> >>
> >
> >This is a tall order :) Consider even a mildly-dysfunctional organization
> >with multiple teams owning siloed services operating over a shared cookie
> >space. Throw in some AJAX requests with metadata made across those service
> >boundaries for extra fun.
>
> I have no problems with them having to think.  Their users/customers
> will probably thank me for the better performance :-)
>

Turns out that coordination across 30k developers isn't trivial. :)


>
> >In the other case, for instance where the client composes requests
> >> based on some written API manual, I think the risk of huge HEADERS
> >> is much more likely, but here again it doesn't matter who produces the
> >> 413, the right person still receives it.
> >
> >How do I (as an API provider) discover that users are trying to use my
> >service in a way I'm not currently supporting?
>
> They'll complain to you ?
>

Sadly, only sometimes.
-=R


>
> >A server can advertise a SETTINGS which is narrowly tuned to allow
> >> all legitimate requests.
> >
> >In my experience, "narrow tuning to allow all legitimate requests" is an
> >oxymoron :)
>
> Well, your experience is obviously different from mine (proxied through
> from the varnish users I talk with).  Their current response to the
> lack of header-compression in HTTP/1.1 is to think a lot about how
> big their ingoing and outgoing headers are, and how to use this to
> discriminate DoS attacks.  Some of them have both upper and lower
> bounds on valid requests.
>
> >If I have intent to DoS, I'll send you exactly as much payload as you
> allow
> >and no more. I'm not going to make it easy for you.
>
> That's a lot easier for me to handle than the current drafts "any
> number of CONTINUATION" packets with no specified timeout.
>

You're conflating things.
Timeouts when receiving metadata/headers is an issue regardless of the use
large frames or continuations, as a promise of X bytes (or a complete
header) doesn't mean it will actually happen, or that it will happen in a
reasonable period of time.
This is an issue with both large frames and continuations. It is not
limited solely to continuations.

-=R


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