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

Re: #541: CONTINUATION

From: Poul-Henning Kamp <phk@phk.freebsd.dk>
Date: Mon, 07 Jul 2014 20:06:51 +0000
To: Johnny Graettinger <jgraettinger@chromium.org>
cc: Mike Bishop <Michael.Bishop@microsoft.com>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <77588.1404763611@critter.freebsd.dk>
In message <CAEn92TpmfYG20dphWw3uhYQy8aA+sAiMpsm+taQM=Qjmym8meg@mail.gmail.com>
, Johnny Graettinger writes:

>Agreed. The concept of pre-announcing request and response header limits
>seems... messy to me. I don't know what it means if I have a request who's
>header size is larger than the limit.

It means you might as well not send it, the best you can hope for is
a 413, at worst, it will kill the connection.

Your two options is to give up, or try to spend more CPU time finding
a more efficent compression (provided the chosen header compression
allows this).

>For that matter, how does the remote endpoint
>discover the impact the setting is having on actual clients? I'd rather
>just optimistically fire off the request as I do now, and let the remote
>endpoint be the arbiter of whether it's over limit.

We can't prevent you from doing this, and you'll get the treatment
the protocol specifies for it.

>It also seems problematic to announce to a potentially-malicious host
>exactly how much they can get away with before DoS mitigation starts
>kicking in.

This limit is unlikely to be the entire DoS mitigation mechanism or
for that matter trigger.

-- 
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 20:07:15 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:09 UTC