> > >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. Right. Assuming I've already done the best I can with compression, this outcome is functionally no different than actually sending the request, and getting a 413 or closed connection. If I send the request, at least I've given the server visibility into the failure. >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. > Right. Servers must still handle headers which are larger than they'd like. So, having a maximum header size setting isn't useful to the client, and it doesn't protect the server. What's being bought here? It *might* buy the server implementer the convenience of simply closing the connection, rather than issuing a 413 and preserving the connection. But then again probably not, as they'll probably want to issue 413's in some cases anyway as part of layered DoS mitigation.
Received on Monday, 7 July 2014 20:43:47 UTC