HttpListner path info is case sensitive

ServiceStack Self Hosting
1

Hi,

In latest version the path’s defined in baseaddress’s are case sensitive, previous versions that wasn’t the case. For example in latest version http://localhost/TestSite/swagger-ui only works if TestSite is exact case, in previous version it used to work either way.

2

Following commit may be the issue

3

That commit is old, we’ve removed WebHostRootFileNames top-level caching completely which was inconsistent across different hosts/OS and Debug/Release mode and prevented being able to resolve new files added to the top-level directory.

What’s url are you listening on for the Self Host? and what’s your HostConfig?

4

Only url we’re listening on is http://localhost/TestSite/

What do you mean by HostConfig? All I did is upgraded to new version this morning and I have this issue. So the issue clearly is related to path being case sensitive.

5 
            new HostConfig
            {
                ApiVersion = "6.0",
                DefaultRedirectPath = "/#/auth/login",
                AllowJsonpRequests = true,
                AllowFileExtensions = { "json" },
                ReturnsInnerException = true,
                StripApplicationVirtualPath = true,
                WebHostPhysicalPath = "~".MapServerPath() + "/dist/",

#if DEBUG
                DebugMode = true,
#else
                DebugMode = false
#endif
6

If the url you’re listening on includes the virtual path, i.e. http://localhost/TestSite/ then that should definitely be case-sensitive, I’m surprised it accepted requests without an exact match. We should only be supporting case-insensitive requestes for files/folders on Windows.

7

is it possible to listen on both localhost/TestSite and localhost/testsite? It is an issue for us as this will be a breaking change for our customers and hard to explain that why all of a sudden they have to type the path in case sensitive manner. Also people may have bookmarks that will stop working.

8

It’s unfortunate you’re using a different url to the one specified, that’s never going to work reliably across different hosts.

I’m surprised ServiceStack is receiving the request, if it is you can try redirecting to the registered URL:

SetConfig(new HostConfig { 
    RedirectPaths = {
        { "/testsite/", "/TestSite/" },
    }
})

But it really shouldn’t work as ServiceStack shouldn’t be receiving the request.

Something that might is overriding which PathInfo is resolved in your AppHost:

public override string ResolvePathInfo(IRequest request, string originalPathInfo, out bool isDirectory) =>
    base.ResolvePathInfo(request, originalPathInfo.Replace("/testsite","/TestSite"), out isDirectory);
9

That doesn’t work very reliably. I will be downgrading to previous version until this is resolved. My biggest concern is that this used to work just fine in previous stable build and in this build it doesn’t. We can’t deal with breaking changes like this ongoing basis.

10

Breaking changes aren’t good but it was never intended that the listening url accept anything other than what was specified. It doesn’t work consistently across hosts and it shouldn’t be expected to. It’s unfortunate it accidentally worked before and that you relied on that behavior, but we don’t want to add custom logic to support inconsistent behavior across different hosts. Changes made in the last release was to use as much of the same code-path as possible and to ensure consistent behavior across hosts.

I’ll see if there’s some override, but restoring inconsistent behavior for specific hosts isn’t an issue that needs resolving.

What are some urls that’s not working with:

public override string ResolvePathInfo(IRequest request, string originalPathInfo, out bool isDirectory) =>
    base.ResolvePathInfo(request, originalPathInfo.Replace("/testsite","/TestSite"), out isDirectory);

This works with http://localhost/testsite/swagger-ui/ which I’ve just checked in this commit.