Hi,

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"
>> easily.
>
> 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
> "system".
>

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

-- 
   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.cz