HTTP OPTIONS method is intercepted by servlet #153

zooml opened this Issue Apr 3, 2013 · 10 comments


None yet
6 participants

zooml commented Apr 3, 2013

There is no way to implement the OPTIONS method unless HttpServlet#doOptions is overridden. Need some mechanism to do this. This is critical for CORS support of non-simple requests.


kares commented Apr 4, 2013

probably a setting for your application server - for our RackServlet we do override service thus we shall process all HTTP methods that would otherwise end up as doXXX ... if you're using RackFilter than it's probably a servlet container "issue" that it does not invoke doFilter on HTTP OPTIONS ...

patcheng commented Aug 3, 2013

Actually, I ran into the issue using RackFilter on trinidad. But I think the pull request would resolve the issue for servlet as well.


kares commented Feb 24, 2014

the referenced commits should handle this now ... they're in 1.1.14, thx and let us know in case we need to ... :)

kares closed this Feb 24, 2014

I was helping @jwinter in jruby IRC after he ran into this same issue with Tomcat and Jetty using JRuby-Rack 1.1.14. I dug into the code a bit, since I've had to fix this on TorqueBox in the past. It looks like commit a9c471f doesn't handle the case where RackFilter is being used on Tomcat (and probably Jetty). What happens is Tomcat ends up setting the Allow header (as shown in and thus the logic in that commit thinks the response has been handled. What we did in TorqueBox was add a special check to treat OPTIONS requests with an Allow header set as unhandled and pass them on to the Ruby code.

kares reopened this Mar 19, 2014


kares commented Mar 20, 2014

Thanks @bbrowning !

Seconds attempt at 592c17f

Turns out this one's tricky to test without tracking all headers or compiling against Servlet 3.0 (we're Servlet 2.5 ;( compatible for now) ... thus please @jwinter please do a rake clean gem from the 1.1-stable branch if it works for you.

jwinter commented Mar 21, 2014

@kares initial test looks good; it works in jetty now and I'll test against our Tomcat server in the morning. Thanks for the quick turnaround.

jwinter commented Mar 21, 2014

@kares This worked within our Tomcat server as well. This fixes the issue for me. Thanks again!


kares commented Mar 21, 2014

@jwinter great, thanks for verifying this for us ... fix will be in 1.1.15 (which might take a while - not sure yet)

kares closed this Mar 21, 2014

nurey commented Aug 13, 2014

How is it looking for the release of 1.1.15?


kares commented Aug 13, 2014

@nurey it got yanked, but I shall try 1.1.16 tomorrow or soonish (batling with travis-ci for now) ...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment