Angular.js: encodeUriSegment in resource encodes params, should be optional
When having a $resource and sending a param to be used in the url, it would be nice if there was an option not to encode it. OOB it encodes (in this case the "path") param before it's match agains the url. For example
// In SomeResourceName factory:
$resouce('/:path', { path: 'default.json' }, ...)
// Useing SomeResourceName
SomeResourceName.get({ path: 'game/mygame.json' })
This will result in a call to url "/game%2Fmygame.json" instead of "/game/mygame.json".
There's a quick-fix-workaround:
// In angular-resource.js and method encodeUriSegment
function encodeUriSegment(val) {
return encodeUriQuery(val, true).
replace(/%26/gi, '&').
replace(/%3D/gi, '=').
replace(/%2B/gi, '+').
replace(/%2F/gi, '/'); // <--- Add this line
}
I have no idea what will break, but as of know it works for me. One could also hijack the actions argument in ResourceFactory and pass a skip encode flag to the Route constructor's defaults argument to tell it to skip the encoding.
fredrikbonander
All 55 comments
Created a gist with the changes for hijacking :) https://gist.github.com/3749345
fredrikbonander
on 19 Sep 2012
+1 to this. Provides greater flexibility. In our use case, we are using spring data rest for the backend and search methods are path params that we need to map to actions, ideally in the same resource object as for the basic CRUD ops.
manuelsantillan
on 29 Oct 2012
+1. Our ids contain slashes (we use RavenDB) and it would be a clean solution if it wasn't encoded
georgiosd
on 22 Nov 2012
Making it optional is fine but please insure that it's enabled by default.
It is ill advised to not encode URIs. Not doing so might seem "clean" now but I assure you it will bite you in the ass in this life or the next.
saden1
on 1 Apr 2013
If I read http://www.ietf.org/rfc/rfc3986.txt correctly, we should be allowed the unencoded slash for the fragment.
3.5. Fragment
The fragment identifier component of a URI allows indirect
identification of a secondary resource by reference to a primary
resource and additional identifying information. The identified
secondary resource may be some portion or subset of the primary
resource, some view on representations of the primary resource, or
some other resource defined or described by those representations. A
fragment identifier component is indicated by the presence of a
number sign ("#") character and terminated by the end of the URI.fragment = *( pchar / "/" / "?" )...
The characters slash ("/") and question mark ("?") are allowed to
represent data within the fragment identifier. Beware that some
older, erroneous implementations may not handle this data correctly
when it is used as the base URI for relative references (Section
5.1).
Use case: $location.hash('/secondary-resource')
toddb
on 27 Apr 2013
I'm just curious, is it possible to avoid this issue by double-encoding your params?
ProLoser
on 10 May 2013
Sorry, it then makes it even worse. Just to confirm I tried out a number of opens even though it felt futile!
'/', '%252F' --> %25252F
Also,
/ %2f --> %252F
'/', '//' --> %2F%2F
Thanks for the thought. Request still stands.
toddb
on 11 May 2013
Ran into this today. +1
I might not like it, but our id's contain slashes as well. This needs to be optional.
sephie
on 10 Jul 2013
+1
stevermeister
on 10 Jul 2013
+1
retailpoint
on 11 Sep 2013
+1
chelexey
on 28 Sep 2013
+1
mrzepinski
on 21 Nov 2013
+1
e0ipso
on 3 Dec 2013
+1
jchonde
on 28 Jan 2014
I see mention of a database (RavenDB) that makes the current implementation problematic, but I'd expect there to be an intermediary server that expects encoded components, and decodes them to the correct ID on the backend. Could someone provide a more concrete use case on where forced encoding is causing problems (sorry I don't have more context on RavenDB)?
We hesitate to allow this with the current design of $resource, because it'd make it to easy for user input to affect the path of a request.
jeffbcross
on 6 Feb 2014
I use $location for a REST/hypermedia design and not RavenDB (or $resource). I have had to work with a patched version of the library.
I am also seeking confirmation that in fact this proposal does actually follow the RFC too -see my comment above
I might also be a bit rusty around the library - so big apologies if I am wrong - there are also two implementations of one in resource at L332 and one in Angular at 1071.
I just need the one in Angular because it is what is used by $location ;-) (yes, I see the problem here so I wouldn't suggest haven't different implementations). Apologies if I have any incorrect analysis.
toddb
on 6 Feb 2014
+1
Anybody have a workaround for constructing resource URLs containing forward slashes?
davecap
on 13 Feb 2014
As per the patch line mentioned above in the files the two implementations also mentioned above. It's a pain.
toddb
on 13 Feb 2014
Is there any movement on this?
Just add a point where I could really use such an option myself.
LFDM
on 15 May 2014
hey there,
i've the same problem but the gist doesn't make it work for me. where do i have to place this encodeUirSegment method or where can i place this option? :/
patricklehmann
on 26 May 2014
I was using an HTTP interceptor to transform URLs. It was working until I tested on IE11. Angular breaks on XHR requests to URLs including % in IE11. Not sure about IE10. Angular is supposed to support IE9+ (reference)
Guess I'm going back to the modified ngResource..
connorbode
on 17 Jun 2014
@connorbode --- dude, like it was mentioned in your issue, write a failing test case =) This path SHOULD already be covered, so there's two possibilities, either it's not covered and should be, or you're doing something to break this.
Lets find out which it is!
caitp
on 17 Jun 2014
+1
an-dev
on 24 Jun 2014
+1
ksokol
on 28 Jul 2014
+1
Impossible to work with CouchDB and design-documents (_design/cafehub/_view/menu_items)
rkakrik
on 22 Aug 2014
Can you guys +1 my pull request instead of this issue? It fixes the issue but has been generally ignored since its submission. https://github.com/angular/angular.js/pull/7940
connorbode
on 22 Aug 2014
+1
Really need this to interact with some legacy webservices which do not perform URLdecode
grhegde09
on 23 Sep 2014
+1
There are definitely viable, useful circumstances where a user will want to disable the encoding of URL parameters (for instance, where you want to append to a base URL a path to a resource).
rossbayer
on 21 Oct 2014
+1
pachoulie
on 10 Feb 2015
+1
geoyws
on 19 Feb 2015
+1
jcfontecha
on 21 Mar 2015
+1
rashad803
on 26 Mar 2015
@toddb just FYI, your spec quote refers to the fragment part of a URL, i.e. the #foo/bar part, where escaping a slash is indeed not required or appropriate. But this bug is about escaping a slash in the main path part of the URL. In general, I don't think the RFC applies to this, how Angular's $resource service handles pattern matching and URL construction really doesn't concern the RFC much.
Not escaping slashes in a regular :param style parameter has the problem that it makes the pattern non-invertible. E.g. if you have /x/:param, and you allow generating /x/y/z for {param: 'y/z'}, the resulting /x/y/z will fail to parse against the URL pattern.
IMHO it might make sense to have a feature in URL patterns to accept a star pattern that eats slashes, e.g. "/:param1/:param2/*pathParam", where *pathParam would eat slashes in the URL. For * params, it'd then make sense to also accept slashes without escaping them.
mprobst
on 29 Apr 2015
@mprobst - you are quite correct that I was logging a bug only around the fragment. The code as I use it _also_ affects the fragment. I am not using the $resource service but rather $location. If my memory serves me there are a couple of implementations of the uriSegment code.
The patch by @connorbode from a quick read will address the issue. Cheers
toddb
on 29 Apr 2015
+1
adamhadani
on 30 Apr 2015
+1
nmehta6
on 8 May 2015
+1
paulistoan
on 15 May 2015
+1
strokyl
on 7 Jul 2015
+1
kinoakter
on 12 Aug 2015
+1
tonycapone
on 19 Aug 2015
+1
jkremser
on 20 Aug 2015
+1
pavolloffay
on 21 Aug 2015
You can use the same syntaxe like in the ui-router lib :
http://angular-ui.github.io/ui-router/site/#/api/ui.router.util.type:UrlMatcher
patou
on 6 Sep 2015
+1
it also happens in location
jiananshi
on 15 Oct 2015
:+1:
DaAwesomeP
on 20 Dec 2015
+1
TheSameSon
on 24 Dec 2015
I'm current doing a decode in order to send my original url to backend
.factory('decodeUriSegment', () => {
return (url) => {
return url.replace(/@/g, '%40')
.replace(/:/g, '%3A')
.replace(/\$/g, '%24')
.replace(/,/g, '%2C')
.replace(/\+/g, '%20');
};
});
+1
tekstrand
on 22 Jan 2016
+1
kishorekumaru
on 4 Mar 2016
app.config(function($resourceProvider) {
$resourceProvider.defaults.stripTrailingSlashes = false;
});
zapolnoch
on 5 Jul 2016
+1
hadirsa
on 12 Aug 2016
i'm getting this error in angularjs $resource service
Error: encodeUriSegment is not a function
ibrahim89
on 21 Oct 2016
@ibrahim89, make sure you use the same version of angular and angular-resource.
gkalpak
on 22 Oct 2016
@gkalpak, thank you !!
skarensmoll
on 9 Dec 2016
my error is solved
ibrahim89
on 10 Dec 2016
Related issues
nosideeffects
·
3Comments
tdumitrescu
·
3Comments
gkalpak
·
3Comments
visnup
·
3Comments
jtorbicki
·
3Comments
Most helpful comment
@ibrahim89, make sure you use the same version of angular and angular-resource.