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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On Nov 4, 2008, at 9:28 AM, gummybears wrote:> > 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.> 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 > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
> 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:> 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.-- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
> 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 PROPFINDP.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-- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On Nov 4, 2008, at 11:02 AM, Robert Walker wrote:> >> 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.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. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On 4 nov, 22:13, Philip Hallstrom <phi...-LSG90OXdqQE@public.gmane.org> wrote:> On Nov 4, 2008, at 11:02 AM, Robert Walker wrote: > > > > >> 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. > > 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. I can ask my future ISP --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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 4 nov, 22:13, Philip Hallstrom <phi...-LSG90OXdqQE@public.gmane.org> wrote:> On Nov 4, 2008, at 11:02 AM, Robert Walker wrote: > > > > >> 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. > > 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.--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---