AngularJS Hash Bang Urls and Query Parameter ordering

[CMCDragonkai]

According to AngularJS documentation, it states that a hash bang URL is in this format:

http://foo.com/#!/bar?baz=23

This indicates that the hash fragment is between the path and the query parameters of the URL. It's DOMAIN - HASH FRAGMENT - QUERY PARAMETER

However on Google AJAX Crawling Specification, when it converts a hash bang URL into the _escaped_fragment_ format for the purposes of indexing and then converts it back for search results, it instead places the hash fragment after the query parameter. (See the Search Results section)

http://foo.com/?baz=23#!/bar

This indicates DOMAIN - QUERY PARAMETER - HASH FRAGMENT.

It seems that both are a valid URL structure (try it on a browser with any non SPA application). However if you are using this URL format on any AngularJS site, the site correctly ascertains the path, however it "forgets" the query parameters.

So if you go to http://docs.angularjs.org?key=value#!/guide, it turns into http://docs.angularjs.org/guide. As you can see it forgets the query parameters. If I'm using the Google AJAX specification, then this would result in search results having URLs that don't work properly as their query parameters gets dropped.

I did some testing with both urls which has illuminated the problem:

Case 1: Using DOMAIN - HASH - QUERY PARAMETER (AngularJS format) (http://example.com/#!/path?key=value), the query parameters never gets received by the server, but it is remembered on the client side. It's also available in $location.search().

Case 2: Using DOMAIN - QUERY PARAMETER - HASH (Google's format) (http://example.com/?key=value#!/path), the query parameter gets received by the server (as it is not after the #), but it is forgotten on the client side. It's also not available in $location.search().

Perhaps a solution can be made for case 2. So that when there is query parameter and then hash fragment, AngularJS can correctly remember the query parameter and shift it to the end of the URL (if converting to HTML5 urls) and also make it accessible with $location.search(). Case 1 cannot be solved due to the URL standards as everything after the # is not sent to the server.

[tbosch]

Angular does not remove the query before the hash bang. For angularjs.org this is done on the server with a redirect. See this jsfiddle: http://jsfiddle.net/dVNPz/show/?a=b#!/test?c=d

However you are right in that Angular does not include the query parameter before the hash into $location when in hashbang mode. The reason for this is that Angular can't change anything before the hash without the browser reloading the page.

How did you get the value for the _escaped_fragment_?

[CMCDragonkai]

With regards to the value of _escaped_fragment_, that's just based off the Google AJAX Crawling Specification.

So the server is the one that removes the query before the hash bang? If one could make the server keep the query, can AngularJS extract those values and place it in $location? It doesn't need to change the values before the hash to read the values before the hash right?

[tbosch]

Right, the server behind angularjs.org does remove the query before the hash bang. Your server might not, depending on how you configured it.

Angular could provide this extra information, but the other parts of the url before the # are not present on $location either (e.g. the path). The best thing would be to have a new service that encapsulates window.location only for reading purposes.

For your app, you can just do this (e.g. directly access window.location) and read out the query value.

[tbosch]

Before we work on this, we need verify that Google really moves the query part from behind the hash to the front of it, and does not escape it as well.

[CMCDragonkai]

The part where it mentions it in the Google AJAX specification is here:

Search result

The search engine agrees to display in the search results the corresponding pretty URLs:

    domain[:port]/path#!hashfragment
    domain[:port]/path?queryparams#!hashfragment
    domain[:port]/path
    domain[:port]/path?queryparams 

Specifically:

    domain[:port]/path?queryparams#!hashfragment

Now Google will put everything after the hash fragment into the _escaped_fragment_. This will result in an AngularJS compatible URL. This is not the problem.

The problem is that DOMAIN HASH QS and DOMAIN QS HASH are both valid URL structures. And while we cant fix DOMAIN HASH QS, surely AngularJS should be able to extract the QS from DOMAIN QS HASH.