Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
dnsdist: Send better HTTP status codes, handle ACL drops earlier #7917
We used to send a 500 status code when a query was dropped, regardless of the reason. This PR tries to return a more appropriate status code instead.
here is our line of reasoning why we consider it discouraged to close a TCP connection directly instead of providing a proper HTTP response code:
If the TCP connection comes from a client that is not allowed as per ACL why not answer with
And if dnsdist on a plain (non-DoH) frontend were to answer with
this sound more like an issue with the backend? and
Right, I understand that closing the TCP connection right away will not play well with some HTTP clients or proxies. I will make sure we send a 403 code instead when the source IP is not allowed by the ACL.
This PR currently turns that into a 502 instead. I don't really know if 502 or 504 is more appropriate, since it's not really a timeout at that point. I'm not sure it matters much for this case, since it's very unlikely to happen.
Thanks a lot for the feedback, this is very useful!
referenced this pull request
Jun 13, 2019
Thanks a lot for considering our concerns, this is very encouraging when feedback is actually taken into account!
we would suggest to aim for the following principles in this area of "what response code to return?". We understand that this is not trivial since not every possible error condition has a perfectly matching and specified HTTP error code representation.
a) try to match the HTTP error code description as specified in RFC as good as possible
Some more explaining about (d)