URLs with hash-bang unexpected behaviour
Added by Jorge Paulo over 12 years ago
Hi,
I observed the following unexpected and unwanted behaviour when the hash-bang is required for internal paths.
My concern is that an URL with hash-bang doesn't behave exactly as the equivalent without the hash-bang.
I'm using IE9.
If a users accesses directly an URL in this format
http://myhost/#/test
The application start with an internal path of "/" followed by an internalPathChanged signal to "/test". (without hash-bang internal path is "/test" and there's no extra internalPathChanged signal)
My application uses a stacked widget at the root, and for optimization reasons, it just creates each layer after the user requests it.
With the hash-bang, I'm forced to compute all content for layer 1 at "/" ,followed by the layer corresponding to "/test".
This is because, on the first request, I'm not relying on the internalPathChanged signal, because it is not triggered if the URL is simply http://myhost or http://myhost/test
What is unexpected and unwanted for me:
- Because the "/" state/page is always created, it is flashed to the user followed by the "/test" page.
- Crawlers accessing the URL with the hash-bang, just see "/", not "/test"
I know IE9, and other browsers without history API, can access URLs without hash-bang, but these URLs are kept and spread to other users and browsers through bookmarks, emails, HTML links, etc...
What I think can be done
- Nothing, accept the current behaviour, after all the HTTP request is really for "/". Just make a very light "/" state and live with it.
- Maybe I'm using a bad application development pattern, fix it. (how?)
- Change to the API, so that the URI with the hash-bang is made available through WEnvironment, so that the developers can work around it: internalPath()="/", env.uri()="/#/test" (ugly)
- Abstract the hash-bang URL so that internalPath()="/test"
Please comment if you think you can help.
Regards,
Jorge
Replies (2)
RE: URLs with hash-bang unexpected behaviour - Added by Koen Deforche over 12 years ago
Hey,
Your analysis is indeed correct. With older browsers (without html5 history support), and when using progressive bootstrap, the first page will be rendered which is not aware of the internal path (the #/... is not propagated by browser to server). The workarounds (3, 4) will not work then (otherwise we would have made sure we propagated the correct internal path in the first place). As soon as we can read the fragment from the URL we propagate it is as an internal path.
You should probably provide a way for IE users to easily access the 'perma-link' for a page where you remove the hash, and encourage them to bookmark/email this link instead. For other users (html5 browsers) this is not needed. You do not want these fragment URLs to proliferate in the first place.
Hopefully, IE will follow soon with implementing html5 history.
Regards,
koen
RE: URLs with hash-bang unexpected behaviour - Added by Jorge Paulo over 12 years ago
Hi,
it makes perfect sense now.
I was mistakenly assuming the #/... was received by the server on the first request.
Wt makes such a nice work abstracting the Web specifics that I start to forget how it works :)
Thanks,
Jorge