$resource POST removing trailing slash

I have a module where I define a service like this:

.factory("Charts", function ($resource) {
return $resource("/api/charts/:chartId", {
}, {});
})

Then, on the controller I do:

var chart = new Charts({
name:$scope.name,
query:$scope.query,
since:$scope.since,
since_unit:$scope.since_unit,
interval:$scope.interval
}
);
chart.$save();

And on the server I'm receiving the POST to /api/charts instead of /api/charts/ that is what (I think) it should be.

There is a discussion in the list:

https://groups.google.com/forum/?fromgroups#!topic/angular/taypgj_D3YQ

Pull request on this issue: https://github.com/angular/angular.js/pull/1064/files

we just ran into this with django, it was a bit of a tussel, with angular stripping off the slash and django (by default) was adding slash it back end and doing a redirect. Even after changing django default, I ran into an inconsistency with django-tastypie and ended up modifying ngResource to append a slash to make all parties happy.

a little differen than fastreload's

return url + "/" + (query.length ? '?' + query.join('&') : '');

I think maybe an param option might be nice.

--thx

dan

I have done a quick hack on the issue but what I think is that frameworks should treat urls as is. Adding or removing a character from url actually means creating a completely new url and hoping that server will understand what we want.

I think the convenience of providing the hash with bind elements (as opposed to having a url template), means, that angular needs to muck with the url. I think they tried to cover too many cases and instead should probably just tell the user. What the url will look like in the various cases or provide options to dictate what should happen. IMHO

Yes, but they could also make their internal interpretation of the urls and use the original url while contacting server. I have not examined the inner workings of url interpretation and routing yet this still does not legitimize changing urls without explicit order from user/coder.

Each server can have different types of interpretation urls and a client side framework should be able to communicate with them with no hassle or source changing. For example, Django has APPEND_SLASH setting which uses HTTP 302 redirection to append slash to urls without slash. This works with GET method but not with others (POST,PUT,DELETE) because redirection cannot and will not pass the data to the new URL.

I think these are great points to bring up. Don't know if you saw but there was a fairly long thread (a number of months ago) on ngResource rewrite and request from comments from Misko. Given the diverse response, I he decided to table things until future time.

I haven't seen that thread, I am also not using angularjs for that long time, yet the claims that I have said are not design philosophies which is not related to a particular framework (as you said). Hopefully developers will see this issue and change their designs until new development cycle.

Is there any more discussion on this? It would seem strange that the framework would enforce a certain type of url.

Not that I know. No active developers have responded to this issue yet. I think that they would agree to that it is wrong to enforce a certain type of url but this part of the framework (ngResource, http) might not be loosely coupled with the rest of the framework and it may require more than a couple of changes for it to work. But that's just a hopeful assumption.

There are many deficiencies in $resource. We are trying to figure out what
to do with it. in the meantime we recommend that you create resources
manually, which gives you full control over everything.

See:
http://stackoverflow.com/questions/11850025/recommended-way-of-getting-data-from-the-server/11850027#comment15909222_11850027

On Tue, Aug 21, 2012 at 4:20 AM, Umur Kontacı notifications@github.comwrote:

Not that I know. No active developers have responded to this issue yet. I
think that they would agree to that it is wrong to enforce a certain type
of url but this part of the framework (ngResource, http) might not be
loosely coupled with the rest of the framework and it may require more than
a couple of changes for it to work. But that's just a hopeful assumption.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/992#issuecomment-7898116.

That would be a proper workaround meanwhile. Thanks for the heads up

Thanks for the responses! Sorry to ask this here, but following the example, Book is undefined for me in my controller. Any suggestions?

@stryderjzw

@stryderjzw the factory is missing return Book, I updated the SE.

As part of our effort to clean out old issues, this issue is being automatically closed since it has been inactivite for over two months.

Please try the newest versions of Angular (1.0.8 and 1.2.0-rc.1), and if the issue persists, comment below so we can discuss it.

Thanks!

I took a different approach to remedy this incompatibility issue with my django backend. Just thought to share with the folks encountering the same problem for the time being. I wrote a custom response interceptor that adds the trailing slash if the url doesn't already have one. Note that the interceptor skips the requests that are configured to use $http cache.

I think the best fix is adding APPEND_SLASH = False in your django settings.

That sometimes isn't an option. The best fix would be having this be configurable in the $resource() constructor, e.g.:

$resource(url[, paramDefaults][, actions][, options]);

Where options could be:

{
  trailingSlash: true/false/undefined,
}

When the trailingSlash option isn't specified, or is undefined, it's the current behaviour. When true, it could always append if necessary, when false, always stripped when necessary.

This problem isn't just for Django people. We have a custom PHP webservice that was created with all trailing slashes.

My pull request to attempt to fix this for once and for all is #5560.

This should support the following configuration:

app.config(function($resourceProvider) {
  $resourceProvider.defaults.stripTrailingSlashes = false;
});

or per instance, using a new, fourth, optional argument to the $resource() constructor:

var CreditCard = $resource('/some/:url/', ..., ..., {
    stripTrailingSlashes: false
});

Any feedback, anyone?

This is the stupidest bug ever, angular has no business editing urls that have been explicitly defined by the developer. And why was this ever necessary in the first place? And 2 years to fix this?

@j0hnsmith

Thanks for being super constructive @j0hnsmith :) This has been triaged for 1.2.x, and it is potentially a breaking change for people who are depending on this functionality unwittingly!

If you can put together a PR to make this work for you, you could let people dog-food it so that we can get a bit more certainty of it, and that would be awesome! We can try to look at it for 1.2.10, if not 1.3

(Oh, and just to correct you, this isn't really "angularjs" core, this is ngResource, which you are not at all forced to use with Angular)

@caitp

@caitp Sorry, don't mean to sound negative, I was just totally astonished by the situation, should've waited 5 mins before I pressed the comment button. After I posted the comment I did see that #5560 has been triaged. I look forward to the change making the grade.

@nvie

Until @nvie 's patch is in, the following will do for a workaround, even in firefox.

Note: This will remove an ending backslash from all urls. If you need that functionality in your application, don't use this.
Django users: this will be making it into djangular very soon, when settings.APPEND_SLASH is true.

angular.module('ngResource').config([
    '$provide', '$httpProvider',
    function($provide, $httpProvider) {
        $provide.decorator('$resource', function($delegate) {
            return function() {
                if (arguments.length > 0) {  // URL
                    arguments[0] = arguments[0].replace(/\/$/, '\\/');
                }

                if (arguments.length > 2) {  // Actions
                    angular.forEach(arguments[2], function(action) {
                        if (action && action.url) {
                            action.url = action.url.replace(/\/$/, '\\/');
                        }
                    });
                }

                return $delegate.apply($delegate, arguments);
            };
        });

        $provide.factory('resourceEnforceSlashInterceptor', function() {
            return {
                request: function(config) {
                    config.url = config.url.replace(/[\/\\]+$/, '/');
                    return config;
                }
            };
        });

        $httpProvider.interceptors.push('resourceEnforceSlashInterceptor');
    }
]);

I've been dealing with this issue while developing server-side support for $resource in Django. (crud view in django-angular)

The simplest workaround for Django is to not use trailing slashes in views used with $resource.
Note that APPEND_SLASH only appends trailing slash when the non-trailing version of the url doens't match any regex in the urlconf.
But since not using trailing slashes is kinda anti-convention, it's better to make them optional rather than removing them.

E.g.

url(r'^angular/?$', AngularView.as_view()),

I'm in favour of that rather than monkey-patching $resource js. Anyway I hope this will be fixed soon.

is this still open?!

Fixed via #5560.

🎊

Unreal. Spent I don't want to admit how long wasting my time trying to figure out what I was doing wrong only to find this. Why on earth was an explicitly set string being messed with in the first place?

Navigation Menu

Repository navigation

$resource POST removing trailing slash #992

25 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

$resource POST removing trailing slash #992

Description

Activity

umurkontaci commented on Jun 17, 2012

dandoyon commented on Jun 26, 2012

umurkontaci commented on Jun 27, 2012

dandoyon commented on Jun 27, 2012

umurkontaci commented on Jun 30, 2012

dandoyon commented on Jun 30, 2012

umurkontaci commented on Jul 3, 2012

stryderjzw commented on Aug 21, 2012

umurkontaci commented on Aug 21, 2012

mhevery commented on Aug 21, 2012

umurkontaci commented on Aug 21, 2012

stryderjzw commented on Aug 22, 2012

mhevery commented on Sep 4, 2012

btford commented on Aug 24, 2013

25 remaining items

tamakisquare commented on Dec 4, 2013

mpaolini commented on Dec 4, 2013

nvie commented on Dec 4, 2013

jdhiro commented on Dec 6, 2013

nvie commented on Dec 29, 2013

j0hnsmith commented on Jan 19, 2014

caitp commented on Jan 20, 2014

j0hnsmith commented on Jan 20, 2014

brian-montgomery commented on Jan 22, 2014

jkosir commented on Mar 6, 2014

FrancisVarga commented on Mar 24, 2014

mgol commented on Apr 9, 2014

btford commented on Apr 9, 2014

jfbrennan commented on Nov 19, 2014

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions