Hacker News Reader

He's saying the opposite.

His point is that adding in a request limit in your server config may not be enough because protocols like websocket might not inherit those size restrictions automatically due to specialized logic for implementing sockets over http.

What part of that do you interpret as trusting the client?

> Paul points out that alternative paths such as WebSockets might bypass limits that are in place for regular HTTP requests <

I'm not sure I interpret that as trusting the client; rather, it seems like the implication is that HTTP limits will be handled correctly by webserver harnesses, whereas WebSockets may not get any such behavior "for free" from the server framework.

He’s saying that some Webservers allow you to limit request size, but the limits you set might only apply to HTTP(S) and can be circumvented when using another protocol. That’s a server side problem.

Is English not your first language? If it is, I am utterly baffled as how you think that's an endorsement trusting the client, rather than merely a description.

He says it's more difficult than you might expect not to.

I think that's an artifact of the problem statement. For example, "length check while receiving or in the process of decompressing" eliminates things like websockets from the equation entirely.