Wrong behavior if delete request receives redirect response

[hading]

If one makes a DELETE request and receives a redirect as a response then Mechanize follows the redirect, but as a GET.

Per Eric Hodel:

According to RFC 2616 section 10.3 only GET and HEAD requests may follow redirects.

So it should not follow at all.

I raise the issue as I'm using a commercial product that may issue a redirect in response to a DELETE and expects me to issue a new DELETE to the location specified by the redirect. So I'd love if Mechanize provided some sort of hook to enable that to happen, whether it be raising an exception or setting a flag in some way that I could check to see if I got a redirect and providing a way to extract the new location and reissue the request, or (I'm sure less optimal from your point of view) a way to configure the non-standard behavior for anyone who wanted it.

[leejarvis]

Adding some info here

tests to update: test_mechanize.rb lines 283 (DELETE), 952 (PUT), 938 (POST)

@drbrain Thoughts on returns for a Net::HTTPRedirection on everything but Net::HTTP::Get or Net::HTTP::Head?

[drbrain]

We should follow RFC 2616 in this manner, if we get a redirect response when we didn't issue a GET or HEAD we should return some special type of response for the user to follow manually.

[leejarvis]

@drbrain Can you review that commit, am I missing anything?

[drbrain]

I thought I could CC this issue from the commit, but I can't. Looks great!

[bradleybuda]

This change breaks many real websites (I can provide examples - I have a script that logs into Campfire that breaks with this change). While you're correctly following the RFC, all of the major browsers follow a 302 redirect after a POST as well. The RFC defines codes 303 and 307 to disambiguate this case, and further notes that the standard is different than most actual implementations: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html (see the note under "302 Found").

You're absolutely right that this follows the standard more closely, but if the goal of Mechanize is to act like a real browser, this is a step in the wrong direction.

[drbrain]

Oops, I did not read the change close enough, you are right.

We're only allowed to GET or HEAD after redirect on POST, DELETE, etc., not POST or DELETE after redirect so we should change the method to GET when redirecting (unless the request was HEAD).

[leejarvis]

The point is that we don't follow a redirect anyway unless its a HEAD or
GET request. So there's conflicts in standards. Either we follow the RFC to
the letter and never redirect non head/get requests (which breaks existing
apps) or we follow the redirect but using a GET instead of the original
request method?

On 8 Feb 2013, at 22:56, Eric Hodel notifications@github.com wrote:

Oops, I did not read the chance close enough, you are right.

We're only allowed to GET or HEAD after redirect on POST, DELETE, etc., not
POST or DELETE after redirect so we should change the method to GET when
redirecting (unless the request was HEAD).

—
Reply to this email directly or view it on
GitHubhttps://github.com//issues/281#issuecomment-13317995..

[muescha]

i think we should behave like more browsers.

and for the special use case of the issue opener (no redirects at posts) can be solved with the original unchanged code with the option {{@redirect_ok}} set to false

see:

mechanize/lib/mechanize/http/agent.rb

Line 936 in 71602a5

return page

this option let also return the page like its done in the patch 71602a5

[leejarvis]

Yeah, @drbrain should we just revert 71602a5 (the behaviour that can still be achieved using redirect_ok) and continue with the existing code (which follows redirects with a GET)

[drbrain]

Just for clarification:

> DELETE /foo
< 303 See Other, Location: /
> GET /
< 200 OK

is OK, but:

> DELETE /foo
< 303 See Other, Location: /
> DELETE /
< …

is NOT OK

[leejarvis]

@drbrain Yeah from what I can see, this is exactly what happened before. Reverting my changes should resolve this which discards the original issues request.

[leejarvis]

Can we close this? I reverted the altered code, as it appears Mechanize already behaves as we're discussing it should.