Is it possible for a server to protect from a malicious client sending humongous requests? And for a...

# http4k

[Mikael Ståldal]

Is it possible for a server to protect from a malicious client sending humongous requests? And for a client to protect from a malicious server sending humongous responses?
I tried to simulate this, and got java.lang.OutOfMemoryError when using a lens, since it reads the whole payload into memory before parsing it:

class StreamBody(override val stream: InputStream, override val length: Long? = null) : Body {
    override val payload: ByteBuffer by lazy { stream.use { ByteBuffer.wrap(it.readBytes()) } }
    // ...
}

It would be nice to be able to specify a max payload size.

[dave]

depending on the backend you're using you can set this up there.

[Mikael Ståldal]

Do you have an example?

[Andrew O'Hara]

Not an expert, but I feel like that's more the responsibility of a WAF rather than the application. A WAF will typically sit just inside or outside your load balancer.

[dave]

yeah, it kind of depends on your usecase

[Mikael Ståldal]

What is a WAF?

[Mikael Ståldal]

I did a workaround by wrapping body.stream with <http://org.apache.commons.io|org.apache.commons.io>.input.BoundedInputStream , but then I cannot use lenses (or can I?).

[dave]

https://www.cloudflare.com/en-gb/learning/ddos/glossary/web-application-firewall-waf/

[dave]

you don't really want to start dealing with streams unless you really need to. As mentioned, this isn't really a concern of your endpoints

[Mikael Ståldal]

OK, but you have an example of a backend which supports this?

[dave]

which backend are you using?

[Mikael Ståldal]

I am not using any at the moment, so I am open to suggestions.

[Mikael Ståldal]

(I am not using http4k in production yet, but considering it.)

[Mikael Ståldal]

(And trying it out.)

[dave]

https://undertow.io/undertow-docs/undertow-docs-1.4.0/listeners.html#:~:text=Defaults%20to%2050k.,size%20of%20a%20request%20entity.

[dave]

but as @Andrew O'Hara says - you should try to rely on the infrastructure for this type of thing

[Mikael Ståldal]

OK, nice.

[dave]

configuring the backend is the next step

[dave]

you don't want to really do it IN your biz logic

[Mikael Ståldal]

Right.

[Mikael Ståldal]

What about client?

[dave]

If you do configure the backend, you'll need to write a custom Undertow (or other) backend. This is pretty easy, it's just mostly boilerplate with a couple of options set

[dave]

what do you mean?

[Mikael Ståldal]

I am using http4k as client also, and want to protect against humongous responses from server.

[Mikael Ståldal]

Is there a client backend with similar protection possibility perhaps?

[dave]

but for the client - you are in control of the code aren't you?

[dave]

I mean it's possible - but once again you would have to configure the underlying client (OkHttp, Apache, Jetty)

[dave]

well - I don't know actually if any clients support that

[Andrew O'Hara]

I haven't found anything to support that in okhttp or apache client yet

[Andrew O'Hara]

https://github.com/square/okhttp/issues/5599

[fredrik.nordin]

Whilst theoretically possible for a server to be malicious and send a humongous response, I would argue that it's not going to happen in practice. Any server that you connect to using a client you should already trust (be it an internal server or an external server from a reputable service). That is probably why you don't see that ability included in the most commonly used http clients. My 2p.