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.
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 ...
Actually, I ran into the issue using RackFilter on trinidad. But I think the pull request would resolve the issue for servlet as well.
response capture should not be considered handled by default - right?!
(related to #153)
when a header is added response should be considered handled (fixes #153
the referenced commits should handle this now ... they're in 1.1.14, thx and let us know in case we need to ... :)
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 https://gist.github.com/jwinter/7c660e16ccef4d6ad5d8) 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.
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.
rake clean gem
@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.
@kares This worked within our Tomcat server as well. This fixes the issue for me. Thanks again!
@jwinter great, thanks for verifying this for us ... fix will be in 1.1.15 (which might take a while - not sure yet)
How is it looking for the release of 1.1.15?
@nurey it got yanked, but I shall try 1.1.16 tomorrow or soonish (batling with travis-ci for now) ...