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...
I'm relatively indifferent. I believe it's clear that a 2xx code
should be successful, no need to argue about that I guess.
One reason why I'd lean towards including 3xx codes is because they
are, as per the spec, not to be regarded as errors (http://tools.ietf.org/html/rfc2616#section-10.3
):
This class of status code indicates that further action needs to be
taken by the user agent in order to fulfill the request. The action
required MAY be carried out by the user agent without interaction
with the user if and only if the method used in the second request
is GET or HEAD. A client SHOULD detect infinite redirection loops,
since such loops generate network traffic for each redirection.
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!
Mind you that selectively regarding some 3xx codes as successful
wouldn't be a good forward compatible solutions, as protocol
extensions like WebDAV define additional status codes in several
ranges (WebDAV only does in 2xx and 4xx, I think, but you get the idea).
One of the more fundamental issues with the way errors are handled is
that internally, the wrapper exits too early, and no further info on
the stream (contents, metadata etc) will be available... so if an
error occurs, there's no way to access any info on what happened
(unless, again, "ignore_errors" is true).
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.
David
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
