Aliases don't work properly when combined with conditionals based on vhost

[Olaf van der Spek]

server.modules = ( "mod_alias" )
server.document-root = "/var/www/"
alias.url += ( "/a/" => "/home/olaf/a/" )

$HTTP["remoteip"] == "127.0.0.1" {
	alias.url += ( "/doc/" => "/usr/share/doc/" )
}

alias.url += ( "/b/" => "/home/olaf/b/" )

/a/ works, /b/ doesn't (from localhost).

[moo]

it is by design. move the last alias.url to after the first one right before the condition, and it will work.

[Olaf van der Spek]

Where is this design documented? I don't think it's good design. ;)

[Olaf van der Spek]

BTW, this issue has been forwarded from Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=445459

With the split configuration Debian uses, the alias ordering isn't obvious. What does happen to /b/ though? Does it just get ignored?

[anonymous]

This might be helpful:

http://www.artificialworlds.net/blog/2007/12/09/lighttpd-on-ubuntu-aliasurl-doesnt-work-when-included-in-a-module-config-file/

Basically if you move the Debian (and Ubuntu) section that starts with:

$HTTP["remoteip"] == "127.0.0.1" {

to the end, after the line that includes the configs in conf-enabled/, it should work how you (and I) expect.

[stbuehler]

Config example:

alias.url += ( "/a/" => "/home/olaf/a/" )

$HTTP["remoteip"] == "127.0.0.1" {
	alias.url += ( "/doc/" => "/usr/share/doc/" )
}

alias.url += ( "/b/" => "/home/olaf/b/" )

Now what to expect in the conditional block?
I think it is obviously that /b/ is not the alias list, as it is added to the global list later.
The "+=" is evaluated while parsing the configfile!

But at condition checking time, all config statements get moved to the beginning of their block above the sub-blocks, i.e. we get this:

alias.url = ( "/a/" => "/home/olaf/a/", "/b/" => "/home/olaf/b/" )

$HTTP["remoteip"] == "127.0.0.1" {
	alias.url = ( "/a/" => "/home/olaf/a/", "/doc/" => "/usr/share/doc/" )
}

And the last block matching determines what happens (global block is the first one), and so localhost doesn't get /b/.

[Olaf van der Spek]

The "+=" is evaluated while parsing the configfile!

Obviously that's an implementation detail.

Now what to expect in the conditional block?

I expect both /a/ and /b/ to apply globally, including localhost/

and so localhost doesn't get /b/.

I know what the implementation does. But this is *really* not what users expect. So I do not agree with the wontfix.

[stbuehler]

If you can give a clean, consistent way to interpret the config (and of course backwards compatible), then please tell. As i don't think such way exists, i think this is a wontfix bug.
The problem here is that:

1. you can write a config that does what you want
2. someone other might want exactly what your config does.

Perhaps this will be the future: http://blog.lighttpd.net/articles/2008/02/09/weekends-projects-lua-as-config-language

Btw: I just wrote "wontfix" into the keywords, and i hope that some main developer will look at this for a final decision.
But moo already told you: It is by design

[Olaf van der Spek]

If you can give a clean, consistent way to interpret the config (and of course backwards compatible), then please tell.

I think the expectation is that ordering of aliases doesn't matter, unless multiple aliases match. In this case, only one alias matches, so ordering shouldn't matter.

someone other might want exactly what your config does.

In that case you should provide a way to disable the /b/ alias in the localhost part.

(and of course backwards compatible)

One that keeps this bug and at the same times fixes it? I don't see how that's possible.

[stbuehler]

As already said, it is by design. Perhaps their should be more documentation about how the config works (ok, it really should).

But anyway, this is not a bug (it is a feature).

[Olaf van der Spek]

As already said, it is by design.

I don't belief it. It's by implementation, and then the documentation is updated to match the implementation instead of the other way around.

[stbuehler]

Please point me to the doc where it is specified?

I am sorry that it is not documented at all (i couldn't find it), and so i don't think it's wrong to not do it the way you like (and break all existing setups).

[Olaf van der Spek]

Please point me to the doc where it is specified?

I've no idea where it's specified.

and break all existing setups

Why would it break all existing setups? It'd only break setups that depend on this undocumented behaviour that many administrators do not consider logical.

[stbuehler]

So you have no idea if it is specified and you are telling me that we would update the doc to match the implementation instead of the other way round?

And you want us to change the way the config is handled in a stable branch?
And only because a setup depends on a not documented behaviour there is no reason to break it.

And you think your judgement of what is logical rules what lighty has to do?

Sry, i think i am not going to argue with you anymore.

[Olaf van der Spek]

So you have no idea if it is specified

Right.

and you are telling me that we would update the doc to match the implementation instead of the other way round?

Right.

And you want us to change the way the config is handled in a stable branch?

Right.

And only because a setup depends on a not documented behaviour there is no reason to break it.

It's not 'only because'. It's doing what makes sense. In addition, I'm really wondering how much setups would break due to this change.

And you think your judgement of what is logical rules what lighty has to do?

No, did I say that?

[alexgirao@…]

for the record: i've lost some hours because of this "feature", i really hope that a more elegant and logical solution pops up in future releases

[jean--marc@…]

Hi everybody. I got the same problem to configure CGI module in lighttpd 1.4.13 on my Debian Etch box using the std Etch package. And running a strace on lighttpd to know what happened when I tried to run my CGI script, I found this:

stat64("/usr/lib/cgi-bin/, /usr/lib/cgi-bin/test-perl.pl", 0xbff46288) =
-1 ENOENT (No such file or directory)

So, I do not know if I am right but the first arg of stat64 should be a file including its path; and as far as I can understand it, the way it is seems to be incorrect.

So, if it is not correct and if it really comes from the config' files, it should be a bug.

P.S. sorry for my bad english and all the mistakes I made, it is the first time I post on such a Trac wiki.

[Olaf van der Spek]

You might want to try 1.4.19 from backports.

[jean--marc@…]

Olaf, I know that I speak about an old version, older than the one this ticket is linked to. But moving the so called "Debian section" to the end of the config' file solved my problem.

So, it is a little bit strange that depending on the place you put sections in your config', lighttpd changes the way it works.

Anyway, as I said, if I am wrong posting this here, just tell me.

P.S. Olaf, when you suggest to use the 1.4.19, do you mean that this version solved this kind of bugs ?

[Olaf van der Spek]

So, it is a little bit strange that depending on the place you put sections in your config', lighttpd changes the way it works.

That's by design. Lovely, isn't it? ;)

P.S. Olaf, when you suggest to use the 1.4.19, do you mean that this version solved this kind of bugs ?

No, it hasn't been fixed. Although in later Debian versions some confing related to aliases was moved to the bottom, just like you did.