REST-Interface does not send PUT/DELETE but OPTIONS

tcebulla

Hi there,


I have the following code which should trigger different http methods for each action:
[code]
editor = new $.fn.dataTable.Editor( {
"ajaxUrl": {
"create": "POST http://uri/app.servers.ServerController?format=DataTables",
"edit": "PUT http://uri/app.servers.ServerController?format=DataTables",
"remove": "DELETE http://uri/app.servers.ServerController?format=DataTables",
},
[/code]

The requests for edit and remove do not send the PUT or DELETE request method but OPTIONS which seems to be wrong from my point of view. How can I change the OPTIONS method into PUT or DELETE request methods?


Regards

allan

I'd fully agree `OPTIONS` is wrong there. I've just tried out my example here ( http://editor.datatables.net/release/DataTables/extras/Editor/examples/REST.html ) and it appears to be using the correct HTTP method.

Can you link me to a test case which shows the problem please?

One thing that stands out to me, is that it looks like you are using an absolute URL and thus might be running into cross domain scripting problems?

Allan

tcebulla

Unfortunately I cannot give you a link to the site because it resides in the private network of the company I'm working at. What I can give you is the full (without js and css) HTML-source of that page: http://pastebin.com/N20ASFvW

When firing the edit and delete events both are sent with http request method 'OPTIONS' (seen via firebug) - funnily enough the source of the example code seems to be the same (to me) but fires the correct request methods.


What I also saw (in firebug) was, that no more parameters are being sent (I thought the full row data would be transferred in some way?) when firing POST, PUT and DELETE events.
I really like DataTables and I think about buying the Editor plugin, but I try for 2 days now and this does struck my nerves =/


Hope you can help me!


Regards


PS: yep you we're right, the frontend is on another domain as the REST-API (which is my own by the way - so I did not use the one that comes with the Editor plugin), but it has the cross-domain feature enabled in the http headers.

allan

Could you possibly try it in Chrome please, and have a look at the 'Network' tab there - just to sanity check. I can't understand why it would be sending OPTIONS...!

Thanks,
Allan

tcebulla

I've tested this in chromium/chrome (23.0.1271.97) and firefox (14.0.1) - both browsers do send the OPTIONS method. I will try reinstalling DataTables and all related libs tomorrow, respectively I will use the sources from the datatables.net website.

If you have any other idea what could cause this behaviour ...

Regards


EDIT: Here is a screenshot: http://s1.directupload.net/file/d/3142/me7db7vu_png.htm

allan

I wonder if there is some sort of preflighting by the browser for the cross domain request going on. Your screenshot shows 'Access-Control-Request-Method' being `PUT` which is what would would be expected.

Actually - looking into it a bit more, this appears to be exactly what is happening. From the MDN page on the subject ( https://developer.mozilla.org/en-US/docs/HTTP/Access_control_CORS ):

> the specification mandates that browsers "preflight" the request, soliciting supported methods from the server with an HTTP OPTIONS request header, and then, upon "approval" from the server, sending the actual request with the actual HTTP request method

So the options is required - presumably to check that a cross domain request is possible. I guess your REST interface will need to implement this to be able to work with cross domain requests.

Allan

tcebulla

Hell yeah :D
The problem was the cross-domain request - I moved the API to the same document root - now the PUT-request is being sent. Thank you for that hint :)

I don't know if your PHP-API does support cross-domain request - if not you need to return the 'Access-Control-Allow-Headers' header with all (uppercased) allowed request methods, including OPTIONS that are supported by the API. Then there are sent 2 requests to the API - first OPTIONS to check if the API does support the request method and then PUT/DELETE/WHATEVER.

Hope that this will help another one who is facing the same problem.


Regards

allan

Excellent point - I'll look into adding this as an option to the Editor PHP API.

Regards,
Allan

tcebulla

I've got two question remaining which are somehow related to this.


1. When sending a DELETE-request the parameters are being sent to STDIN:
string(36) "action=remove&table=&id=&data%5B%5D="

But I am looking for some data in the data-hash - why is it empty? I would only need the id of the record/row which is stored in "server_id" but not in "DT_rowid" - how can i change that?



2. When sending a POST (create), PUT (update) or DELETE (delete) request, which response does the DataTables plugin expect?

allan

> I would only need the id of the record/row which is stored in "server_id" but not in "DT_rowid" - how can i change that?

Editor 1.2.3 will include a new option called `idSrc` which allows you to set the object property to something other than DT_RowId for where the row id is stored. There isn't an option to override it in 1.2.2-.

> 2. When sending a POST (create), PUT (update) or DELETE (delete) request, which response does the DataTables plugin expect?

The client/server communication for Editor is detailed here: http://editor.datatables.net/server/ . There are examples at the bottom of the page. Also all of the examples on the Editor site have an "Ajax data" tab which you can use to see the data that is sent / received on those pages.

Allan

tcebulla

Okay, thank you :)
By the way, the documentation is very detailed - but hard to find =/

Last question: When is the release date of Editor 1.2.3?

allan

Editor 1.2.3 is expected by the end of the month :-).

Allan