Hi, I''m a fairly new user of mechanize and for the most part it''s working out well for me. I do have a question though. We have a system where when sometimes when sending a delete request the system will send a redirect and we then need to delete as specified by the redirect. However, doing this naively with Mechanize results in the initial delete being sent correctly, the redirect being received, and then a second request being issued but as a GET instead of a DELETE. Is there any automatic way to get mechanize to reissue a DELETE to the redirect location, or do I have to do things more manually (e.g. don''t follow redirects, read the code manually, and reissue manually if I get a redirect)? Thanks, Howard Howard Ding Visiting Research Programmer 135 Grainger Engineering Library 217-300-1763 / hding2 at illinois.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/mechanize-users/attachments/20121206/473e0034/attachment.html>
On Dec 6, 2012, at 9:26, "Ding, Howard Adrian" <hding2 at illinois.edu> wrote:> Is there any automatic way to get mechanize to reissue a DELETE to the redirect location, or do I have to do things more manually (e.g. don''t follow redirects, read the code manually, and reissue manually if I get a redirect)? >According to RFC 2616 section 10.3 only GET and HEAD requests may follow redirects. So there is a bug here in mechanize, it should not make a GET request to the Location returned, but we cannot automatically reissue the DELETE. (At least the extra GET will be harmless for HTTP-compliant applications.) Can you create an issue on https://github.com/sparklemotion/mechanize? If we return some kind of redirect pending response for you DELETE redirect it will make it easier to implement your application-specific behavior, at least. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/mechanize-users/attachments/20121206/65bdafee/attachment.html>
It may well be that the particular product we''re using this with is not conforming with the spec, but that''s what we have. I''ll find some time to put an issue in, but I may also fork (at least temporarily) and make it work as we need for our purposes. Thanks, Howard Howard Ding Visiting Research Programmer 135 Grainger Engineering Library 217-300-1763 / hding2 at illinois.edu From: mechanize-users-bounces at rubyforge.org [mailto:mechanize-users-bounces at rubyforge.org] On Behalf Of Eric Hodel Sent: Thursday, December 06, 2012 1:38 PM To: Ruby Mechanize Users List Subject: Re: [Mechanize-users] redirect with DELETE question On Dec 6, 2012, at 9:26, "Ding, Howard Adrian" <hding2 at illinois.edu<mailto:hding2 at illinois.edu>> wrote: Is there any automatic way to get mechanize to reissue a DELETE to the redirect location, or do I have to do things more manually (e.g. don''t follow redirects, read the code manually, and reissue manually if I get a redirect)? According to RFC 2616 section 10.3 only GET and HEAD requests may follow redirects. So there is a bug here in mechanize, it should not make a GET request to the Location returned, but we cannot automatically reissue the DELETE. (At least the extra GET will be harmless for HTTP-compliant applications.) Can you create an issue on https://github.com/sparklemotion/mechanize? If we return some kind of redirect pending response for you DELETE redirect it will make it easier to implement your application-specific behavior, at least. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/mechanize-users/attachments/20121206/62b7c72b/attachment-0001.html>
Howard,
This is the section of the code you would need to modify:
https://github.com/sparklemotion/mechanize/blob/master/lib/mechanize/http/agent.rb#L926-L953
I like Eric''s suggestion of having some form of "redirect
confirmation"
callback or return value, however.
"
If the 301 status code is received in response to a request other
than GET or HEAD, the user agent MUST NOT automatically redirect the
request unless it can be confirmed by the user, since this might
change the conditions under which the request was issued.
Note: When automatically redirecting a POST request after
receiving a 301 status code, some existing HTTP/1.0 user agents
will erroneously change it into a GET request.
" - http://www.ietf.org/rfc/rfc2616.txt
Since mechanize is acting as both user-agent and deciding user in this
case, I think it makes sense to provide some scriptability of
this behavior.
-Tim
On Thu, Dec 6, 2012 at 2:37 PM, Eric Hodel <drbrain at segment7.net>
wrote:
> On Dec 6, 2012, at 9:26, "Ding, Howard Adrian" <hding2 at
illinois.edu>
> wrote:
>
> Is there any automatic way to get mechanize to reissue a DELETE to the
> redirect location, or do I have to do things more manually (e.g.
don''t
> follow redirects, read the code manually, and reissue manually if I get a
> redirect)?
>
> According to RFC 2616 section 10.3 only GET and HEAD requests may follow
> redirects.
>
> So there is a bug here in mechanize, it should not make a GET request to
> the Location returned, but we cannot automatically reissue the DELETE. (At
> least the extra GET will be harmless for HTTP-compliant applications.)
>
> Can you create an issue on https://github.com/sparklemotion/mechanize? If
> we return some kind of redirect pending response for you DELETE redirect it
> will make it easier to implement your application-specific behavior, at
> least.
>
> _______________________________________________
> Mechanize-users mailing list
> Mechanize-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mechanize-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/mechanize-users/attachments/20121206/1559ca90/attachment.html>
On Dec 6, 2012, at 11:41, "Ding, Howard Adrian" <hding2 at illinois.edu> wrote:> It may well be that the particular product we''re using this with is not conforming with the spec, but that''s what we have.Your server is spec-compliant, but there are restrictions on what mechanize may do. It''s fine for the server to return a redirect for a DELETE request, but it''s not fine for a general-purpose user-agent like mechanize to automatically send a DELETE to the redirect location. If you build something atop mechanize that has application-specific knowledge, it''s fine for that program to automatically DELETE the redirect location.
That''s fine. I''m reporting the issue now and if Mechanize can provide a compliant way to deal with this in the future I''ll be fine, and for my purposes now I''ll just fork it and make it an agent specific to our application here. :-) Thanks, Howard Howard Ding Visiting Research Programmer 135 Grainger Engineering Library 217-300-1763 / hding2 at illinois.edu -----Original Message----- From: mechanize-users-bounces at rubyforge.org [mailto:mechanize-users-bounces at rubyforge.org] On Behalf Of Eric Hodel Sent: Thursday, December 06, 2012 2:14 PM To: Ruby Mechanize Users List Subject: Re: [Mechanize-users] redirect with DELETE question On Dec 6, 2012, at 11:41, "Ding, Howard Adrian" <hding2 at illinois.edu> wrote:> It may well be that the particular product we''re using this with is not conforming with the spec, but that''s what we have.Your server is spec-compliant, but there are restrictions on what mechanize may do. It''s fine for the server to return a redirect for a DELETE request, but it''s not fine for a general-purpose user-agent like mechanize to automatically send a DELETE to the redirect location. If you build something atop mechanize that has application-specific knowledge, it''s fine for that program to automatically DELETE the redirect location. _______________________________________________ Mechanize-users mailing list Mechanize-users at rubyforge.org http://rubyforge.org/mailman/listinfo/mechanize-users