Skip to main content

Bug Tracker

Side navigation

#11586 closed bug (duplicate)

Opened April 12, 2012 02:44PM UTC

Closed August 24, 2012 04:11PM UTC

Last modified December 28, 2013 10:16PM UTC

$.ajax DELETE request not passing data parameters

Reported by: Owned by:
Priority: low Milestone: None
Component: ajax Version: 1.7.2
Keywords: Cc: jaubourg
Blocked by: Blocking:

Version 1.7.2

Firefox 11

$.ajax when type:"DELETE" will drop any data parameters involved. e.g.:






FireBug will show the request being sent with no parameters. Manually appending the parameter to the url will send correctly, e.g.:


For obvious reasons I really don't want to do that. According to this StackOverflow post, version 1.4.4 allowed for this.

According to the RFC this should be perfectly allowable.

Discussed on IRC and came to no conclusions.

Attachments (0)
Change History (22)

Changed April 12, 2012 02:55PM UTC by dmethvin comment:1

component: unfiledajax
priority: undecidedlow
status: newopen

I dunno, the RFC isn't that clear about whether the args should be on the URL or in an entity body. Further info:

If the method CAN accept an entity body, then the data should be going there and not the URL. Perhaps the data is going into an entity body but it's being thrown away by Firefox?

Changed April 12, 2012 03:28PM UTC by comment:2

I'm fairly new to JavaScript and am investigating how to set up an AJAX request in raw JS to test it outside of jQuery. I would still point out that a commit (made by yourself) a year ago was meant to allow this, but current functionality shows it is not working.

Changed April 12, 2012 03:43PM UTC by dmethvin comment:3

OK, then, thanks for the reminder! Your post above seems to indicate you're expecting the data to be on the URL. If my post from a year ago is correct (and it seems to agree with those links) then the data should be in the entity body and not the URL. Is that what you expected? Are you seeing Firefox send it in the entity body ("POST data")?

Changed April 12, 2012 03:46PM UTC by jaubourg comment:4

Yep, there seems to be some confusion here, seeing that rnoContent did *not* change:

Changed April 12, 2012 04:02PM UTC by anonymous comment:5

I managed to get a mock up written by manually creating am XMLHttpRequest, FireBug was showing the data being sent in the body and NOT the URL. The URL system simply worked.. somewhat, with minor modification on the server side.

So yes, sending the data in the entity body seems to be the correct route.

Changed April 12, 2012 04:51PM UTC by dmethvin comment:6

resolution: → worksforme
status: openclosed

Sweet, it's working then.

Changed May 21, 2012 02:41PM UTC by comment:7

I believe that this ticket should be reopened.

IIS/ cannot parse parameters passed in the body of DELETE request.

Google web hosting returns BADREQUEST.

Amazon hosting returns BADREQUEST

The RFC clearly states that all delete values should be passed in the URI.

jQuery should be converting the data passed to the URI.

Changed May 21, 2012 03:16PM UTC by dmethvin comment:8

@jhancockdarwin can you quote the specific part of the RFC? My impression was that DELETE could have a body. As things stand now you can encode parameters in the URL yourself, but if we reverse it there would be no way to send a body.

Changed July 25, 2012 06:51PM UTC by comment:9


The DELETE method requests that the origin server delete the resource

identified by the Request-URI. ....

Note that it clearly states that the resource must be identified by the URI, not the body. This is why most major servers will not allow a body on a DELETE request and either ignore it, or throw an error (and firebug does the right thing by ignoring it)

DELETE works exactly the same as GET. All data should be passed as parameters on the URI as specified by the RFC.

Changed July 25, 2012 07:06PM UTC by dmethvin comment:10

_comment0: Just to link, you're quoting \ \ I'll reopen, but at this point it's too late for 1.8 I think.1345771952601787
resolution: worksforme
status: closedreopened

Just to link, you're quoting

I'll reopen, but at this point it's too late for 1.8 I think.

Changed July 25, 2012 07:06PM UTC by dmethvin comment:11

cc: → jaubourg
status: reopenedopen

Changed August 24, 2012 01:34AM UTC by Dave Methvin comment:12

resolution: → fixed
status: openclosed

Fix #11586. Ajax DELETE ain't got no body, so data goes to its URL.

Changeset: c01e022f33575ed45fb8da65be756fc464d40a24

Changed August 24, 2012 10:20AM UTC by jaubourg comment:13

We're going back and forth here, this is breaking since we did it that way purposedly:

It seems to me the previous behaviour was better. The spec doesn't say there shouldn't be a body, it says the resource should be identified in the URI which doesn't forbid to add additional data in the body. That some implementations decide to ignore it is irrelevant here.

With the previous behaviour, you could handle the identification within the URL and give a body. Now we're just being more strict than the standard, which never ended well for us ;)

Changed August 24, 2012 12:55PM UTC by dmethvin comment:14

@jaubourg, your memory and/or search skills exceed mine. It seems that according to this ticket several very popular implementations specifically forbid a body so perhaps that is a good enough reason?

Changed August 24, 2012 02:20PM UTC by jaubourg comment:15

Except said implementations are not standard: they shouldn't break on a DELETE with a body, they simply can (and probably should) ignore said body.

All I'm saying is that the previous fix allowed DELETE requests with or without a body, which is standard compliant. The fix in this ticket specifically forbids DELETE requests with a body and doesn't add any actual feature (you could already add data to the URL manually).

I'd say the safest way is probably to keep the less restrictive approach. There is more to data you can send using a request than resource identification alone, timing, security and debugging info come to mind (especially for a destructive operation such as a DELETE).

Let's not paint ourselves in a corner with the risk of going back and forth again in yet another minor version. If we want to look into this seriously, let's 1.9-discuss it.

(Just some quick searching in the tracker btw, because it rang a bell. So half-memory/half-search I guess ;)

Changed August 24, 2012 04:01PM UTC by Dave Methvin comment:16

Revert "Fix #11586. Ajax DELETE ain't got no body, so data goes to its URL."

This reverts commit c01e022f33575ed45fb8da65be756fc464d40a24.

We actually changed DELETE to accept a body on purpose, see .

Changeset: 05337e78fa68aac3a3d703d7cc59f145f13ea779

Changed August 24, 2012 04:02PM UTC by dmethvin comment:17

Agreed, jaubourg. If I had seen the earlier ticket I wouldn't have pursued this, so I've backed it out. Anyone who wants to send the DELETE request in the URL already has the tools to do so.

Can you review the tickets in your usual haunts and see if any need changes? You can probably do that faster and better than I can. I'm only leaving tickets open if I think they need action, so this ticket fit into that category.

Changed August 24, 2012 04:10PM UTC by jaubourg comment:18

resolution: fixed
status: closedreopened

I'll try to be more attentive next time. I see the ticket was created on April the 12th (my birthday) which could explain a lot ;)

I also tend to leave tickets open in case someone else would chime in, but I think it's probably a mistake and I should start closing bugs more often and pre-emptively. We can always re-open them anyway.

Sorry about my missing this one earlier btw.

Changed August 24, 2012 04:11PM UTC by jaubourg comment:19

resolution: → duplicate
status: reopenedclosed

Duplicate of #7285.

Changed August 15, 2013 05:18PM UTC by bharbulot comment:20

While we can discussed whether a body is allowed at all in a DELETE request, it doesn't make any sense to do so.

The StackOverflow question used to justify this change in #7285 states it clearly:

the request URI should completely identify the resource to delete.

This is also quite clearly in the HTTP specification:

The DELETE method requests that the origin server delete the resource identified by the Request-URI.

Therefore, you can't put anything that's going to help identify what to delete in the body.

If you send a

request to
, whether the content of the body is
doesn't matter, it's the resource solely identified by
that should be deleted.

While the HTTP specification may tolerate a body in a

request, the spec doesn't really leave much room to do anything with it. (Metadata belongs to the headers anyway.)

This is the same argument as for HTTP

. Quoting Roy Fielding:

Yes. In other words, any HTTP request message is allowed to contain a message body, and thus must parse messages with that in mind. Server semantics for GET, however, are restricted such that a body, if any, has no semantic meaning to the request. The requirements on parsing are separate from the requirements on method semantics. So, yes, you can send a body with GET, and no, it is never useful to do so. This is part of the layered design of HTTP/1.1 that will become clear again once the spec is partitioned (work in progress).

In contrast,
is a different URI from
, which identifies a different resource.

Hence, it would make much more sense to pass the data as query parameters (like

does) instead of passing them in the body.

Changed November 14, 2013 10:12PM UTC by comment:21

So I've worked my way through the entire path and I still don't know ... if a Delete request has a body, is there a way for the service code to see it?

We are designing an industry-wide REST standard and at this point have been told in order to have a single request delete multiple objects who's refIds are in a list we should:

1. Put the list as query parameters in the URL

2. Use X-HTTP-Method-Override set to Delete, in a POST, where the body contains the list and the HTTP field says it's really a delete.

3. Use a 2-step approach - send the list as a post, get back a URL and then send a delete to that URL

4. Put the list in the payload of the delete and assume the service accepts it, because most development platforms today accept it.

Unfortunately we need to standardize on one of these for all adapters, and are probably going with #4. I need to know if your service platform will support that or has to be explicitly flagged. Much thanks for any response or clarification here.

Changed December 28, 2013 10:16PM UTC by comment:22

So, I have to delete an object which is under the control of an optimistic locking protocol.

As you can imagine, every change on the object updates its version, and when I try to update that object I have to tell the server which version I have, so it knows that I'm dealing with the latest information before making my change, or it informs me that my object is out of date and leaves me to refresh it if I please.

So, the version shouldn't be part of the URI, because the object's identity isn't changing. I don't think it belongs in the query string, because I'm issuing updates against a specific object, not search results, so the query string shouldn't exist. I can put the version in the headers, but the headers are used by the server for routing and meta-processing and probably shouldn't be passed into the business logic. The only place left is to have the object I'm modifying sent along with the delete command. Then the server is free to use it to determine the version any way it wishes.

Or, is this all wrong? Only, I can't do this at the moment -- I have to hack the version into the meta-data somehow.