ISP denies HTTP DELETE in httpd.conf ?

Hi,

I discovered that my webhoster denies HTTP delete's. They suggest I can do the same via HTTP get's. As I explained to them I am using their Rails framework via REST and CRUD, it seems either they don't know what they are doing or I have to do some serious thinking.

As I am developing an web application where users can create/edit/ delete records in a database table, I thought by using the REST method, I was following RoR guidelines.

My question is this, are they correct in saying I can use get's instead of delete's ?

P.S Their comment was, DELETE's are very old, you can do the same with GET's, but the HTTP return code is different. They only allow the following requests GET POST OPTIONS PROPFIND

TIA

Hi,

I discovered that my webhoster denies HTTP delete's. They suggest I can do the same via HTTP get's. As I explained to them I am using their Rails framework via REST and CRUD, it seems either they don't know what they are doing or I have to do some serious thinking.

As I am developing an web application where users can create/edit/ delete records in a database table, I thought by using the REST method, I was following RoR guidelines.

My question is this, are they correct in saying I can use get's instead of delete's ?

If your users are interacting with your site via a web browser then
all the requests will be either GET or POST and Rails sneaks in a
hidden parameter to set the actual verb (ie. the DELETE you want).

If it's a RESTful client that really speaks REST then you're gonna be
in trouble.

That's my understanding anyway.

If it's a RESTful client that really speaks REST then you're gonna be in trouble.

Why would he be in trouble? What would stop him from sneaking in the same parameter into a POST request just like Rails does?

Verb & URL: POST /resources/1

Parameters: _method=DELETE

Would that not work? I'm not sure since I haven't tried it.

Philip Hallstrom wrote:

P.S Their comment was, DELETE's are very old, you can do the same with GET's, but the HTTP return code is different. They only allow the following requests GET POST OPTIONS PROPFIND

P.P.S. They are very uninformed. DELETE has always been, and continues, to be an integral part of HTTP. Web browser vendors have just been too damn lazy to implement the full HTTP protocol. I'd say the opposite it true. We are now finally getting around to actually using HTTP the way it was intended to be used from the start.

It's like saying, "Don't ask me to delete a thing, instead ask me to get it. But, if you really want me to delete it, wink at me when you ask."

P.P.P.S I would ask them to explain this section of the HTTP 1.1 specification:

Because a real RESTful client would want to say "DELETE /resources/1" and not mess around with the hacks to trick web browsers into being able to simulate REST by passing _method.

But, if all his users are using web browsers he's fine.

First, thanks to all for their answers/comments.

I think I am out of luck, my ISP is not supporting the DELETE, period. Either I try including the _method=DELETE or perhaps to construct a rewrite rule in .htaccess to get around the problem. Lastly as I was also experiencing other issues with my current ISP (no ssh support, they say it's unsafe, only ftp support) so I was thinking to move to another ISP. Hopefully their web environment is better suited for the things I am trying to accomplish.

BTW I updated my code to use the POST request with the extra parameter _method=DELETE. This works, the right controller is called with the correct params and action. But in the Rails log I am also seeing extra parameters passed on (things like /:controller/:id.html/:id => nil), something to do how Apache/fcgi passes the request to Rails (rewrite rules in .htaccess)

gummybears wrote:

Lastly as I was also experiencing other issues with my current ISP (no ssh support, they say it's unsafe, only ftp support)

Time to get a service provider that has a clue perhaps ?

ssh is unsafe if you don't know how to set it up properly. A chrooted scp only environment is trivial to setup and far far more secure than an ftp one.

I would venture that the majority of internet facing servers are accessed primarily by ssh - it's safe.