Appcache causing hashbang URLs?

Enabling the Appcache package caused my app to start using hashbang routes. For example, if I go to /dashboard it redirects to /#!dashboard. Is this expected behavior? If so, can I disable it?

In addition to making my URLs ugly, the hashbang URLs are wreaking havoc with the collection-fs package, which relies on some custom routes for uploading. It seems to be getting stuck in a redirect loop.

For now I’ve disabled Appcache, but I’m curious if any of you have encountered similar issues before.

1 Like

I too have hit that wall and never gotton around to taking another shot at it.

I’d really appreaciate if you can share your findings.

I was very perplexed by the hashbangs also. I dug into it a few months ago, and was somewhat surprised to find out that it’s expected behavior and traces all the way to W3C standards/discussions.

http://www.w3.org/blog/2011/05/hash-uris/

Apparently, localstorage is treated as a document fragment by the browser? Something along those lines…

3 Likes

Thanks for the link. That seems to explain to logic behind using fragment identifiers with AJAX apps, but it didn’t clarify the connection with the AppCache.

I did a little more digging and found this old post from the meteor-core forum:

The current appcache package makes any URL path route serve the application HTML, using the fallback section with an entry of “/ /”, which says that any URL not otherwise listed falls back to serve the root ("/") URL contents.

The problem is that each and every route encountered get added as a “master” entry in the application cache, and Chrome at least then stores (and reloads on a cache update) all the master entries.

https://groups.google.com/forum/#!msg/meteor-core/bUTOXugc5qE/QOmlSjZxwFYJ

So it seems like in order for the AppCache to work properly, Meteor (or Iron Router, more specifically) needs to use hash fragments so browsers don’t cache each route as a distinct page. Bummer, but at least it makes sense now.

Iron:router uses iron:location which have a weak dependency on appcache and configure the Location object to use hash bang if appcache is used in the app.
i guess that you will need to use another router (may be Backbone router) or dig into webapp connect handlers as appcache uses webapp, and probably regenerate response html based on that case.
if meteor came to support server side rendering this would be part of heaven.

2 Likes

Ok, then I wonder, what do we do in order to handle this situation?

I remember getting all kinds of error messages in the console, which had led me to ditch appcache in the first place.

There is a limitation with appcache. https://groups.google.com/forum/m/#!topic/meteor-core/tFXZkhIWeKk

1 Like