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
On Nov 4, 2008, at 9:28 AM, gummybears wrote:
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 H. wrote:
On Nov 4, 2008, at 9:28 AM, gummybears wrote:
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.
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:
9.1.1 Safe Methods
Implementors should be aware that the software represents the user in
their interactions over the Internet, and should be careful to allow the
user to be aware of any actions they might take which may have an
unexpected significance to themselves or others.
In particular, the convention has been established that the GET and HEAD
methods SHOULD NOT have the significance of taking an action other than
retrieval. These methods ought to be considered “safe”. This allows user
agents to represent other methods, such as POST, PUT and DELETE, in a
special way, so that the user is made aware of the fact that a possibly
unsafe action is being requested.
Naturally, it is not possible to ensure that the server does not
generate side-effects as a result of performing a GET request; in fact,
some dynamic resources consider that a feature. The important
distinction here is that the user did not request the side-effects, so
therefore cannot be held accountable for them.
gummybears 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
On 4 nov, 22:13, Philip H. [email protected] wrote:
POST /resources/1
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.
I can ask my future ISP
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)
On Nov 4, 2008, at 11:02 AM, Robert W. wrote:
_method=DELETE
Would that not work? I’m not sure since I haven’t tried it.
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.
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.