At our site, we are setting up TWiki behind a firewall, which requires us to use relative URLs. Otherwise, a user outside would connect to e.g. https://firewall.our-site.co.uk/twiki/bin..., but the URLs pointing to other pages would look something like http://twikiserver.our-site.co.uk/twiki/bin...

So, I've changed the lines "my $theUrl ..." in most of the scripts to read "my $theUrl = $query->url(-relative=>1);"

Beware: I don't know much perl, so this is strictly cookbook stuff. It works for me in our environment, though. Also, this simply changes things always to use relative URLs; if anyone has a need for absolute URLs this will mess them up. Maybe it should be configurable?

-- PeterGreenwood - 02 Jun 2000

twikidiffs (Context diff of code changes.)

---

There must be a way to config this at install, and if there isn't there certainly should be! I'm going to switch this topic to FeatureEnhancementRequest -- this goes to the heart of TWikiOnIntranets.

-- KevinKinnell - 04 Jun 2000

---

I am not exactly sure I understand what you need to accomplish.

1. Does TWiki need to return the URL host entered? Example: User enters URL host firewall.our-site.co.uk and TWiki should return links with host firewall.our-site.co.uk User enters URL host twikiserver.our-site.co.uk and TWiki should return links with host twikiserver.our-site.co.uk

2. Does TWiki need to return the identical URL host regardless of the URL host used? Example: User enters URL host firewall.our-site.co.uk and TWiki should return links with host twikiserver.our-site.co.uk User enters URL host twikiserver.our-site.co.uk and TWiki should return links with host twikiserver.our-site.co.uk .

Unless I'm completely misreading this, PeterGreenwood is setting up the TWiki behind the firewall but wants external users to have access to it. The problem is that url's on the inside look different than those on the outside -- for the same pages. -- KevinKinnell - 06 Jun 2000 This is it. This is not it.

-- PeterThoeny - 06 Jun 2000

---

Why is there a need for TWiki to return "absolute" (i.e. with host) urls at all? Can't the client (e.g. browser) do the job of expanding relative to full urls itself? Couldn't TWiki just return /twiki/bin/view or /twiki/pub/... instead of http://foo.com/twiki/bin/view ?

Wouldn't wikicfg.pm:$defaultUrlHost=""; work? (normally it says "http://foo.com")

I'm asking because I've been thinking about using http: and https: with the same URLs myself to give different access (edit) or visibility rights (web) -- see UserAuthorizationSchemes for hints on this latter topic.

-- JoergHoehle - 23 Aug 2000

---

There are certain places where an absolute URL is required for some environments, i.e. the PageRedirectionNotWorking problem. TWiki could be tweaked to get the server name from the environment ( HTTP_HOST ) , e.g. at run-time. That would solve the problem of accessing the same TWiki with different host names. Not sure if it is possible to get the protocol ( http: or https: )at run-time. Anybody knows?

One thing to consider is that some TWiki scripts (like mailnotify or statistics ) are called from the shell. Those scripts need the protocol and host name "hard coded" as it is now. BTW, the statistics script can be run from the shell as well as a cgi script, it figures that out at run-time.

-- PeterThoeny - 29 Aug 2000

As far as getting the protocol at runtime...I'm pretty sure for apache at least that when using https a whole host of SSL_BLAH_BLAH environment variables get set up for you. You could check for the presence of these to autodetect the protocol if there's no more direct way to do it. Not sure how much this matters, since this page seems to have been abandoned >2 years ago, but there it is.

-- WalterMundt - 08 Jan 2003

I also had to solve the same problem as Peter Greenwood. Here is what I did: 1. Edit the templates to remove the tag 2. Edit the TWiki.pm not to use $urlHost By these changes all URLs become relative. The only problem is the email notification. The links in the email notification dont know where to go.

-- GokulmuthuNarayanaswamy - 16 Aug 2004

There is at least one other reason relative URLs are problematic; many templates contain TWiki code similar to:

[[%SCRIPTURL%/view%SCRIPTSUFFIX%/%WEB%/%TOPIC%][View]]

If %SCRIPTURL% expands to a relative URL /foo/bar/baz then [[/foo/bar/baz][some link text]] breaks; it looks like this: some link text rather than like this: some link text.

This is exactly the problem described in NoRelativeSupportInArbitraryTextForWikiWordLinks.

At our site we have a scenario requiring RelativeURLs which is more complex than the firewall / twikiserver one above: we have a central intranet web cluster service which delegates requests to various content providers, one of which is the twiki server. So the twiki server receives the URL ( $theUrl in the code) as a URI whose protocol/host/port segment is entirely different to the segment the client browser requests. This is akin to Apache's ProxyPass directive. Not only that, but we also cater for requests going directly to the TWiki server, i.e. bypassing the central web cluster delegation, and requests going directly are under a different authentication domain to those going via the central cluster. To accomplish this we had to change $scriptUrlPath, $dispScriptUrlPath, and $pubUrlPath per hit in TWiki::initialize().

-- AdamSpiers - 13 Apr 2005

One of our users just noticed another issue with RelativeURLs: the tweak stops auto-rendering of image URLs. This is a simple matter of tweaking a regexp; here's the patch: auto-render-images.patch.

It will presumably also break auto-linking of %SCRIPTURLPATH% URLs, although the above patch doesn't bother addressing that.

However, after a discussion with CrawfordCurrie, I'm wondering whether the way we're changing $scriptUrlPath etc. to be RelativeURLs is really the best way of going about things, as certain bits of code (WysiwygPlugin for instance) rely on %PUBURL% being an absolute URI not relative. Maybe out-of-band post-processing is a cleaner, more general approach. Possible ways of achieving that:

• write a new late mod_perl handler - undesirable since couples the solution to mod_perl
• write a RelativeURLsPlugin - is endRenderingHandler the right one?

Given that we want to move to SpeedyCGI, I like the sound of the latter.

-- AdamSpiers - 01 Jun 2005

I really don't think out-of-band processing would achieve anything. Generally I don't think using relative URLs is a good idea:

• they break plugins that parse absolute URLs,
• they (potentially) break scripts that rely on getting a URL base from the code (mailnotify etc)

I don't really understand why you need relative URLs. The only thing the URL in the CGI query is used for is determining the urlHost. This in turn is used in generating new URLs. You can easily override this behaviour to normalise the $urlHost to the same as given in $scriptUrlPath. Conversely you can override the host specified in the $scriptUrlPath with the host from the request (the firewall example, given above). As long as this is done consistently, the parsing rules in plugins should work, unless the host actually differs for every single request, which seems a bit unlikely.

-- CrawfordCurrie - 02 Jun 2005

Please read the above explanation of our environment which refers to the use of multiple central webservers which proxy through requests to multiple TWiki servers via multiple authentication realms (where the realm is determined by the first segment of the URL path immediately following the host:port/ bit) all with the same backend code and data (shared via NFS). As a result of all these combinations, there is no single value for $urlHost which would satisfactorily work everywhere, therefore we have to determine its value per hit.

However, the TWiki code has no way of determining the original URL which was typed into the browser, because it receives the HTTP request from the proxy, not from the client direct. Therefore the normal $doGetScriptUrlFromCgi code for determining $scriptUrlPath and $urlHost will not work because they rely on the results of CGI::url(), which rely on $ENV{HTTP_HOST} (or if that doesn't exist, $ENV{SERVER_NAME} and $ENV{SERVER_PORT}).

Example scenario 1:

Client accesses the TWiki from home via one of the external proxies facing the internet. $doGetScriptUrlFromCgi is 1.

URL in browser	http://external3.company.com/TWK/bin/view/TWiki/WebHome
URL of proxied HTTP request	http://twiki-2.intranet.our.company.com/TWK/bin/view/TWiki/WebHome
$ENV{HTTP_HOST}	twiki-2.intranet.our.company.com:80
Resulting $urlHost	twiki-2.intranet.our.company.com:80
Resulting %SCRIPTURL%	http://twiki-2.intranet.our.company.com/TWK/bin/ - WRONG
Required %SCRIPTURL%	http://external3.company.com/TWK/bin/

Example scenario 2:

Client accesses the TWiki from the office via one of the internal proxies on the intranet. $doGetScriptUrlFromCgi is 1.

URL in browser	http://internal.company.com/TWK/bin/view/TWiki/WebHome
URL of proxied HTTP request	http://twiki-3.intranet.our.company.com/TWK/bin/view/TWiki/WebHome
$ENV{HTTP_HOST}	twiki-3.intranet.our.company.com:80
Resulting $urlHost	twiki-3.intranet.our.company.com:80
Resulting %SCRIPTURL%	http://twiki-3.intranet.our.company.com/TWK/bin/ - WRONG
Required %SCRIPTURL%	http://internal.company.com/TWK/bin/

Example scenario 3:

Client accesses the TWiki web server directly from the office. $doGetScriptUrlFromCgi is 1. Note that the /TWK path segment has gone, because a different authentication realm is in use.

URL in browser	http://twiki.intranet.company.com/bin/view/TWiki/WebHome
URL of proxied HTTP request	n/a - no proxy
$ENV{HTTP_HOST}	twiki.intranet.our.company.com:80
Resulting $urlHost	twiki.intranet.our.company.com:80
Resulting %SCRIPTURL%	http://twiki.intranet.our.company.com/bin/
Required %SCRIPTURL%	http://twiki.intranet.our.company.com/bin/

Only in scenario 3 did the code get the right %SCRIPTURL% and have the correct links in the resulting page.

Now, I take back my earlier comment that "the TWiki code has no way of determining the original URL which was typed into the browser" - fortunately our proxies do pass through a custom header which appears in the TWiki process's CGI environment, providing TWiki with the name of the proxy server the request was originally sent to by the client (assuming it went through a proxy at all). Therefore it sounds like the best approach is to tweak TWiki.pm to dynamically construct absolute URLs using the value of this variable, and this will avoid the need to tweak other code which relies on there being absolute URLs. Would you agree this is the best method?

-- AdamSpiers - 09 Jun 2005

Update: I'm now actually rewriting the $SERVER_NAME and $HTTP_HOST environment variables each hit, by frobbing with the %{"CGI::"} symbol table in order to wrap CGI::init() with my own routine. This catches any plugins (e.g. TablePlugin) which use code like $query->url. I also modify the $urlHost, $pubUrl etc. variables per hit via the initializeUserHandler() handler of a custom plugin. By luck, that handler gets run at just the right time - early enough to catch what we need, but not so early that it precedes the native TWiki.pm code which already tweaks it (in a manner depending on the values of $doGetScriptUrlFromCgi and $doRemovePortNumber).

This keeps core code changes to a minimum, which hopefully reduces maintenance overheads (e.g. during upgrades).

-- AdamSpiers - 12 Sep 2005

Adam, could you be so kind to post a patch for the RelativeURLs as you described in the above post? I expect usage to be fully automatic?

Thanks!

-- TWikiGuest - 26 Sep 2008