[connorbode]

fixes #1388

[mary-poppins]

I'm sorry, but I wasn't able to verify your Contributor License Agreement (CLA) signature. CLA signature is required for any code contributions to AngularJS.

Please sign our CLA and ensure that the CLA signature email address and the email address in this PR's commits match.

If you signed the CLA as a corporation, please let us know the company's name.

Thanks a bunch!

PS: If you signed the CLA in the past then most likely the email addresses don't match. Please sign the CLA again or update the email address in the commit of this PR.
PS2: If you are a Googler, please sign the CLA as well to simplify the CLA verification process.

[connorbode]

@Narretz : This was labelled $http but it relates to ngResource

[Narretz]

Thx, fixed. Have you checked why your CLA couldn't be verified?

[connorbode]

I had submitted the CLA right before submitting the pull request -- I'm assuming it hadn't been processed yet. It's verified now though.

And the Travis build errors are really odd. All tests failed with

Message:
     timeout: timed out after 30000 msec waiting for spec to complete
   Stacktrace:
     undefined

I was able to build fine. If you have access to Travis can you re-run the build?

[Narretz]

I think Travis is a real pain at the moment. Can't do anything about it. I added a 'needs review' label, so hopefully maybe someone will look it over (although I noticed the origin issue has been labelled Purgatory)

[connorbode]

thx

[caitp]

no

[caitp]

So, the main issue here (from my perspective) is that we have no way of ensuring that user-provided path values are "sane", and it becomes the application's responsibility. That's probably fine, but it's something that should be noted in the docs.

I am not keen on the way this public API looks, but I can't really think of anything better for it.

Have to see what API owners think about it though

[connorbode]

So, the main issue here (from my perspective) is that we have no way of ensuring that user-provided path values are "sane", and it becomes the application's responsibility. That's probably fine, but it's something that should be noted in the docs.

I think this is why / is encoded in the first place. I can make a note of it in the docs.

I am not keen on the way this public API looks, but I can't really think of anything better for it.
Have to see what API owners think about it though

Who are the "owners"?

[rkakrik]

+1

[jcassee]

+1

Usecase: HAL

var Resource = $resource(':href', {href: '@_links.self.href'}, {put: {method: 'PUT'}}, {encodeSlashes: false})
var user = new Resource({username: 'example', _links: {self: {href: '/user/1'}}})
user.$put()

[jdeniau]

+1

[ghost]

+1
What is the status quo on this PR?

[toddb]

+10 - please, please, can we have this sorted. It has been around since 2012 in #1388 (as pointed out up the top)

[connorbode]

I don't think anything is happening with this version of angular anymore.
All the focus is on angular 2

On Mon, Mar 30, 2015, 4:47 AM toddb notifications@github.com wrote:

• 10 - please, please, can we have this sorted. It has been around
  since 2012 in encodeUriSegment in resource encodes params, should be optional #1388 encodeUriSegment in resource encodes params, should be optional #1388
  (as pointed out up the top)

—
Reply to this email directly or view it on GitHub
#7940 (comment).