-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi all,
The HTTP wrapper currently only accepts status codes 200 and 206 as
successful in the 2xx range. Response codes like 202 (Accepted) fail and
throw a warning. However, the HTTP specification defines all 2xx status
codes as successful. This has posed some problems for us in writing
RESTful applications effectively, as we're trying to take advantage of
the full spectrum of successful codes.
The patch to fix this problem is relatively straightforward; see
http://cynigram.com/~nfontes/http_fopen_wrapper.patch
If anyone could take a look at this, I would be most grateful.
Thanks and regards,
Noah
Noah Fontes
Bitextender
http://www.bitextender.com/
Phone: +1 919 349 9826
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFIheUThitK+HuUQJQRArGfAKCJsEZ8QDFcWpoI4g2ZsbzGVsCAxgCgtZEk
7S66/HWfSf16D2FxUTMVsGU=
=zalu
-----END PGP SIGNATURE
Hi!
codes as successful. This has posed some problems for us in writing
RESTful applications effectively, as we're trying to take advantage of
the full spectrum of successful codes.
I think there should be no big problem to allow all 2xx codes, even
though some ones like 204 may behave strangely, but as long as it
doesn't break anything...
--
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hi!
codes as successful. This has posed some problems for us in writing
RESTful applications effectively, as we're trying to take advantage of
the full spectrum of successful codes.I think there should be no big problem to allow all 2xx codes, even though
some ones like 204 may behave strangely, but as long as it doesn't break
anything...
It is a BC break. But people should be checking the retrieved status
codes anyway so I don't think its a big issue.
+1
-Hannes
Yeah. We discussed that quite a while back when I sent over the
"ignore_errors" options patch-like thing in November:
http://thread.gmane.org/gmane.comp.php.devel/46003
I think we should do it.
But what about other 3xx redirect codes? How are those handled?
David
Am 22.07.2008 um 23:22 schrieb Stanislav Malyshev:
Hi!
codes as successful. This has posed some problems for us in writing
RESTful applications effectively, as we're trying to take advantage
of
the full spectrum of successful codes.I think there should be no big problem to allow all 2xx codes, even
though some ones like 204 may behave strangely, but as long as it
doesn't break anything...--
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
David Zülke wrote:
Yeah. We discussed that quite a while back when I sent over the
"ignore_errors" options patch-like thing in November:
http://thread.gmane.org/gmane.comp.php.devel/46003I think we should do it.
But what about other 3xx redirect codes? How are those handled?
I think PHP implicitly follows any Location headers it can. That's
probably not the right behavior, but for an automated process it's not bad.
I think that 3xx status codes, if they appear without a Location header,
should also probably not throw errors. They could provide valuable
information about the status of a page (particularly 304 Not Modified),
so I've updated the patch:
http://cynigram.com/~nfontes/http_fopen_wrapper.patch
BTW, any chance this could be rolled into 5.3? I think the BC break is
pretty non-notable, and it would be nice to stop throwing errors for
successful responses.
Regards,
Noah
Noah Fontes
Bitextender
http://www.bitextender.com/
Phone: +1 919 349 9826
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFIh20nhitK+HuUQJQRAqipAJ9pndnS4K4L5GtPzoYsEguYQSgSXwCfb6yC
YnohwjT8KYCiADQehg4Jm2A=
=UzO8
-----END PGP SIGNATURE
So... who's gonna commit it? :)
David
Am 23.07.2008 um 19:40 schrieb Noah Fontes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1David Zülke wrote:
Yeah. We discussed that quite a while back when I sent over the
"ignore_errors" options patch-like thing in November:
http://thread.gmane.org/gmane.comp.php.devel/46003I think we should do it.
But what about other 3xx redirect codes? How are those handled?
I think PHP implicitly follows any Location headers it can. That's
probably not the right behavior, but for an automated process it's
not bad.I think that 3xx status codes, if they appear without a Location
header,
should also probably not throw errors. They could provide valuable
information about the status of a page (particularly 304 Not
Modified),
so I've updated the patch:http://cynigram.com/~nfontes/http_fopen_wrapper.patch
BTW, any chance this could be rolled into 5.3? I think the BC break is
pretty non-notable, and it would be nice to stop throwing errors for
successful responses.Regards,
Noah
Noah Fontes
Bitextender
http://www.bitextender.com/
Phone: +1 919 349 9826
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)iD8DBQFIh20nhitK+HuUQJQRAqipAJ9pndnS4K4L5GtPzoYsEguYQSgSXwCfb6yC
YnohwjT8KYCiADQehg4Jm2A=
=UzO8
-----END PGP SIGNATURE
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1David Zülke wrote:
Yeah. We discussed that quite a while back when I sent over the
"ignore_errors" options patch-like thing in November:
http://thread.gmane.org/gmane.comp.php.devel/46003I think we should do it.
But what about other 3xx redirect codes? How are those handled?
I think PHP implicitly follows any Location headers it can. That's
probably not the right behavior, but for an automated process it's not bad.I think that 3xx status codes, if they appear without a Location header,
should also probably not throw errors. They could provide valuable
information about the status of a page (particularly 304 Not Modified),
so I've updated the patch:http://cynigram.com/~nfontes/http_fopen_wrapper.patch
BTW, any chance this could be rolled into 5.3? I think the BC break is
pretty non-notable, and it would be nice to stop throwing errors for
successful responses.
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 :(
-Hannes
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 afile_get_contents()request. Store it in a local buffer.
I do a secondfile_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
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 afile_get_contents()request. Store it in a local buffer.
I do a secondfile_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.
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.
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.
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 :]
-Hannes
Am 26.07.2008 um 22:53 schrieb Hannes Magnusson:
On Sat, Jul 26, 2008 at 22:37, David Zülke <david.zuelke@bitextender.com
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 afile_get_contents()request. Store it in a local buffer.
I do a secondfile_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
Noah Fontes wrote:
I think PHP implicitly follows any Location headers it can. That's
probably not the right behavior, but for an automated process it's not bad.
It's a configurable option (don't have the code in front of me, so no
proof, sorry). You can set redirects = 0, and have http not follow any
redirects.
--
Edward Z. Yang GnuPG: 0x869C48DA
HTML Purifier http://htmlpurifier.org Anti-XSS Filter
[[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]]
Edward Z. Yang wrote:
It's a configurable option (don't have the code in front of me, so no
proof, sorry). You can set redirects = 0, and have http not follow any
redirects.
Whoops, I'm talking about pecl/http, not the http wrapper. Disregard the
above.
--
Edward Z. Yang GnuPG: 0x869C48DA
HTML Purifier http://htmlpurifier.org Anti-XSS Filter
[[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]]
On Tue, Jul 29, 2008 at 05:50, Edward Z. Yang
edwardzyang@thewritingpot.com wrote:
Edward Z. Yang wrote:
It's a configurable option (don't have the code in front of me, so no
proof, sorry). You can set redirects = 0, and have http not follow any
redirects.Whoops, I'm talking about pecl/http, not the http wrapper. Disregard the
above.
No. You are right. You can turn it off:
http://no2.php.net/manual/en/context.http.php#context.http.max-redirects
-Hannes