Re: Patch for 301/302 redirect after post
Date: Mon, 04 Aug 2008 09:17:41 +0200
Daniel Stenberg napsal(a):
> On Thu, 17 Jul 2008, Martin Drasar wrote:
>>>> -1: error is reported after post followed by 301/302
>>>> 0: post is resent
>>>> 1: post is changed to get
>>> One thought just came to me--is the new "-1" option even needed? How
>>> is it different from disabling redirects altogether and letting the
>>> application check the return code for 301 or 302 itself?
>> Because I don't want to disable redirects. I still want curl to follow
>> 307. This new option is needed so that my platform can tell the
>> customer - "hey, your system is broken. Follow the standards at once"
> Eh, why would returning 301 or 302 to a POST be a broken system? The
> brokeness here is only due to how (old?) browsers work, not in the
The "system" here means customer's program that is not conformant to
standard, expecting re-POST after 302. Aside from that, nothing is wrong
with sending 301 or 302 after POST.
>> Without this I have no other way to find and report that customer's
>> system is using 302 (which causes GET everytime) where he should be
>> using 307, other than by examining the response I get (which could be
>> PITA) or by disabling redirects and hadnling them by myself...
> You can easily detect 301/302 codes yourself when having it activated
> and then make them cause errors get returned.
Can I? When CURLOPT_FOLLOWLOCATION is turned on? Please tell me how,
because that would render half of my patch unneeded.
> I don't like this way to allow two particular HTTP response codes to
> cause errors. I'm generally against creeping featurism in the
> location-following department, as no matter how advanced we make it
> there will always be lots of edge-cases people want that we cannot
> possibly provide as an existing feature.
> If you want something more fancy and something that goes beyond the
> logic and core functionality of the libcurl redirect handling, then you
> SHOULD do the logic yourself. Recent info variables we've added even
> makes that job quite easy these days.
> But I do approve of a CURLOPT_POST301-style fix to also handle 302, as I
> believe the not doing so already was an oversight from when this option
> was added in the first place.
I understand that you don't want to fill the code with overly specific
features and having bool CURLOPT_POST302 is better than nothing for sure...
Thanks for your time
-- Martin Drasar, Developer / Analyst OptimSys, s.r.o. drasar_at_optimsys.cz Tel: +420 541 143 065 Fax: +420 541 143 066 http://www.optimsys.czReceived on 2008-08-04