Should HTTP load balancer forward bad requests to backend?

in flag

If a HTTP client sends a GET request with a body that would generate a 400 Bad Request response, should the load balancer forward that request to the backend or deal with it immediately? Is there any advantage in NOT dealing with it at the load balancing layer?

Recently, an application team complained that a load balancer was returning 400 Bad Request when the application itself would return 405 Method Not Allowed. It seemed the load balancer was right and the application team had a misunderstanding but that left me wondering when the load balancer should more forgiving and forward crap to backends anyway.

cn flag

Why not both? A http request can be both malformed, and the verb attempted not supported in that context. 400 is easier to check with just a parser, so the load balancer can reject non compliant headers without knowing what the request really means.

Defense in depth applies. A bad, possibly malicious, request rejected by a front end is one a back end never has to see. Possibly stopping an attack that the backend would not by itself.

haproxy, for example, is of the opinion that their option accept-invalid-http-request and option accept-invalid-http-response should be left disabled. That is, standards compliant. Of course, as configurable as haproxy is, it can be set to a relaxed mode to deal with broken things.


Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.