TIWServerController::URLBase

[JuergenS]

I am using HTTP.SYS with URL reservation.

I found the following in the ATOZED documentation:

URLBase: string; [Published, Read/Write]

URLBase is the common prefix found while navigating inside a given website is known as the base URL.
The URLBase is concatenated with the server's root URL to form the application URL.
Example: server URL is www.yourserver.com and application URLBase is /myapp/, the application root url will be http(s)://www.yourserver.com/mypp/

I keep getting complaints from users getting the "Resource not found on server (error 404)" error because they're just not used to typing the slash at the end.

Even if I just use myapp instead of /myapp/ for URLBase, the slash has to be specified at the end.

Is there a way to omit the trailing slash?


Regards
JuergenS

[Alexandre Machado]

Hi,

I believe you are correct. Regardless of registering with or without the trailing slash, it should behave the same.

Usually this is handled by a root content handler (or a specific one registered for the URL base). But we'll add some code to handle this specific situation in the next release.

However, the trailing slash will be kept (the users don't need to type it but the application will handle it transparently)

Cheers

[JuergenS]

Unfortunately the change in IW15.2.63 wasn't that good.

It works when a URL is entered interactively via the keyboard and the URLBase matches exactly.
However, the URLBase seems to be treated case-sensitive internally, which probably shouldn't be the case.

It does not work if the URL is pasted externally, for example via a password manager or from an automatically saved browser link.


Regards
JuergenS

[Alexandre Machado]

Strictly speaking, I'm afraid that it should.

Please notice that Linux internet servers are - by default - case sensitive regarding to URLs (this exact forum won't respond to https://www.atozed.com/FORUMS/ but will respond to https://www.atozed.com/forums/), and this is what W3C has to say about it:

From: https://www.w3.org/TR/WD-html40-970708/htmlweb.html

There may be URLs, or parts of URLs, where case doesn't matter, but identifying these may not be easy. Users should always consider that URLs are case-sensitive

I know that IW has been historically case insensitive regarding to URLs but don't expect the rest of the internet to behave like this (for example, any proxy server, load balancer or reverse proxy can mess with your application if you rely on this).


In your case, I don't think that a history link will contain the incorrect string case, unless the user types it incorrectly. If your UrlBase is "/UrlBase/" Even if you type https://yourdomain.com/URLBASE/ IntraWeb will set the address correctly in the fist response (i.e. it will become https://www.yourdomain.com/UrlBase/), and there is  no way the user can save a wrong URL from the actual page. Also, I find strange that any password manager will mess with the case of saved URLs knowing that by default most Internet servers out there are case sensitive...

Anyway, I'll make sure that it will redirect to the correct URLBase in any case.

[Alexandre Machado]

Please update to https://www.atozed.com/2022/07/intraweb-15-2-64/

Cheers

[JuergenS]

You're absolutely right, but if I type https://www.w3.org/tr it works too

Carrying out the URLBase check in IW in a case insensitive manner is certainly a good decision.

In relation to saved links, I must have expressed myself a little unclearly:

Password managers themselves do not cause a problem because everyone determines for themselves how a URL is saved in the context of a password entry in the password manager.

URL reservation is an extension to HTTP.SYS that makes it possible to run multiple web servers or web services over the same port.
For a user, however, this is transparent, he is used to calling up a website without an trailing slash.

When entering a URL with URL reservation manually in the browser, the slash is automatically added at the end in some browsers and thus stored in the history.
With other browsers, however, the slash is not automatically added at the end and the URL is stored in the history as specified.
This can lead to the URL being called sometimes with and sometimes without a slash at the end.

It is not clear to me whether the automatic addition of the slash at the end is a function of IW or the respective browser.