Re: Using ACLs to block responses according to status code

Hello Mark,

On Thu, Feb 28, 2008 at 10:36:16AM +0100, Mark E. wrote:
> Hello, I would like to block responses with a status code different
> from 200, 301 or 404.
> To do this I initially went with this rule:
>
> rspideny ^HTTP/1.[01]\
> (20[^0]|2[^0]0|3[^0]1|30[^1]|4[^0]4|40[^4]|[^234][0-9][0-9]).*$
>
> Most probably the regex can be written in a much more efficient way,
> sadly this is the best I could do.
>
> Still, this approach works very well and each time the backend server
> sends a response with a status code different from 200, 301 or 404,
> HAProxy correctly sends to the client a 502 Bad Gateway page.
>
> While reading the latest documentation I saw that it is suggested to
> use ACLs instead of rspdeny and similar keywords.
>
> So I tried to use this:
>
> # Define an ACL that matches the 200 response status
> acl status_200 status 200
>
> # Define an ACL that matches the 301 response status
> acl status_301 status 301
>
> # Define an ACL that matches the 404 response status
> acl status_404 status 404
>
> # Block responses which have a status code that isn't a 200, 301 or 404
> block if !status_200 !status_301 !status_404
>
> The last directive has the result of returning a 403 on every request,
> instead of the 502 I thought I would have.
>
> I went again through the docs and I think that the above behaviour is correct.
> Indeed I noticed that:
>
> 1) The status test is mentioned only in the older docs
> (haproxy-en.txt) and not in the more recent configuration.txt. Even so
> this test should be valid for version 1.3.12 and since I'm using
> version 1.3.14.2 which is not too far, the test should be still valid.
> This is confirmed from the fact that I don't get any configuration
> parsing error.
> So the above ACLs should be correctly defined.
>
> 2) According to the latest docs the block keyword works on requests,
> while I'm trying to block a response.
>
> After these considerations I assume that HAProxy is behaving correctly
> giving me a 403 on every request. It is blocking them because it
> obviously can't find any status code which with the rule above would
> be equivalent to match a status code different than 200, 301 or 404.
>
> So I was wondering if there is a keyword like block, to be used with
> ACLs, that works on responses instead of requests.
>
> I went through the docs without being able to find such a keyword even
> if it is said that ACLs can be used also to define rules on responses.
> I have no problem keeping the reqideny rule but I thought I should get
> rid of it in favor of ACLs.

Your analysis is 100% accurate of the situation. While ACLs can match responses, there is nothing in place to make use of them. During debugging, it was quite obvious to modify the block keyword to block on responses, but it is not implemented as it creates confusion.

There is a need for some thinking about what/how to match in requests/responses, and how to make use of this. Also, sometimes a condition to be used in the response could make use of some information gathered in the request. For these reasons, I prefer not to extend the usage before ensuring that a durable solution is found. BTW, "block" was initially added for debugging purposes only and proved to be useful :-)

So I suggest that you keep the rspdeny right now, even if it looks tricky. When a cleaner method is available, the transition will be easier.

Regards,
willy Received on 2008/02/28 14:20