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:
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 Received on 2009/01/29 01:38
This archive was generated by hypermail 2.2.0 : 2009/01/29 01:45 CET