On Wed, 28 Jan 2009, Willy Tarreau wrote:
<CUT>
We may start with implementing a sequential ordering for req (request) and
supporting three default targets: deny, tarpit and allow.
And "redirect" please ;-)
If we do this right there will be no need to add a special "redirect"
target as it should be possible to create it with:
- insert header (Location)
- deny with custom http reply code (3xx instead of 403)
Allowing such possibility *in the right way* is one of my current goals,
however as each change requires some thinking and discussing I prefer to
finish one stage before starting with a next one. I have developed too
many custom patches for haproxy, I really need to clean my code and push
them upstream, one by one. ;) Keeping them outside the mainline cost me
too much.
In fact, I think you should not touch "block" for now, as it's evaluated
very early, independant of this new sequence. We would just have to emit
a big warning when loading a new config using "block" and suggest moving
those lines to the top of the ACLs and changing it with "req deny".
Or we may simply handle it as "req deny" + emitting standard "deprecated"
warning.
<CUT>
Also BTW, there's something else I had planned. Right now you cannot
write rules without an ACL for whatever object. While this is handy
for complex configs, this is very boring for small configs. I'd like
to be able to use the verb as a function in the rules.
For instance, instead of always having to write :
acl admin src 192.168.0.1
allow if admin
you could write :
allow if src(192.168.0.1)
The last changes I made to the rules in order to add better checks
and typing have made that a lot easier. It would of course prevent
caching, as "src(192.168.0.1)" would automatically be compiled into
an implicit ACL, but caching is still not implemented, and people
who would need caching will certainly not use this anyway because
they'd want to factor out common information.
Indeed, your "instant acl's" idea seems very useful. However, I'm not sure
if it is OK to distinguish it by parenthesis - how whould you like to
write it for "hdr(host) -i localhost"?
hehe I thought about that this morning when going to work :-)
Indeed, parenthesis are a bad idea. But having a method for
grouping is still needed, or at least being able to specify a
modifier (-i), an operator (-gt, -lt) and a value. Maybe we
should imply enclose them by parenthesis, something like that :
req allow if (hdr(host) -i www) (src 10.0.0.0/8)
OK, but if we do this we should, at the same time, deny creating acls with
names containing "acl" and/or parenthesis.
Maybe it would be better to add two new keywords: "ifacl" or "unlessacl"?
If I understand what you propose, I don't think it will solve the
issue as I don't see how I could combine two ACLs with this method.
However, a minor modification might consist in having an "acl()"
function :
req allow if acl(hdr(host) -i www) ...
Ack, this looks wisely.
<CUT>
That said, I'm clearly in favor of "deny" instead of "block" and
adding "allow" ;-)
OK. So if you agree on my "req {allow|deny|tarpit} {if|unless} acl"
idea I'll try to rework my patch that way.
Yes I agree with it provided you also include "redirect" and you
keep in mind that later we'll make it evolve towards "in" and "out",
with probably "in" being the default when not specified.
I think we need to discuss more on this "redirect" target. However I
believe whatever solution we will choose it should be possible to add it
by simply extending current syntax.
BTW, may be you have noticed, I have updated the master git tree
on the site (and a snapshot was published yesterday). The HTTP
part is far more easy to modify without being perturbated by
lower layers, and vice-versa. Those who want tons of new features
and new L7 protocols (POP, SMTP) will be happy. At least, I hope :-)
Yep. ;) I have a local copy of the git repository so if I only have
enough time I trace each change as soon as you push it. ;)
Best regards,
Krzysztof Olędzki
