Escaped Fragment and Query Parameter Problem

[CMCDragonkai]

In cases 1 and 3. The client side (AngularJS) cannot access the query parameters, but the server can. However this can be fixed angular/angular.js#6172

In cases 2. The client side (AngularJS) can access the query parameters, but the server never gets any of the query parameters. This cannot be fixed without changing the URL standard as everything after the hash is not passed to the server.

CASE 1

http://example.com/?key=value#!/blah (Link)
=> http://example.com/?key=value&_escaped_fragment_=%2Fblah (Google conversion)
=> GET [/blah](urldecode%28%29 automatically)
=> http://example.com/#!/blah?key=value (the hash is appended without any encoding)

(FINAL - this is the proper form according to Google AJAX specification. It allows the query parameters to be processed by both the server and the client)
(The middleware currently implements this)
=> http://example.com/?key=value#!/blah

CASE 2

//Assuming the Google Search Engine doesn't differentiate what's after the #! and considers it all fair game. Then everything after the #! is going to be moved inside the escaped_fragment

http://example.com/#!/blah?key=value (Link)
=> http://example.com/?_escaped_fragment_=%2Fblah%3Fkey=value (Google conversion)
=> GET [/blah?key=value](urldecode%28%29 automatically)
=> http://example.com/#!/blah?key=value (the hash is appended without any encoding)

(FINAL - this is not the proper form, however this cannot be fixed without extra logic because the escaped_fragment value is a single string containing anything. In this case, the query parameter can only be accessed from the client side, and it will never be passed to the server.)
(The middleware currently implements this)
=> http://example.com/#!/blah?key=value

CASE 3

//Assuming the Google Search Engine does differentiate on what's after the #! and can separate paths from query parameters and anchors. Then query parameters after the #! will not be moved inside the escaped_fragment

http://example.com/#!/blah?key=value (Link)
=> http://example.com/?key=value&_escaped_fragment_=%2Fblah (Google conversion)
=> GET [/blah](urldecode%28%29 automatically)
=> http://example.com/#!/blah?key=value (the hash is appended without any encoding)

(FINAL - this is the proper form according to Google AJAX specification)
(The middleware currently implements this)
=> http://example.com/?key=value#!/blah

CONCLUSION

With regards to the URLs that is sent to the SnapSearch service:

We should follow Google's AJAX specification of DOMAIN - QUERY PARAMETER - HASH. This fits with the URL standard and allows the query parameters to be potentially accessible from the client and server even if some frameworks don't implement this properly.

However the problem is whether Google differentiates whats after the #!. It is quite likely that they do not differentiate. This can be concluded with some tests, but it will take some time. This means that CASE 2 does not follow Google's AJAX specification, and will not follow it, unless we put in logic to differentiate paths from potential query parameters inside the escaped_fragment. This logic will have to be very robust because the escaped_fragment can be very malformed.

RECOMMENDATIONS

Make sure popular SPAs fix up their query parameter detection on hashbang URLs so that they detect query parameters on DOMAIN - QUERY PARAMETER - HASH formats (Case 1 & Case 2).

a. AngularJS - angular/angular.js#6172

If the it's going to be DOMAIN - HASH - QUERY PARAMETER (Case 2), either compensate it with extra logic to differentiate inside the hash fragment. Or recommend to developers that their query parameters should not be pertinant to content output from the server side. That is, the query parameters are only relevant to the client side. Developers using hash bang urls and following this advice will negate this problem.

Sites using HTML5 pushstate are not affected by this.