This undoes the fix done by fix to the bug https://bugs.php.net/bug.php?id=62524. I do not think we should be doing this. We should follow redirects if they are redirects - i.e., have proper redirect code.

Stanislav, fix done to the bug https://bugs.php.net/bug.php?id=62524 is incorrect. After applying it we are not able to do not follow location in case of 2xx response codes. Please, double check the fix. It just allows to change follow_location parameter only if response code is 3xx. But in case of 2xx response code you will be redirected to location url and you cannot do anything with it.

@akbarovs But why you need to follow location on non-redirect response? It looks very counter-intuitive when you POST something to an URL and get the content of entirely different URL, without redirect code... And you won't even know which URL is that.

@smalyshev I do not need to follow location. I just want to fix the bug related to the 3xx response codes patch, which broke fopen logic. Let me describe what was changed related to the bug https://bugs.php.net/bug.php?id=62524
Before:
follow_location is true (1) by default, so we do redirect without taking response code into account. But you could change follow_location parameter to 0 and do not follow redirects
After 62524:
follow_location is true (1) by default, so we do redirect for 3xx response code taking follow_location parameter into account. For all others response codes (ex. 201) we do redirect. And I am not able to prevent fopen to do such redirects
My patch:
follow_location is true (1) by default.
If response code in 3xx we check follow_location parameter. if follow_location is true (default) -> we do redirect, else we do not do follow it.
If response code not in 3xx we check follow_location parameter. If follow_location is not set (usually people does not use it) -> we do not follow redirect. But if parameter is set -> we follow redirect (because if I have opportunity to extract location header from the response and call fopen one more time with new url parameter. So why we should prevent people from doing this?)

@akbarovs OK, I now understand, thanks for the explanation. Yes, it seems to be wrong that non-3xx statuses always redirect. This was not the intent of the original patch I think.

@smalyshev Yes. Looks like there is difference between original patch intention (which is correct according to the rfc) and implementation.

I'll add some tests (missing tests probably a reason why previous patch failed) and merge.

Comment on behalf of stas at php.net:

merged