$.ajax DELETE request not passing data parameters

[chapman.cliff@…]

Version 1.7.2 Firefox 11

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

$.ajax({

type:"DELETE", data:{"var":"val"}, url:"test.php"

})

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

test.php?var=val

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

 http://stackoverflow.com/questions/4018982/ajax-ignoring-data-param-for-delete-requests

According to the RFC this should be perfectly allowable.

 http://tools.ietf.org/html/rfc2616#section-9.7

Discussed on IRC and came to no conclusions.

[dmethvin]

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

 http://stackoverflow.com/questions/299628/is-an-entity-body-allowed-for-an-http-delete-request

 http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-19#page-23

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?

[chapman.cliff@…]

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.

 https://github.com/jquery/jquery/commit/09022e0b09db71259751e7146bb64727615028af

[dmethvin]

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")?

[jaubourg]

Yep, there seems to be some confusion here, seeing that rnoContent did *not* change:  https://github.com/jquery/jquery/blob/master/src/ajax.js#L11

[anonymous]

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.

[dmethvin]

Sweet, it's working then.

[jhancockdarwin@…]

I believe that this ticket should be reopened.

IIS/MVC.net/ASP.NET 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.

[dmethvin]

@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.

[jhancockdarwin@…]

9.7 DELETE

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.

[dmethvin]

Just to link, you're quoting  http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.7

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

[Dave Methvin]

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

Changeset: c01e022f33575ed45fb8da65be756fc464d40a24

[jaubourg]

We're going back and forth here, this is breaking since we did it that way purposedly: http://bugs.jquery.com/ticket/7285

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 ;)

[dmethvin]

@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?

[jaubourg]

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 ;)

[Dave Methvin]

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 http://bugs.jquery.com/ticket/7285 .

Changeset: 05337e78fa68aac3a3d703d7cc59f145f13ea779

[dmethvin]

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.

[jaubourg]

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.

[jaubourg]

Duplicate of #7285.