#2485 An extra /src is added to the links with lighttpd

closed
nobody
None
5
2008-02-14
2007-06-22
Daniel Bainton
No

1.4.10 introduced this bug when using Lighttpd. 1.4.9a works fine. Works fine with Apache2 too.

An extra /src is added to some of the links, including the links on the top (Compose, Addresses, Folders, Options, Search, Help).

Discussion

  • Logged In: YES
    user_id=285765
    Originator: NO

    Can you check the detected base_uri as output by the src/configtest.php script?

     
  • Daniel Bainton
    Daniel Bainton
    2007-06-26

    Logged In: YES
    user_id=893475
    Originator: YES

    1.4.9a shows "http://www.domain.com/webmail/src" and 1.4.10a shows just "http://www.domain.com"

     
  • Logged In: YES
    user_id=285765
    Originator: NO

    Have you set the base URI setting in conf.pl / config.php?

     
  • Daniel Bainton
    Daniel Bainton
    2007-06-29

    Logged In: YES
    user_id=893475
    Originator: YES

    No, I haven't.

    The same exact settings work fine with 1.4.10a with Apache2 and 1.4.9a with Lighttpd, but not with 1.4.10a with Lighttpd.

     
  • Logged In: YES
    user_id=29895
    Originator: NO

    I'm seeing this as well. My base_uri is autodetected to https://webmail.domain.net (as it should be).

    All links work except the ones on the top. For some reason makeInternalLink is giving a $base_uri of https://webmail.domain.net/src/, which causes the duplicate.

    Plugins (Calendar in my case) in the same area don't exhibit the same issue.

     
  • Logged In: YES
    user_id=508228
    Originator: NO

    No, actually, your base_uri I believe should be detecting the /src part of the path too, but I think this problem is unrelated to the get_location() function and $config_location_base...

    In functions/strings.php, find the sqm_baseuri() function (immediately above get_location(), around line 251) and put an echo statement in there right after the global statement:

    echo "PHP SELF IS $PHP_SELF<hr />";

    Your web server may not be providing PHP_SELF....? If this does not output something like:

    PHP SELF IS /webmail/src/right_main.php?PG_SHOWALL=0&sort=0&startMessage=1&mailbox=INBOX

    Then you'll want to go to the php_self() function which is also in functions/strings.php, near line 218. At the top of that function, you can dump out the values used therein:

    echo "_SERVER[PHP_SELF] IS: " . $_SERVER['PHP_SELF'] . "<br />_SERVER[QUERY_STRING] IS: " . $_SERVER['QUERY_STRING'] . "<hr />";

    If you get nothing out of PHP_SELF, this could be the problem (if it's not found, we use an empty string for $PHP_SELF). Please then show the output of this:

    sm_print_r($_SERVER);

    You can put this in the php_self() function and it should output all relevant request environment variables provided by PHP/your web server.

    However, what is curious to me is that llarian reports that his SM runs out of https://webmail.domain.net, in which case an empty $PHP_SELF (thus an empty $base_uri when constructing menu links) should provide the correct links. Perhaps his problem is not the same as the OP. The OP runs off of http://www.domain.com/webmail and so if $base_uri is empty, this is probably why it is breaking..... er, but the problem I perceive here is that with an empty $base_uri, you get links without "/webmail" in them. I'm not sure how you'd get an extra /src in there. Please post some of the information I have asked for and this may shed more light on the situation.

     
  • Logged In: YES
    user_id=1020419
    Originator: NO

    Changing status to pending after a reply from a developer.

     
    • status: open --> pending
     
  • Logged In: YES
    user_id=508228
    Originator: NO

    Should we really be changing to pending so fast? Given how speedy we are at replying to some of these trackers.... And even if the OP does not respond does not always mean the issue went away or was invalid - someone else might have the same problem (although they can file another report if so). OTOH, I don't like trackers that hang around w/out any responses, so I'll bow to your decision on how to manage them.

     
    • status: pending --> closed
     
  • Logged In: YES
    user_id=1312539
    Originator: NO

    This Tracker item was closed automatically by the system. It was
    previously set to a Pending status, and the original submitter
    did not respond within 14 days (the time period specified by
    the administrator of this Tracker).

     
  • Note that someone else finally was helpful enough to follow up. A patch has been proposed here:

    http://marc.info/?t=119192393900002&r=1&w=2

    This patch may very well show up in SquirrelMail version 1.4.20 or 1.4.21