fix($route): fix redirection with optional/eager params

[gkalpak]

Previously, when (automatically) redirecting from path that fetured a trailing slash and optional or "eager" parameters, the resulting path would (incorrectly) contain the special characters (?,*) along with the parameter values.
(There is also a first (unrelated) commit, that fixes the names of 2 tests in routeSpec.)

Closes #9819

[gkalpak]

With regard to #9819 (comment), why not merge this one and close the resolved/duplicate issues issues and PRs (as detailed in the aforementioned comment), until #8200 is merge-ready (i.e. has satisfactory test-coverage) ?

[pkozlowski-opensource]

The second commit (04f38fd) LGTM, I'm still puzzled about the 018d942. @gkalpak could you help me understand what is going on with 018d942?

I will have another look at this one before merging, putting for 1.3.4 for now.

[gkalpak]

@pkozlowski-opensource: The diff for gkalpak@5f54934 is kind of "deceiving". If you take a look at https://github.com/gkalpak/angular.js/blob/22ddfe570aaa2855f24bf3655c757f1d9226209b/test/ngRoute/routeSpec.js#L265 there is this route defined:

$routeProvider.when('/$test.23/foo*(bar)/:baz',

What the tests are trying to show is that the . (in $test.23) and the * (in foo*(bar)) are literally matched (i.e. they are only going to be matched against a . and a * respectively - and not interpreted as special RegExp characters).

The 1st test tests for the . by substituting $test.23 with $testX23 and verifying that the route does not match. Therefore, it should be named matches literal . (not *).
The 2nd test tests for the * by substrituting foo*(bar) with foooo(bar) and verifying that the route does not match. Therefore, it should be named matches literal * (not .).

_{(Copied from: https://github.com/gkalpak/angular.js/commit/22ddfe570aaa2855f24bf3655c757f1d9226209b#commitcomment-8525121)}

[pkozlowski-opensource]

@gkalpak OK, I see, this makes sense. Thnx for clarifying.

[pkozlowski-opensource]

@gkalpak one more question - in your comment you are suggesting that that this PR should be closed in favour of #8200. Is it still true?

[gkalpak]

@pkozlowski-opensource: I never said my PR should be closed in favor of #8200 (in those exact words :P).
My suggested "roadmap" is detailed in my other comment you mentioned.

Basically, I would merge this PR (mainly for the test-name fixes and the additonal test-case).
Then I would (rebase and) merge #8200 (as it solves an extra corner-case issue and I find the approach more clear anyway).
Finally, I would close related issues/PRs (see my other comment).

[googlebot]

Thanks for your pull request.

It looks like this may be your first contribution to a Google open source project, in which case you'll need to sign a Contributor License Agreement (CLA) at https://cla.developers.google.com/.

If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check the information on your CLA or see this help article on setting the email on your git commits.

Once you've done that, please reply here to let us know. If you signed the CLA as a corporation, please let us know the company's name.