Re: Patch for HTTP successful status codes

Am 26.07.2008 um 22:53 schrieb Hannes Magnusson:

On Sat, Jul 26, 2008 at 22:37, David Zülke <david.zuelke@bitextender.comwrote:

Am 25.07.2008 um 12:53 schrieb Hannes Magnusson:

I think changing all 3xx status codes to be success is a slightly more bc break then you think. A simple example: I do a file_get_contents() request. Store it in a local buffer. I do a second file_get_contents(), get a error (304) back, print out my buffer. Now, in 5.3.0 the 304 is treated as success so I naturally discard my buffer and print the results of the new request... Whooopsy, there was no data :(

The problem with the current behavior is that a warning is thrown, but the response is empty and there is no way to even tell the status code that you got back. Sure, there is the "ignore_errors" option in 5.3 that I proposed back in November (which Sara committed, thanks again), but still...

http://no.php.net/manual/en/reserved.variables.httpresponseheader.php ? afaik this variable is always set, especially on errors.

Yes, but that only includes the headers. There is no way to get the response body.

Also, to get back a 304, you'd have to send ETag and If-Modified-Since headers anyway, since it is only returned for such conditional requests - it won't happen in normal situations!

Why not? You try obviously set these headers to spare you needing to fetch the content again if it hasn't changed.

Yes. But you do that manually, that was my point. A 304 breaking current apps is quite unlikely. Unless, of course, you did the wrong thing and used @file_get_contents() and stuff...

I'm relatively indifferent on this. For purposes where I need access to the info, I'll always set the "ignore_errors" option anyway. But if I had to choose, I'd say include 3xx codes in the "successful" group.

Like mike put it on IRC: "Ahh shit. You should be using pecl/http anyway" describes the situation pretty well. PHP only offers half baked implementation which is very useful for regular joe, but as soon as you need to do anything fancy with it you are shit out of luck.

That's no excuse for fixing it ;) And besides the error handling problem, it's very complete. You can do any kind of stuff, like POSTing etc, with a stream context.

I'm fine with just documenting this change in the "bc break" section, but this is such a subtle change that will be very hard to debug though :]

As I said, I'm fine with having it handled as an error. But I believe it's inconsistent to handle some redirects as successful, and some as erroneous... David