https://redmine.lighttpd.net/https://redmine.lighttpd.net/favicon.ico?13667327412007-11-01T01:20:37Zlighty labsLighttpd - Bug #1427: Aliases don't work properly when combined with conditionals based on vhosthttps://redmine.lighttpd.net/issues/1427?journal_id=34762007-11-01T01:20:37Zmoo
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Fixed</i></li><li><strong>Resolution</strong> set to <i>invalid</i></li></ul><p>it is by design. move the last alias.url to after the first one right before the condition, and it will work.</p> Lighttpd - Bug #1427: Aliases don't work properly when combined with conditionals based on vhosthttps://redmine.lighttpd.net/issues/1427?journal_id=34772007-11-01T09:11:50Zadmin
<ul><li><strong>Status</strong> changed from <i>Fixed</i> to <i>Need Feedback</i></li><li><strong>Resolution</strong> deleted (<del><i>invalid</i></del>)</li></ul><p>Where is this design documented?<br />I don't think it's good design. ;)</p> Lighttpd - Bug #1427: Aliases don't work properly when combined with conditionals based on vhosthttps://redmine.lighttpd.net/issues/1427?journal_id=34782007-11-01T11:08:09Zadmin
<ul></ul><p>BTW, this issue has been forwarded from Debian: <a class="external" href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=445459">http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=445459</a></p>
<p>With the split configuration Debian uses, the alias ordering isn't obvious.<br />What does happen to /b/ though? Does it just get ignored?</p> Lighttpd - Bug #1427: Aliases don't work properly when combined with conditionals based on vhosthttps://redmine.lighttpd.net/issues/1427?journal_id=34792007-12-09T01:10:20ZAnonymous
<ul></ul><p>This might be helpful:</p>
<p><a class="external" href="http://www.artificialworlds.net/blog/2007/12/09/lighttpd-on-ubuntu-aliasurl-doesnt-work-when-included-in-a-module-config-file/">http://www.artificialworlds.net/blog/2007/12/09/lighttpd-on-ubuntu-aliasurl-doesnt-work-when-included-in-a-module-config-file/</a></p>
<p>Basically if you move the Debian (and Ubuntu) section that starts with:</p>
<pre>
$HTTP["remoteip"] == "127.0.0.1" {
</pre>
<p>to the end, after the line that includes the configs in conf-enabled/, it should work how you (and I) expect.</p> Lighttpd - Bug #1427: Aliases don't work properly when combined with conditionals based on vhosthttps://redmine.lighttpd.net/issues/1427?journal_id=34802008-02-17T22:32:51Zstbuehler
<ul></ul><p>Config example:</p>
<pre>
alias.url += ( "/a/" => "/home/olaf/a/" )
$HTTP["remoteip"] == "127.0.0.1" {
alias.url += ( "/doc/" => "/usr/share/doc/" )
}
alias.url += ( "/b/" => "/home/olaf/b/" )
</pre>
<p>Now what to expect in the conditional block?</p>
<p>I think it is obviously that /b/ is not the alias list, as it is added to the global list later.</p>
<p>The "+=" is evaluated while parsing the configfile!</p>
<p>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:</p>
<pre>
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/" )
}
</pre>
<p>And the last block matching determines what happens (global block is the first one), and so localhost doesn't get /b/.</p> Lighttpd - Bug #1427: Aliases don't work properly when combined with conditionals based on vhosthttps://redmine.lighttpd.net/issues/1427?journal_id=34812008-02-17T22:37:17Zadmin
<ul></ul><blockquote>
<p>The "+=" is evaluated while parsing the configfile!</p>
</blockquote>
<p>Obviously that's an implementation detail.</p>
<blockquote>
<p>Now what to expect in the conditional block?</p>
</blockquote>
<p>I expect both /a/ and /b/ to apply globally, including localhost/</p>
<blockquote>
<p>and so localhost doesn't get /b/.</p>
</blockquote>
<p>I know what the implementation does. But this is <strong>really</strong> not what users expect.<br />So I do not agree with the wontfix.</p> Lighttpd - Bug #1427: Aliases don't work properly when combined with conditionals based on vhosthttps://redmine.lighttpd.net/issues/1427?journal_id=34822008-02-18T00:06:58Zstbuehler
<ul></ul><p>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.</p>
The problem here is that:
<ol>
<li>you can write a config that does what you want</li>
<li>someone other might want exactly what your config does.</li>
</ol>
<p>Perhaps this will be the future:<br /><a class="external" href="http://blog.lighttpd.net/articles/2008/02/09/weekends-projects-lua-as-config-language">http://blog.lighttpd.net/articles/2008/02/09/weekends-projects-lua-as-config-language</a></p>
<p>Btw: I just wrote "wontfix" into the keywords, and i hope that some main developer will look at this for a final decision.</p>
<p>But moo already told you: It is by design</p> Lighttpd - Bug #1427: Aliases don't work properly when combined with conditionals based on vhosthttps://redmine.lighttpd.net/issues/1427?journal_id=34832008-02-18T08:01:46Zadmin
<ul></ul><blockquote>
<p>If you can give a clean, consistent way to interpret the config (and of course backwards compatible), then please tell.</p>
</blockquote>
<p>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.</p>
<blockquote>
<p>someone other might want exactly what your config does.</p>
</blockquote>
<p>In that case you should provide a way to disable the /b/ alias in the localhost part.</p>
<blockquote>
<p>(and of course backwards compatible)</p>
</blockquote>
<p>One that keeps this bug and at the same times fixes it? I don't see how that's possible.</p> Lighttpd - Bug #1427: Aliases don't work properly when combined with conditionals based on vhosthttps://redmine.lighttpd.net/issues/1427?journal_id=34842008-03-01T14:44:27Zstbuehler
<ul><li><strong>Status</strong> changed from <i>Need Feedback</i> to <i>Fixed</i></li><li><strong>Resolution</strong> set to <i>invalid</i></li></ul><p>As already said, it is by design. Perhaps their should be more documentation about how the config works (ok, it really should).</p>
<p>But anyway, this is not a bug (it is a feature^^).</p> Lighttpd - Bug #1427: Aliases don't work properly when combined with conditionals based on vhosthttps://redmine.lighttpd.net/issues/1427?journal_id=34852008-03-01T14:46:45Zadmin
<ul></ul><blockquote>
<p>As already said, it is by design.</p>
</blockquote>
<p>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.</p> Lighttpd - Bug #1427: Aliases don't work properly when combined with conditionals based on vhosthttps://redmine.lighttpd.net/issues/1427?journal_id=34862008-03-01T15:22:16Zstbuehler
<ul></ul><p>Please point me to the doc where it is specified?</p>
<p>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).</p> Lighttpd - Bug #1427: Aliases don't work properly when combined with conditionals based on vhosthttps://redmine.lighttpd.net/issues/1427?journal_id=34872008-03-01T15:29:58Zadmin
<ul></ul><blockquote>
<p>Please point me to the doc where it is specified?</p>
</blockquote>
<p>I've no idea where it's specified.</p>
<blockquote>
<p>and break all existing setups</p>
</blockquote>
<p>Why would it break all existing setups?<br />It'd only break setups that depend on this undocumented behaviour that many administrators do not consider logical.</p> Lighttpd - Bug #1427: Aliases don't work properly when combined with conditionals based on vhosthttps://redmine.lighttpd.net/issues/1427?journal_id=34882008-03-01T15:51:40Zstbuehler
<ul></ul><p>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?</p>
<p>And you want us to change the way the config is handled in a <strong>stable</strong> branch?</p>
<p>And only because a setup depends on a not documented behaviour there is <strong>no</strong> reason to break it.</p>
<p>And you think your judgement of what is logical rules what lighty has to do?</p>
<p>Sry, i think i am not going to argue with you anymore.</p> Lighttpd - Bug #1427: Aliases don't work properly when combined with conditionals based on vhosthttps://redmine.lighttpd.net/issues/1427?journal_id=34892008-03-01T16:08:56Zadmin
<ul></ul><blockquote>
<p>So you have no idea if it is specified</p>
</blockquote>
<p>Right.</p>
<blockquote>
<p>and you are telling me that we would update the doc to match the implementation instead of the other way round?</p>
</blockquote>
<p>Right.</p>
<blockquote>
<p>And you want us to change the way the config is handled in a stable branch?</p>
</blockquote>
<p>Right.</p>
<blockquote>
<p>And only because a setup depends on a not documented behaviour there is no reason to break it.</p>
</blockquote>
<p>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.</p>
<blockquote>
<p>And you think your judgement of what is logical rules what lighty has to do?</p>
</blockquote>
<p>No, did I say that?</p> Lighttpd - Bug #1427: Aliases don't work properly when combined with conditionals based on vhosthttps://redmine.lighttpd.net/issues/1427?journal_id=34902008-03-06T12:53:10ZAnonymous
<ul></ul><p>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</p>
<p>-- alexgirao</p> Lighttpd - Bug #1427: Aliases don't work properly when combined with conditionals based on vhosthttps://redmine.lighttpd.net/issues/1427?journal_id=34912008-04-16T21:05:37ZAnonymous
<ul></ul><p>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:</p>
<pre>
stat64("/usr/lib/cgi-bin/, /usr/lib/cgi-bin/test-perl.pl", 0xbff46288) =
-1 ENOENT (No such file or directory)
</pre>
<p>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.</p>
<p>So, if it is not correct and if it really comes from the config' files, it should be a bug.</p>
<p>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.</p>
<p>-- jean--marc</p> Lighttpd - Bug #1427: Aliases don't work properly when combined with conditionals based on vhosthttps://redmine.lighttpd.net/issues/1427?journal_id=34922008-04-16T21:19:37Zadmin
<ul></ul><p>You might want to try 1.4.19 from backports.</p> Lighttpd - Bug #1427: Aliases don't work properly when combined with conditionals based on vhosthttps://redmine.lighttpd.net/issues/1427?journal_id=34932008-04-16T21:34:31ZAnonymous
<ul></ul><p>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.</p>
<p>So, it is a little bit strange that depending on the place you put sections in your config', lighttpd changes the way it works.</p>
<p>Anyway, as I said, if I am wrong posting this here, just tell me.</p>
<p>P.S. Olaf, when you suggest to use the 1.4.19, do you mean that this version solved this kind of bugs ?</p>
<p>-- jean--marc</p> Lighttpd - Bug #1427: Aliases don't work properly when combined with conditionals based on vhosthttps://redmine.lighttpd.net/issues/1427?journal_id=34942008-04-16T21:40:09Zadmin
<ul></ul><blockquote>
<p>So, it is a little bit strange that depending on the place you put sections in your config', lighttpd changes the way it works.</p>
</blockquote>
<p>That's by design. Lovely, isn't it? ;)</p>
<blockquote>
<p>P.S. Olaf, when you suggest to use the 1.4.19, do you mean that this version solved this kind of bugs ?</p>
</blockquote>
<p>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.</p> Lighttpd - Bug #1427: Aliases don't work properly when combined with conditionals based on vhosthttps://redmine.lighttpd.net/issues/1427?journal_id=46432008-10-10T18:54:19Zstbuehler
<ul><li><strong>Status</strong> changed from <i>Fixed</i> to <i>Invalid</i></li></ul>