Such the better idea. I copy-and-pasted the back-forward impl from some
other helper code (actually in xhrwrapper, which will be replaced w/
this), but this is less code, faster, and more accurate.
Sending updated patch shortly w/ the following updates:
* Regex parsing
* Responses to all Michael's comments (from oddly duplicated request
http://codereview.appspot.com/1673051/show)
* Maintenance of query param ordering, where possible
- Makes tests deterministic
- minimizes chance of weird reordering/cache invalidation issues
- generally less annoying behavior for the user, at little code cost
* Tests actually pass (I sent this CL a bit early per others' request)
On 2010/07/21 06:41:44, jasvir wrote:
http://codereview.appspot.com/1875044/diff/2001/3005
File features/src/main/javascript/features/shindig.uri/uri.js (right):
http://codereview.appspot.com/1875044/diff/2001/3005#newcode60
features/src/main/javascript/features/shindig.uri/uri.js:60: function
parseFrom(url) {
I don't think parsing from the end rather than from the beginning
works
correctly for URLs. http://www.google.com/search?hl=en&q=:// for
example will
be misparsed by this code I suspect.
At the risk of quoting RFCs, RFC 3986 gives a handy regular expression
for
splitting a URL.
^(([^:/?#]+):)?(//([^/?#]*))?([^?#]*)(\?([^#]*))?(#(.*))?
12 3 4 5 6 7 8 9
scheme = $2
authority = $4
path = $5
query = $7
fragment = $9
Note this regex allows the authority to be things like
//host.com:daytime (where
the port is a named port rather than a number) and //host.com:evil.com
(which
some browsers like FF3.5 and Opera will accept to mean //host.com).
If you want
to defend against that, I'd recommend split the authority into host
and port and
ensuring that the port is a number.
http://codereview.appspot.com/1875044/show
