forward slashe being replaced by %2F in the latest release

[t0lkman]

Forward slash is being replaced by %2F in the latest release (0.2.12).

[t0lkman]

I have to mention, it's only on Ubuntu.
On my local OSX Maverick everything is fine!

[christopherthielen]

This is an extremely vague bug report. 👎

I happen to know what you're referencing, and it's by design so parameters with slashes can be encoded into the URL without affecting the path matching. How is this affecting you?

[t0lkman]

Is it by design? Where can I read about those changes?
All I see is a week ago when I had 0.2.11 my json payload looked like that:
"intervals":["2014-11-07T08:00:00.000Z/2014-11-18T07:59:59.999Z"]

after bower install, I have received 0.2.12 and my payload now looks like:
"intervals":["2014-11-07T08:00:00.000Z%2F2014-11-18T07:59:59.999Z"]

[johnraber]

@christopherthielen I work with t0lkman. We have an issue when we send POST payloads via http.post . Previously, the payloads were not being encoded when using 0.2.11 and when we starting using 0.2.12 we saw the encoding which our backend can't handle. It was difficult to catch since it is platform dependent. Will this be classified as a bug? Thanks for your help.

[christopherthielen]

This new code shouldn't be affecting your $http.post call. It should only affect how parameters are encoded into the URL. Show me the code where you are posting. Please put it in a plunk http://bit.ly/UIR-Plunk

This commit introduced the slash encoding: 3045e41 and was in response to this bug report #1119

[johnraber]

We will put together a plunk example in a bit ... but we are not suggesting the router effects $http.post. I should have been more accurate in the problem description. We are pulling the params off our url when we change states via ... $location.search().s which use to decode url params but now does not on the Ubuntu platform. Thanks

[christopherthielen]

OK now it's becoming clear. Why do you try to manage $location.search() manually? Why not use the $stateParams?

If you are convinced that you must manage .search() manually, you can also override the built-in string type (which is performing the slash encoding) by registering your own replacement "string" type.

  function valToString(val) { return val != null ? val.toString() : val; }
  function regexpMatches(val) { /*jshint validthis:true */ return this.pattern.test(val); }
  $urlMatcherFactory.type("string", {
      encode: valToString,
      decode: valToString,
      is: regexpMatches,
      pattern: /[^/]*/
    });

[christopherthielen]

closing, works as designed.

[johnraber]

Thanks for the tips Chris!

[epicwhale]

I must add that even though this is a design decision to encode all slashes in params, it causes a backwards break. Maybe this should be marked as a major release instead of a minor / revision as its surely breaking our app, given our use-case resolves around having one centralized route named 'rewrite' which accepts the entire route as a single param.

$stateProvider.state('rewrite', {
            params: { uri: {}, resource: {} },
            url: '/{uri:.*}',
            // ....
        })

I can't think of a solution to upgrade seamlessly to the latest version without registering a custom type. Or am I missing something?

cc: @christopherthielen

[christopherthielen]

@epicwhale Sorry, I think you'll have to register a custom type.

function valToString(val) { return val != null ? val.toString() : val; }
function regexpMatches(val) { /*jshint validthis:true */ return this.pattern.test(val); }
$urlMatcherFactory.type("uriType", {
  encode: valToString, decode: valToString, is: regexpMatches, pattern: /.*/
});

$stateProvider.state('rewrite', {
            params: { uri: {}, resource: {} },
            url: '/{uri:uriType}',
            // ....
        })

[adamreisnz]

For reference, I ran into this (or similar) issue with hosting my Angular app (HTML5 mode) on S3 and using redirection rules to prevent 404's when a user types in a direct URL to a certain route.

Due to S3 limitations, these direct URL's needed to be rewritten to use the hash symbol, e.g. example.com/some/path would have to be rewritten to example.com/#/some/path so that S3 would serve the index.html correctly.

Angular's HTML5 mode then kicks in and automatically removes the #/ part from the URL.

However, I found when using $urlMatcherFactoryProvider.strictMode(false);, this behaviour got broken and ui-router replaced the URL to example.com/#%2Fsome%2Fpath instead.

Removing the strict mode setting to false fixed the issue.