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


From: Roberto Peon <grmocg@gmail.com>
Date: Mon, 7 Jul 2014 15:38:28 -0700
Message-ID: <CAP+FsNcX4XACcf7_zeVWjmjzZycVG3cDVYXV7Tk7CRGOU2TLOg@mail.gmail.com>
To: Poul-Henning Kamp <phk@phk.freebsd.dk>
Cc: Johnny Graettinger <jgraettinger@chromium.org>, Mike Bishop <Michael.Bishop@microsoft.com>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
On Mon, Jul 7, 2014 at 3:27 PM, Poul-Henning Kamp <phk@phk.freebsd.dk>

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

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


> --
> 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.
Received on Monday, 7 July 2014 22:38:55 UTC

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