Am 26.07.2008 um 22:53 schrieb Hannes Magnusson:
On Sat, Jul 26, 2008 at 22:37, David Zülke <[EMAIL PROTECTED]
> wrote:
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
