• Do not register here on develop.twiki.org, login with your twiki.org account. • Use Item7848 for generic doc work for TWiki-6.1.1. Use Item7851 for doc work on extensions that are not part of a release. More...Close• Anything you create or change in standard webs (Main, TWiki, Sandbox etc) will be automatically reverted on every SVN update. • Does this site look broken?. Use the LitterTray web for test cases.

Item5382: TWiki.pm sets wrong urlHost if https protocol and ShorterUrlCookbook is used

Item Form Data

AppliesTo:

Component:

Priority:

CurrentState:

WaitingFor:

TargetRelease

ReleasedIn

Engine

TWiki.pm

Urgent

Closed

patch

4.2.1, 5.0.0

Edit Form Data

Summary:

Reported By:

Codebase:

~twiki4

6.0.2

6.0.0

5.1.3

5.1.1

5.0.2

5.0.0

4.3.1

4.2.4

4.2.2

4.2.0

4.1.1

4.0.5

4.0.3

4.0.1

6.1.0

6.0.1

5.1.4

5.1.2

5.1.0

5.0.1

4.3.2

4.3.0

4.2.3

4.2.1

4.1.2

4.1.0

4.0.4

4.0.2

4.0.0

Applies To:

Component:

Priority:

Current State:

Waiting For:

Target Release:

n/a

major

minor

patch

Released In:

6.1.1

6.0.1

5.1.3

5.1.0

5.0.0

4.3.0

4.2.3

4.2.0

4.1.1

4.0.4

4.0.1

6.1.0

6.0.0

5.1.2

5.0.2

4.3.2

4.2.5

4.2.2

4.1.3

4.1.0

4.0.3

4.0.0

6.0.2

5.1.4

5.1.1

5.0.1

4.3.1

4.2.4

4.2.1

4.1.2

4.0.5

4.0.2

Detail

Description of the problem

Suppose you have an Apache configuration allowing both http and https connects to your TWiki and you have a DefaultUrlHost like http://www.example.com. (means default is http if not specified).

and your view URLs look like: http://www.example.com/Web/Topic or (and that's the important case for this bug) https://www.example.com/Web/Topic then you have problem in the second case (https case) because all links (that TWiki shows on the page) have the DefaultUrlHost prepended with http and not https!

Why?

Taking a look at TWiki.pm in the constructor (sub new) where urlHost is set, then we see

If your view script gets called with https://www.example.com/Web/Topic, then url in this case is https://www.example.comwithout a trailing slash. Hence the regexp doesn't match (one slash after the two slashes of protocol:// is required; and even if there were a trailing slash $2 would be empty).

Then you have the wrong urlHost and especially all created links point to http://www.example.com/... and not https://www.example.com/...

-In the case, the line my $url = $query->url(); sets value to $url = http://www.example.com (it does not set to https://www.example.com or does not set to https://www.example.com/Main/WebHome), so it does not go through if( $url && $url =~ m!^([^:]*://[^/]*)(.*)/.*$! && $2 ), it goes via else { $this->{urlHost} = $TWiki::cfg{DefaultUrlHost}; } loop

So $this->{urlHost} gets the value $TWiki::cfg{DefaultUrlHost} which is http://www.example.com

So all links from the page/topic have links starting with http:// protocol and not with https://

Because of the if … elseif … else construction there are now two completely different branches handling URLs. In the second branch (elsif) the RemovePortNumber config variable and the GetScriptUrlFromCGI config variable are both ignored and there is no localhost test.

Perhaps it's better to think about fixing the first regular expression (in the if) instead of opening more branches. But for fixing the reg exp some hints are needed what this reg exp should match and what not.

its actually better to use the url processing CPAN library - i didn't when I last poked the url parsing code because we try to avoid external dependancies, but I suspect it'd be safer to do so - perhaps by including a copy of the .pm in the release.

Christian for sure understood at that low level what the code is doing.

Take a step back and tell us what the code is supposed to do

As Christian writes: "I know this bug is now four month old, but I cannot suggest a patch, because I do not know the intention of the code"

What is the intention of the code? Even with a CPAN call you can get into trouble if you use it for the wrong purpose. And even without knowing the original intention exactly - for sure we are not going to force a new CPAN dependency of a lib that has to be installed just to perform such a simple little task. It is difficult for people using shared hosting to get the admins to install CPAN libs and for sure this one can be resolved with the right regex.

Humm... since when state is "Being worked on" the "Waiting for" field have information about who is working, I thought (when I saw Item4824 at RecentlyClosed) that this field should have the name of people that fixed the bug when state was "Waiting for Release". Now that I read instructions more carefully, I realized that I was using somethings in a wrong way... it's always nice to read

However I still have a question (that I didn't find the answer within docs): a bug on TWikiRelease04x02 implies on ticking "4.2.1" at Codebases form field?

And I think there is a pending issue: TWiki:Main.SopanShewale said he would test the fix and would also update unit tests. In this case should he open a new report or should we set state to "Waiting for Feedback" on Sopan (or keep "Being worked on")?

Gilmar, the normal procedure for a report to remain in "Being Worked on" with a name in the "Waiting For" field until the bug is fixed and unit tests pass. There should be no need to open a new report for unit test fixes. Once the report is "Waiting for Release" or "Closed" there is no need for a name in "Waiting For". The main purpose of the "Waiting For" field is to generate reminder emails for the person being waited on.