$resource DELETE should set the request body if present.

[adamdecaf]

It seems to be that $resource.remove doesn't allow for a request body to be set (but rather sets it as query parameters.) It also looks like it could be changed in one line of resource.js

I haven't found a clear consenseness of if it should be allowed or not. (As per this SO answer). Thoughts?

[squid314]

It is my understanding from reading various discussions and documentation across the internet regarding this issue that HTTP's DELETE method must provide all information on what is to be deleted in the URL, even though it is allowed to have body content. In addition, in my testing while building various web apps, several browsers don't send any body content with DELETE requests even if it is provided to the XMLHttpRequest. As such, I don't think that this should be added.

[adamdecaf]

I have been reading a few articles / rfc discussions too, and it does seem like DELETE's shouldn't be allowed a body. (Since, as you said all of the information must be in the URL). Thanks for double checking.

[npetrovski]

I do not see a reason of not having body in the DELETE method. The body could be use for getting entity meta-data, version sync, etc, If I need to be honest I couldn't find the rfc where it is written that DELETE method should not present body; moreover I have seen a lot of software that are in fact count on the DELETE request body (for instance ElasticSearch).

Now, in present day angular $resource is a separate module, and when it comes to practically using it I found some very major problems:

1. DELETE does not send request body
2. DELETE does not send proper Content-Type
3. $request does not allow fully replacing the initial URL template with a dynamic address (this is required when using HAL REST pagination for instance)

[squid314]

As discussed above @npetrovski, while the RFC does not state that a DELETE cannot have a body, it does state that the definition of what is to be deleted must be fully specified in the URL. Additionally, also specified above, some browsers don't send the body content for DELETE calls even if it is validly specified on the XMLHttpRequest object. Therefore, at least until Angular 2.0, I don't think this is worth considering. If you need to add extra metadata which does not change what is being deleted, you can always specify it as part of the headers of the request (which is probably where it should be).

Regarding ElasticSearch, the documentation for delete which I found states that "The query can either be provided using a simple query string as a parameter, or using the Query DSL defined within the request body." This states that either URL query parameters or the body content may be provided. Is there a different API call you were referencing?

[npetrovski]

From what you are saying I still cannot see a reason angular not keeping the option of sending body over the DELETE requests. Of course it might be stripped by some browsers, but until it is not a part of any RFC stating that entity must be only specified by the URL and the headers I see this problem as a lack of functionality.

[squid314]

I'm not sure you understand what the RFC states, though I have attempted to explain it. If you look at the spec for DELETE and compare it to the spec for something like POST or PUT, you should be able to see the difference. The POST and PUT specs state that the "enclosed entity" should be associated with the "Request-URI". However, the DELETE spec says nothing about an "enclosed entity" and only mentions the Request-URI stating "The DELETE method requests that the origin server delete the resource identified by the Request-URI." Therefore, even if all browsers actually included the body content when they sent the request, a fully compliant server could ignore the "enclosed entity" entirely. (I'm confident that a compliant browser and server could handle requests while observing or ignoring the "enclosed entity" randomly, though that would be very unlikely to be implemented.) Since both the browser and the server can ignore the "enclosed entity", the $resource service would have to either detect what the browser and server are actually doing and handle that situation specially or send the identifying information both in the Request-URI and the "enclosed entity". Personally, I don't think that Angular should be supporting a non-standard feature such as this in the $resource service.

[npetrovski]

@squid314 I am fascinated from how you guys can read between the lines and assume something that has never been written. The fact that (as you said) "enclosed entity" is not mentioned in the RFC2616 section 9.7 (DELETE) does not necessary mean that it should not be presented in the request. Moveover, if you read the rfc a bit more carefully you would notice that message body is ONLY and explicitly forbidden in TRACE requests (section 9.8). The other statements related to the message body say:
- an entity-body is only present when a message-body is present (section 7.2)
- the presence of a message-body is signaled by the inclusion of a Content-Length or Transfer-Encoding header (section 4.3)
- a message-body must not be included when the specification of the request method does not allow sending an entity-body (section 4.3)

Now, when it comes to the so-called fully compliant servers and browsers that are stripping the message body on DELETE requests - I have never seen a statement in agular.js documentation where it is written that it should be only used with one or another set of clients/servers. Thinking outside of the box the shiny js library you are providing can be also used by custom clents and server configurations - are you not agree? I don't think a prerogative of any js library should be to force one or another protocol constraint - the way it will be used must be in the developer's hands. Talking about developers - I can't see nothing more natural when implementing a standard CRUD to use respectively POST, GET, PUT and DELETE and having those implemented with asame manner.

I still believe having this regex (in the $resource lib) that defines $hasBody only for certain HTTP methods is bad written and should be considered for refactoring.

[squid314]

I am not assuming anything that "has never been written." I am claiming that the outcome of including a message-body or an entity-body is not defined in the HTTP spec for a DELETE request. Therefore a fully compliant server can do anything they want regarding the body content (including ignore it or core dump or start a large number of small fires in Yugoslavia). I am also not claiming that AngularJS is written to target any specific clients/servers/proxies/grapefruits/etc. However, the $resource service is written on top of the $http service and the $http service "is a core Angular service that facilitates communication with the remote HTTP servers via the browser's XMLHttpRequest object or via JSONP." (Emphasis mine; see here for original.) Therefore, Angular's $http service must be written to work within the bounds of a fully compliant implementation of HTTP (on both the client and server side). If you are asking the AngularJS developers to start working outside the official specification of HTTP, that is effectively asking them to begin supporting the custom unpublished very-close-to-but-not-quite-HTTP that you use. I am not claiming that it wouldn't be nice/interesting/fun/etc. to have the $resource be able to support this slightly different protocol, but I am claiming that I don't believe that it is reasonable to ask the AngularJS developers to start supporting this slight modification of the HTTP spec. I hope this makes my position more clear. (Don't forget that you can create your own fork of the repository, make the modification that you believe should be applied, and use that version of the library, updating your fork when Angular makes updates.)

[npetrovski]

@squid314

Again,

1. Not defined does not necessary mean denied
2. It is written in the official and accepted RFC (the same one you quoted) that message body should not be included when the method does not allow it (and it is explicitly forbidden in TRACE requests)
3. I am not asking you guys start writing something that is outside of the official protocol specification, but just leave the protocol constraints to the web clients/servers to manage this. This wont make your lib inaccurate
4. Correct me if am I wrong, but angular's $http does not implement the same restrictions (stripping the message body on DELETE) and it is still fully compliant
5. and yes, thank you - I know I can fork and work my own version of $resource, but I guess this aint something I am targeting at the moment

Thank you for being responsive @squid314 . I believe I stated my point clear enough and if you guys don't want to accept it or have different understanding of how the RFC defines (or not defines) the problem it is totally up to you.

Good luck.

(there is no Yugoslavia anymore, the communism is over :P )

[squid314]

1., 2. I agree completely.
3. I'm not sure that I completely agree on this one, but that's okay.
4. So, I just looked through the code for the $http service (at least the version I have cloned). While it appears that the core $http service doesn't remove the post data from the request object before forwarding the request information to the underlying XMLHttpRequest, the shortcut methods like $http.delete don't include the post data while the shortcut methods like $http.post do include it. This means that you can attempt to submit a body as part of HEAD, DELETE, etc. requests if you set it up like $http(url, { method: 'delete', data: {blah: 'blah} }) rather than $http.delete(url, {blah: 'blah'}) (since the object is treated as the $http config hash). (I think that $http.delete(url, { data: {blah: 'blah'}}) will work but I'm not sure; probably easier to test it than walk through the code.) This information is mirrored in the docs for $http where put and post allow a data param but the rest of the shortcut methods don't.

(What? You don't think that I have equipped my web servers with time-travelling flamethrowers? Fine, you're right; I haven't. I just love the name, not sure why, and I keep forgetting that it is one of those no-longer-existing countries.)

[anton000]

+1

[pmariduena]

I know this is closed, but I think it should be added (I agree with @npetrovski). Maybe a custom property could be added to $resource (under "options", say "enableDeleteRequestBody"), with a warning that this is not the officially Spec-compliant use of a DELETE (use at your own risk). But I would really like to use it. It would allow for batch deletes of multiple, non-consecutive objects that represent, say, rows in a database. specifying those rowIds as, say, query string params in the URL, or request headers, is messy. Apache Jetty server is definitely accepting my DELETE body request that I send from POSTman.