Mongrel and http 1.1 OPTIONS keyword

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 Dec 10, 2007 11:38 AM, Yves D’Astous [email protected]
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 H.

On Dec 11, 2007 10:50 AM, Kirk H. [email protected] 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 V.
CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com]
RubyWorks [http://rubyworks.thoughtworks.com]

On Dec 11, 2007 3:47 PM, Alexey V. [email protected]
wrote:

On Dec 11, 2007 10:50 AM, Kirk H. [email protected] 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 H.