Hello. I just seen some errors in my mongrel application log: It seems related to the httpd OPTIONS keyword Example: Processing LoginController#login (for .30.5.208 at 2007-12-10 09:00:23) [OPTIONS] and our ruby application does not know what to do with it. and finally send an error Does mongrel (which is the http server) is supposed to deal with these kind of request ? I think these request are coming from a MS Front Page application, what other are doing when these requests happen ? Yves D''Astous
On Mon, 10 Dec 2007 13:38:19 -0500 Yves D''Astous <yves.dastous at intertrade.com> wrote:> Hello. > > I just seen some errors in my mongrel application log: > > It seems related to the httpd OPTIONS keyword > > Example: > Processing LoginController#login (for .30.5.208 at 2007-12-10 09:00:23) > [OPTIONS] > and our ruby application does not know what to do with it. and finally > send an error > > Does mongrel (which is the http server) is supposed to deal with these > kind of request ? > I think these request are coming from a MS Front Page application, what > other are doing when these requests happen ?If you need to tell options to remote servers then you can write the handler that returns them. Most applications don''t need this since they run rails, and usually the web app would have a different interpretation for each option they wanted. Otherwise, I suggest telling your front server to quit asking that. It''s dubious feature at best which doesn''t do anything for a proxy server situation. -- Zed A. Shaw - Hate: http://savingtheinternetwithhate.com/ - Good: http://www.zedshaw.com/ - Evil: http://yearofevil.com/
On Dec 10, 2007 11:38 AM, Yves D''Astous <yves.dastous at intertrade.com> wrote:> Does mongrel (which is the http server) is supposed to deal with these > kind of request ?Mongrel is the HTTP server, but _Mongrel_ itself should not be dealing with OPTIONS reqests. Mongrel doesn''t know what the correct answer is for a given request because the responsibility for handling a request falls onto the shoulders of some handler or other. In the case of a handler like DirHandler, which itself directly handles the request, it would make sense for the handler to return the response because the handler knows what is reasonable for a given request. However, in the case of a handler like the RailsHandler, where the handler just passes control to another entity (the application), that entity is the only thing that can return a meaningful response to an OPTIONS request -- the handler doesn''t know what the application is willing to handle for a given request. I think that the value in changing the standard Mongrel handlers, like DirHandler, to deal with OPTIONS is meager, at best, though. As easy as it is in Ruby to either subclass or just reopen a class and change parts of it, I''d suggest that if one really _needs_ to do something like handle OPTIONS, that they just create a custom handler for their application which will do so in a way that makes sense for them. And if your Rails app really needs to handle OPTIONS, can''t you just do that? Kirk Haines
On Dec 11, 2007 10:50 AM, Kirk Haines <wyhaines at gmail.com> wrote:> And if your Rails app really needs to handle OPTIONS, can''t you just do that?I''ve heard of using OPTIONS requests to monitor HTTP servers, on the assumption that it''s a really cheap operation with no side effects. But never saw it firsthand.> I think that the value in changing the standard Mongrel handlers, like DirHandler, to deal with OPTIONS is meager, at best, though.+1 -- Alexey Verkhovsky CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com] RubyWorks [http://rubyworks.thoughtworks.com]
On Dec 11, 2007 3:47 PM, Alexey Verkhovsky <alexey.verkhovsky at gmail.com> wrote:> On Dec 11, 2007 10:50 AM, Kirk Haines <wyhaines at gmail.com> wrote: > > And if your Rails app really needs to handle OPTIONS, can''t you just do that? > > I''ve heard of using OPTIONS requests to monitor HTTP servers, on the > assumption that it''s a really cheap operation with no side effects. > But never saw it firsthand.Yeah. Using an asterisk as the request uri. That''s the only OPTIONS request that I can see an argument for Mongrel directly supporting. Does anyone know of any concrete examples where that use case is necessary or desireable? Kirk Haines