How to handle sub-directory base URLs

[amitaibu]

Assuming:

delta2url : Model -> Model -> Maybe UrlChange
delta2url previous current =
    case current.activePage of
        Login ->
            Just <| UrlChange NewEntry "/#login"

And my app's path is https://example.com/subdirectory then the above code will change the URL to https://example.com/#login.

However the desired/typical outcome should be https://example.com/subdirectory/#login

[rgrempel]

I suppose you've basically got two options, either:

Just <| UrlChange NewEntry "#login"

or

Just <| UrlChange NewEntry "/subdirectory/#login"

I find the former to be quite convenient if you've decided you are just using the hash, as you don't have to know what the subdirectory actually is.

[amitaibu]

Yeah, I tried removing the leading / , but this results with an error:

Uncaught SecurityError: Failed to execute 'pushState' on 'History': A history state object with URL 'http:/#login' cannot be created in a document with origin 'http://localhost:3000' and URL 'http://localhost:3000/'

It seems to remove the base url.

[rgrempel]

Ah, that is interesting.

Now, it does work in some cases, but what it is relying on (when it works) is that the browser will interpret a pushState which starts with a "#" in a certain way ... that is, just changing the hash and leaving everything else alone.

So, one clue to the problem is that the browser you're using is interpreting the input to pushState as having been "http:/#login". That is, when given "#login", your browser is normalizing that to "http:/#login" (rather than to "http://localhost:3000/#login", which presumably is what would work).

In any event, I suppose that I could fix this by pre-normalizing what I supply to pushState. That is, if the new URL starts with a "#", I do know the current URL, so I can do the normalization I want manually. Presumably that's what I'll have to do, if some browsers don't behave as I expected.

BTW, which browser/OS combination are you seeing this with? I should try to reproduce this before I fix it :-)

[amitaibu]

which browser/OS combination are you seeing this with?

Mac (10.10) & Chrome 50

[amitaibu]

btw, for now I just cheated and add a CNAME so there's no more a subdirectory ;) http://elm-spa-example.gizra.com/

[rgrempel]

I'm actually having trouble reproducing the problem, using Chrome 51 and Mac OS X 10.11.

And, it turns out that it's a bit of a pain to re-install Chrome 50.

I'll mull this one over ... it really ought to work ... I suppose it's just barely possible that it was a bug fixed in Chrome 51.

If you can set up the original, offending code again, do you see any different results in Safari?

[amitaibu]

I've updated to Chrome 51 and it doesn't work there. Nor in Safari.

You can see this in http://elm-spa-example.gizra.com/ if you change the Router

[rgrempel]

I forked the elm-spa-example, and made the following changes to try to reproduce the problem:

https://github.com/rgrempel/elm-spa-example/commit/a4e8eb577f7cdd3e3b3ae95e72d10d5cadd14b4f

With these changes, I need to go http://localhost:3000/serve/ in order to see the app -- that is, when I run gulp, I've now got the app mounted in a subdirectory.

This seems to work for me, both in Safari and Chrome.

So, I'm thinking that I must not be accurately reproducing what failed for you?

[amitaibu]

You should see the app under http://localhost:3000 (the gulpfile change shouldn't be needed)

[rgrempel]

Ah, I am seeing the problem now -- not sure why I wasn't before.

I shall investigate!

[rgrempel]

This should be fixed in version 2.0.1 -- thanks for reporting it -- and my apologies for not reproducing it sooner!

[amitaibu]

Thank you! 👍