Re: [PHP-DEV] Patch for HTTP successful status codes
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. YangGnuPG: 0x869C48DA HTML Purifier http://htmlpurifier.org Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch for HTTP successful status codes
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. YangGnuPG: 0x869C48DA HTML Purifier http://htmlpurifier.org Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch for HTTP successful status codes
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
Re: [PHP-DEV] Patch for HTTP successful status codes
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. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 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 [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
Re: [PHP-DEV] Patch for HTTP successful status codes
Did you yet? :) Am 24.07.2008 um 14:42 schrieb Michael Wallner: David Zülke wrote: So... who's gonna commit it? :) I'll commit in the next few hours if nobody objects. Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch for HTTP successful status codes
On 25.07.2008, at 12:34, David Zülke wrote: Did you yet? :) yes .. it has been commited. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch for HTTP successful status codes
On Wed, Jul 23, 2008 at 19:40, Noah Fontes [EMAIL PROTECTED] wrote: -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/46003 I 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch for HTTP successful status codes
So... who's gonna commit it? :) David Am 23.07.2008 um 19:40 schrieb Noah Fontes: -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/46003 I 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- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch for HTTP successful status codes
David Zülke wrote: So... who's gonna commit it? :) I'll commit in the next few hours if nobody objects. Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch for HTTP successful status codes
On Tue, Jul 22, 2008 at 23:22, Stanislav Malyshev [EMAIL PROTECTED] wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch for HTTP successful status codes
-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/46003 I 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- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Patch for HTTP successful status codes
-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- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch for HTTP successful status codes
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 [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
