Lighttpd

See docs:modrewrite -> NOTE: url rewriting does not work within a $HTTP["url"] conditional.

It's a redirect, not a rewrite. :) Everything is working fine both within and outside of that conditional apart from that one regex which contains one of the url portions from the url conditional.

Forget my post, misread it.

debugvariables

Cheers. :) I'll run some tests.

I've just run it with the conditional debugging enabled, and, (accepting the fact that my experience with the debug output is extremely limited), it appears as if it works upto the point where it matches the url against the conditional and goes no further within that host block when it doesn't find a match within that conditional. It appears as if the redirect rules outside of that conditional, but within the host block further down, are ignored. Obviously, I could be mistaken however.

Would it possibly make things easier for checking as to where the problem may lay if I e-mailed the debug output and a full copy of the config file to one of the Devs, (due to the size of the debug output)?

Thanks again.

I think you´re limited to a match within a conditional block, you can´t use the results outside.

Surely it ought to class the parent block/conditional as the possible scope for its matches though, rather than descending into a child block/conditional and stopping there if no matches are found? The way it appears to be working at the moment, (if my assumption is correct), limits the usefulness of using child conditionals for fine selection.

I´m not sure, stbuehler might help.

Cheers. Thanks for your help, btw. It's highly appreciated.

Let me try to explain the config system: for every option we go trough the complete config and choose the last assignment we find in an "active" block (i.e. conditional matched); in this context all rules in a block come before all rules of the sub blocks. Have a look at "lighttpd -pf /etc/lighttpd-config-file" to see how lighttpd sees your config (this is especially helpful if you want to find out what "+=" does).

Not all conditional types are available for all "hooks", that is why rewrite doesn't work in url conditionals (as the url conditional is not activated before the rewrite hook).

If I understand your reply correctly, using the -pf option with Lighttpd, the last block/match listed in that output for the parent container is the one which will be used, and any other possible matches ignored?

Yes, only the last one is used, the others are ignored.

Surely though, the child conditional itself should not be classed as a match if there are no matching regex'es within it? Logic would suggest that the conditional is checked for any matching regex within it, but if none are found, a matching regex within the parent block takes precedence over the actual conditionals match. How it works at the moment, (unless I'm missing some obvious logic), means that it's impossible to use a child conditional as a quick stop to prevent further regex matching for only certain portions of a url whilst catering for a blanket regex within the parent which will catch any further matches not specifically listed within that child.

Granted, it can be worked around in a couple of ways which spring to mind, but that means certain regex'es need to be longer and more complicated, or even be repeated with only slight variations, to work around it.

Btw, thanks for the tip on using that -p option. I'd not realised that option existed. It makes life a lot easier for figuring out how the config rules will apply.