Re: Using ACLs to block responses according to status code

From: Mark E. <memarkrav#googlemail.com>
Date: Thu, 28 Feb 2008 17:53:58 +0100


Thanks for the clarification and for the excellent piece of software that HAProxy is!

-Mark

On 2/28/08, Willy Tarreau <w#1wt.eu> wrote:
> 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 17:53

This archive was generated by hypermail 2.2.0 : 2008/02/28 18:00 CET