Attaching a patch that should (hopefully) fix all the problems listed here. I have tested it and it looks good to me.
On Thu, May 9, 2013 at 9:55 AM, Darshit Shah <dar...@gmail.com> wrote: > > > We currently suspend any method if the response code is a non 307 >> > redirect. That I believe is wrong. We should only be suspending the >> > POST method and not others. >> >> It sounds good, but we must be careful also with 303. >> >> Do you agree that the matrix for the method to use on the next request >> should look this way? >> >> original >> method -> POST FOO HEAD >> response >> status >> | >> \/ >> 301 GET FOO (terminate) >> 302 GET FOO (terminate) >> 303 GET GET (terminate) >> 307 POST FOO (terminate) >> >> Looks good to me. This will require some work so that the code remains > maintainable later. > I implemented setting opt.spider when invoked with --method head. But > spider mode currently follows all redirects till it receives a 200 OK. This > does not match with the intended behaviour. > > >> > Well yeah. It has opened a whole lot of possibilities that we must >> > keep considering. I will handle it separately for HEAD and send in a >> > patch soon. However, I was thinking, that since the new --method >> > command needs a lot of work specific to itself and that it may only >> > increase in the future, we should handle that code separately? Maybe a >> > set_method_opts() function? >> >> we can refactor if/when we really need it, no need to overengineer the >> code now. > > Let's keep it for later then. > > Do you already have any of such "opts" in mind? >> > Just the code that handles post-body/data and now for HEAD. > > > > -- > Thanking You, > Darshit Shah > > -- Thanking You, Darshit Shah
0001-Follow-RFC-2616-and-httpbis-specifications-when-hand.patch
Description: Binary data