You are here: Foswiki>Tasks Web>Item14996 (28 Mar 2022, MichaelDaum)Edit Attach

Item14996: wrong url host if foswiki called via localhost

Priority: Urgent
Current State: Closed
Released In: 2.1.7
Target Release: patch
Applies To: Engine
Branches: Release02x01 master
Reported By: MichaelDaum
Waiting For:
Last Change By: MichaelDaum
When running a Foswiki on https://localhost that has got a different non-localhost DefaultUrlHost then the urlHost gets botched for no good reason.


$Foswik::cfg{DefaultUrlHost} = 'https://intranet',

Then access the site via https://localhost - given the intranet is on localhost (don't ask why). The desired outcome is that all %SCRITPURLs are set to https://localhost. However there is a special treatment of the situation:

  • DefaultUrlHost differes from the one in the request
  • protocol equals the request
  • then rewrite the urlHost to the one configured in DefaultUrlHost ...

The questionable code in

        # If the urlHost in the url is localhost, this is a lot less
        # useful than the default url host. This is because new CGI("")
        # assigns this host by default - it's a default setting, used
        # when there is nothing better available.
        if ( $this->{urlHost} =~ m/^(https?:\/\/)localhost$/i ) {
            my $protocol = $1;

#only replace localhost _if_ the protocol matches the one specified in the DefaultUrlHost
            if ( $Foswiki::cfg{DefaultUrlHost} =~ m/^$protocol/i ) {
                $this->{urlHost} = $Foswiki::cfg{DefaultUrlHost};

This is bs imho, nor can I find a clear bug report. My git blame skills are missing probably as this code has been moved around a lot during the ages.

I'd suggest to remove this particular exception all together. If there once was a bug being triggered in CGI then maybe it comes back and we can deal with it again. But until then, this code hurts (in my eyes) more than it helps.

-- MichaelDaum - 09 Dec 2020

Related comments in Item10669 seem to share the impression that the url rewrite happening here is ... horrible.

-- MichaelDaum - 10 Dec 2020
Topic revision: r4 - 28 Mar 2022, MichaelDaum
The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy