In message <>
, 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