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