Project

General

Profile

Bug #1427

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

Added by admin over 11 years ago. Updated over 10 years ago.

Status:
Invalid
Priority:
Normal
Assignee:
-
Category:
mod_alias
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Missing in 1.5.x:

Description


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).

History

#1

Updated by moo over 11 years ago

  • Status changed from New to Fixed
  • Resolution set to invalid

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

#2

Updated by admin over 11 years ago

  • Status changed from Fixed to Need Feedback
  • Resolution deleted (invalid)

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

#3

Updated by admin over 11 years ago

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?

#4

Updated by Anonymous over 11 years ago

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.

#5

Updated by stbuehler over 11 years ago

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/.

#6

Updated by admin over 11 years ago

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.

#7

Updated by stbuehler over 11 years ago

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

#8

Updated by admin over 11 years ago

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.

#9

Updated by stbuehler over 11 years ago

  • Status changed from Need Feedback to Fixed
  • Resolution set to invalid

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^^).

#10

Updated by admin over 11 years ago

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.

#11

Updated by stbuehler over 11 years ago

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).

#12

Updated by admin over 11 years ago

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.

#13

Updated by stbuehler over 11 years ago

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.

#14

Updated by admin over 11 years ago

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?

#15

Updated by Anonymous over 11 years ago

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

-- alexgirao

#16

Updated by Anonymous about 11 years ago

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.

-- jean--marc

#17

Updated by admin about 11 years ago

You might want to try 1.4.19 from backports.

#18

Updated by Anonymous about 11 years ago

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 ?

-- jean--marc

#19

Updated by admin about 11 years ago

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.

#20

Updated by stbuehler over 10 years ago

  • Status changed from Fixed to Invalid

Also available in: Atom