link-to component no longer accepts special chars

[t4t5]

Previously, it was possible to include the "@"-symbol in your URLs.

My router looks like this:

  this.route('user', { path: '/:userHandle' });

... and I could redirect to the path this way:

{{#link-to "user" "@tristan"}}
  Go to profile!
{{/link-to}}

This worked in 2.5 (it transitioned to /@tristan), but in the recent versions it instead changes the URL to /%40tristan.

What's the reason for this change, and is there a way to turn it off?

[Serabe]

I think this is related to the fix of #4794. Not sure if we should consider this a bug or not.

[rwjblue]

I think @bantic and/or @nathanhammond would have the best understanding of this. Would love for them to review/reply.

[rwjblue]

The changes in question landed in Ember 2.7.0 (and have been reverted in current release branch, to be released as 2.7.2). They are still included (with bug fixes for the regressions identified) in the current beta (which will become 2.8.0).

The changes regarding encoding/decoding of links (including dynamic segments) were made in tildeio/route-recognizer#91. There is specific discussion there about @ (in the context of a URL reserved character).

[bantic]

One of the changes in tildeio/route-recognizer#91 was to help make it so that route generation and recognition are symmetric (that is, generating a route with a dynamic segment would always create a string that would then be recognized by the route-recognizer). Before that change it was possible to generate routes that would not be recognized, for example, if you had the route /:userHandle and you did {{#link-to "user" "abc/def"}} the url that is generated would be "/abc/def", which route-recognizer would no longer recognize (it doesn't match /:userHandle).

After that PR the part of a dynamic segment is always encoded via encodeURIComponent so that, e.g. "abc/def" becomes "abc%2Fdef". This happens in the generate method for a dynamic segment here.

I believe if you opt out of the improved encode/decode by setting RouteRecognizer.ENCODE_AND_DECODE_PATH_SEGMENTS = false; in your app, you'll see the behavior you're looking for (the "@" will appear in the URL as-is).

[bantic]

For context, encodeURIComponent will percent-encode any character in the uri reserved set (these: ; / ? : @ & = + $ ,) as well as non-ascii characters (like emoji). (The JavaScript spec for encodeURIComponent is here.)
And the URI spec for what makes up a path is here.
RFC 3986 implies that the following characters should be allowed (i.e., not percent-encoded) in path segments:
! $ & ' ( ) * + , ; = : @.
I will take a stab at updating route-recognizer to explicitly allow those characters (un-encoded) when generating dynamic segments.

[t4t5]

Thanks for the clarification @bantic! Seem overall like it's a good fix, but that some apps could get some nasty side-effects from it. 👍

Just one question: how can people set RouteRecognizer.ENCODE_AND_DECODE_PATH_SEGMENTS to false in their Ember CLI apps without forking the Ember library's route?

I naively tried setting:

var ENV = {
    RouteRecognizer: {
      ENCODE_AND_DECODE_PATH_SEGMENTS: false,
    },
}

... in the /config/environment.js-file, but that does not seem to work.

[bantic]

@t4t5 Hmm, looking now I'm not sure RouteRecognizer is explicitly exposed for you to set the flag on. I'll check on that.

I have a fix for RR (here: bantic/route-recognizer@23455b6) that I will PR in a little bit after I have a chance to clean it up.

[bantic]

@rwjblue Here's a PR that should fix the problem in RR: tildeio/route-recognizer#109

[nathanhammond]

@bantic RouteRecognizer isn't exposed to be able to set that flag from Ember land, but that's something I would prefer to keep. As of 0.3.0 I'd prefer to remove the "legacy" encoding behavior (and that flag) and stick with the behavior from RFC 3896 as "correct".

[nathanhammond]

Addressed upstream, can be closed.