403 Forbidden on PUT #105

Closed
dwoodjungroup opened this Issue May 9, 2012 · 10 comments

Comments

Projects
None yet
3 participants

We see 403 Forbidden errors from Tomcat on attempts to PUT. Routing and Tomcat 7 config are standard and this works in webrick, but is broken upon warbling.

Investigation eventually yielded this:

http://stackoverflow.com/questions/9624499/does-the-jruby-rack-servlet-container-support-put-delete

We confirmed that the workaround of downgrading from 1.1.5 to 1.1.4 does fix the problem.

This appears to be a regression in jruby-rack 1.1.5.

Owner

kares commented May 9, 2012

oh I see, we refactored the chain handling with the RackFilter so it can return "errors" from the chain above and not proceed with dispatching to rack/rails - thus only HTTP 404 is assumed as a valid outcome to proceed dispatching (previously all >= 400 where) ... and so it seems Tomcat by default handles "unknown" PUTs as 403 instead thus I probably have to make a proceed error list and add it as a default.
it makes me wonder how other containers deal with PUTs by default ...

If I had to speculate, I'd say PUT, DELETE, etc. would historically be considered "esoteric" HTTP verbs by most users of Tomcat.

May I suggest pulling 1.1.5 from general release? Those verbs are exactly the opposite of esoteric for users of Rails...

Owner

nicksieger commented May 9, 2012

Hmm, that's curious. Any guesses as to which of these commits might be the culprit? Would you able to check out source and run git bisect?

Owner

kares commented May 9, 2012

@nicksieger I already have the fix locally just testing things out more before pushing.
also I do not thing we do need to yank a release that's been out a while - most of the time rails emulates PUT with POST anyway. we'll release 1.1.6 soonish ... I'd like to close #104 as well but if it's that much of a hustle we can do a quick release after this getting closed.

kares was assigned May 9, 2012

Owner

kares commented May 9, 2012

for the record it got introduced with be12c1e as part of the effort in allowing errors to bubble down from the filter chain instead of all getting swallowed. this was part of the request that we do not reset the response as an outcome from the chain (#97).
I'll also add the possibility to configure which statuses should be considered "unhandled" - by default 403 and 404.

Owner

nicksieger commented May 9, 2012

Great, thanks @kares!

kares closed this in c42ee20 May 9, 2012

Owner

nicksieger commented May 11, 2012

@kares I'd say a 1.1.6 sometime next week would be great. If we can make progress on #104, great, but I think this fix warrants a new release sooner than later. Do you have everything you need to perform the release yourself?

Owner

kares commented May 11, 2012

@nicksieger you're right, feel free to release anytime you want. it seems there's no reply from the reporter on #104 I tried reproducing and have a few more "rewindable" specs locally but so far no luck ...

Owner

kares commented May 16, 2012

1.1.6 released with this single fix - the issue was reproduced and verified to be fixed on Tomcat 6.0.x

I can confirm this build has resolved our problem. Thank you!!!

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