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

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

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.

-- 
  / daniel.haxx.se