Support the non-standard HTTP response status: 499 Close.

[amcgregor]

Howdy!

The hosting provider I'm utilizing currently uses Sozu as a front-end load balancer (FELB) solution. It's been a great experience so far, but there is one feature from Nginx (behavior defined under the "Request finalization" section) also implemented in other solutions such as Apigee, which I sorely miss, and is "hard-coded" into the web application firewall implementation my web framework uses: the non-standard response status 499 Close.

The WAF utilizes this to attempt to maximally mitigate the impact of malicious or otherwise blacklisted requests by simply not returning anything to the requesting client, at all, and internally if raised as an exception (HTTPClose) the requesting client becomes blacklisted.

Having recently weathered a DDOS mass requesting invalid resources which ultimately fell back on a database-impacting query, the ability to utilize the WAF as intended (and not artificially transform these into 410 Gone to return a response) would be wonderfully helpful and greatly appreciated.

Thank you for your time.

[amcgregor]

After a quick dive, it looks like there's already code in place—just commented out—to implement such a feature as this. As part of parsing the response status line:

https://github.com/sozu-proxy/sozu/blob/0c5e81fe30dd98f13f515d16acca2c447e968abb/lib/src/protocol/http/parser/response.rs#L236-L241

[FlorentinDUBOIS]

Hello @amcgregor!

Thank you for the interest that you give to Sōzu! We need more precision about what you want us to develop. For what I have read from the HTTP status code 499 Client Close Connection, if we implements it in Sōzu, we should return 499 status code only in 2 cases which are:

• The back-end has answered a 499 status code
• The back-end is too long to answer according to the internal back-end response timeout and Sōzu send a 499 status code and mark the back-end as unavailable.

According to your comment above, it seems that you want another behavior. Could you give us more details about it? By the way, if your WAF answer 499 status code, it does not contact your back-end behind and to me, it works as expected.

[amcgregor]

Howdy!

For what I have read from the HTTP status code 499 Client Close Connection, if we implements it in Sōzu, we should return 499 status code only in 2 cases which are:

Nope!

• The back-end has answered a 499 status code

If the back-end returns 499, hang up immediately by closing the connection, as per the sozu code sample I linked.

• The back-end is too long to answer according to the internal back-end response timeout and Sōzu send a 499 status code and mark the back-end as unavailable.

This has absolutely nothing to do with timeouts whatsoever. No involvement, the code 499 never reaches the user because they have already been hung up on.

According to your comment above, it seems that you want another behavior.

I want the behavior as defined by Nginx, first link in original description. Hang up.

Could you give us more details about it?

I'm really not sure what more I could provide other than the exact documented behaviour.

By the way, if your WAF answer 499 status code, it does not contact your back-end behind and to me, it works as expected.

My WAF is the back-end application, or a middleware layer around it, so this statement may require some clarification. "After contacting the back-end it doesn't contact the back-end if told not to contact the back-end" — that's the sense I get from this.