Route assessment based on pathname but doesn't take into account html name

[jhchill666]

Firstly, this issue exhibits when running [email protected] with [email protected].

When setting a routing basename via useBasename() I'm experiencing issues if the html file isn't named as per the server default.

For example, if running an app at http://localhost, setting the base as / works as expected. This is also true of any other server context ie. http://localhost/my-app with base /my-app.

But if my index file is renamed to something other than the expected server default, ie. if the html file name is present in the address bar, the router fails to instantiate the appropriate route components.

http://localhost/someIndex.html now silently fails, displaying a blank screen.

It appears that the route matching looks at window.location.pathname to assess whether a route is a match, and in this case the pathname of /someIndex.html, fails to match the base set as /.

createHistory.js

function locationsAreEqual(a, b) {
  return a.pathname === b.pathname &&
    a.search === b.search &&
    //a.action === b.action && // Different action !== location change.
    a.key === b.key &&
    deepEqual(a.state, b.state)
}

The pathnames are assessed using strict equals, so '/' with not match '/someIndex.html'

To confirm this ambiguity, if I now set the base to /someIndex.html or /my-app/someIndex.html, things work as expected.

I would have expected the route matching to disregard the name of the underlying html, when matching routes.

I know it's a fairly unusual use case, to even have the html filename in the address bar, but unfortunately, is beyond my control, due to client requirements.

NB// I am using the html element to dynamically set the base for useBasename, although this doesn't seem to be pertinent to the problem.

[taion]

I don't think that's right. For example, I have a site where the routes actually are e.g. /foo.html and /bar.html for legacy reasons.