Impossible to encode slashes as path parameters using URI encoding

[christopherthielen]

UI-Router has had troubles encoding slashes in path parameters for quite a while now.

example:
Given: a url with parameters: /path/:param1/:param2
If: param1 is foo/bar and param2 is baz/qux
The browser URL should be: /path/foo%2Fbar/baz%2Fqux

We've gone through a few iterations to encode those slashes, including attempting double encoding (3045e41) and eventually a custom encoding (02e9866).

I wanted to revert any special handling of slashes, and simply url-encode/decode. I dug into this recently and I've come to the conclusion that it's actually impossible, using the $location service.

For posterity, I am leaving my notes here:

---

We are currently calling $location.url(url) to apply a new URL. The $location.url implementation decodes the path portion of the url before applying it as the $location.$$path. Naively passing a pre-encoded URL such as /path/foo%2Fbar/baz%2Fqux immediately get decoded to /path/foo/bar/baz/qux, the param separation are lost. Internally $$path is set to /path/foo/bar/baz/qux

Since .url() pre-decodes the incoming URL, we can't use it. Calling $location.path() directly seemed like a possible alternative since it applies the path without much processing. The $$path value is set the way we want with our parameters encoded: /path/foo%2Fbar/baz%2Fqux. However, then the $$url is built from $$compose() by calling encodePath which splits the path on the slashes, then encodes each segment. Because of this, $location.url() is double encoded as /path/foo%252%bar/baz%252Fquz.

We landed on purposefully double encoding the slashes, but this caused quite a few issues (most linked to this ticket #1645).

As of 0.2.16, we're custom encoding slashes as ~2F (using the string typed parameter) so that the $location service doesn't try to handle them specially.

This is working fine for most of our users. If a user requires a slug (non-encoded slashes) we can support that using a different parameter type that doesn't explicitly encode/decode.

---

In query parameters, however, we also currently default to the string parameter type, which is unnecessarily encoding slashes, such as ?queryParam=foo~2Fbar. We should choose a different default parameter type for query parameters than for path parameters to avoid this. I don't have a ticket for this yet.

[ozzi-]

Thank you so much! Now i can remove the dirty hack i have been using

[DavideCordella]

As far as I understod the actual issue is in the $location.url method.

I need to provide my clients with valid urls eg.: http://xyz.com/books/bookId%2FwithSlash/title , that can be shared.

If I just disable encoding/decoding of urls using a parameter custom type, the code %2F is translated to "/" in the address bar, but this leed to a different url from the one I am supposed to provide (with correct URI encoding).

How can this be fixed?

[christopherthielen]

@Songissimo Unfortunately, If I remember correctly, thats the crux of this issue:

The $location.url implementation decodes the path portion of the url before applying it as the $location.$$path. Naively passing a pre-encoded URL such as /path/foo%2Fbar/baz%2Fqux immediately get decoded to /path/foo/bar/baz/qux, the param separation are lost. Internally $$path is set to /path/foo/bar/baz/qux

this might be impossible to fix when $location is being used.

[DavideCordella]

Then, do you think is problem on $location service? Why can't we use another function to set the URL? This is a crucial issue as make impossible to deliver valid URLs.

[christopherthielen]

@Songissimo unfortunately I think the root problem is in $location service.

Why can't we use another function to set the URL?

The problem is primarily related to reading the URL. You might be able to work around the issue by monkey patching $location, but that's something that ui-router cannot support.

[christopherthielen]

Update:

Here's a plunker showing various methods of setting the URL and how it's interpreted by angular 1: http://plnkr.co/edit/T34potPhkRLj6OyLOTKy?p=preview

Here's a issue to track refactoring of this ~2F code in ui-router-core: ui-router/core#14

This doesn't fix the issue with $location, but allows ng2 and react to avoid the weird encoding.

Ng1 Workaround

In ui-router 1.0 betas, you can have slashes in parameters by declaring a param type as { raw: true } but the behavior is undefined when decoding those values.

Example:

  $urlMatcherFactoryProvider.type('pageParam', {
    encode: (pageValue) => (pageValue ? ('page/' + pageValue) : ''),
    equals: (val1, val2) => (val1 === val2),
    decode: (paramString) =>  
        (paramString ? parseInt(/page\/(\d+)/.exec(paramString)[1]) : 0),
    pattern: /page\/\d+/,
    is: pageValue => (typeof pageValue === 'number'),
    raw: true
  });

http://plnkr.co/edit/2E2bdGZqncJKTJ1UGOLv?p=preview

[DavideCordella]

What do you mean by "behavior is undefined when decoding those values"?

[christopherthielen]

It's basically a warning that using raw params is not guaranteed to work bi-directionally for arbitrary data.

For example, a url pattern like '/foo/:param1/:param2' with parameter values { param1: 'a/b', param2: 'c/d' } serializes fine to /foo/a/b/c/d but there's no way to deserialize it and extract the original param values.

---

Actually, I think the only guarantee we can make for raw is that ui-router will not url-encode the parameter value. We're still at the mercy of the $location service (in ng1) for example. Developers will be responsible to ensure their parameter values appear in the URL and are deserialized properly.

Here's a plunk showing some edge cases that I don't think we can perform successfully in ng1 : http://plnkr.co/edit/bjDtVkdHaXUZe3p6NGJ7?p=preview

[felixfbecker]

@christopherthielen any way to prevent %-encoding of query param values in ng1? Could ui-router circumvent $location?

[christopherthielen]

It might be possible in ui-router 1.0+ by specifying raw: true

url: '/foo?param1',
params: {
 param1: { raw: true }
}

Can you try and report back?