# Patch for HTTP successful status codes - Thread: https://externals.io/message/39185 - Original archive: https://news-web.php.net/php.internals/39185 - Started by Noah Fontes on 2008-07-22T13:48:03+00:00 - Messages: 15 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #39185 — Noah Fontes — 2008-07-22T13:48:03+00:00 URL: https://externals.io/message/39185#39185 -----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 --- ## #39202 — Stanislav Malyshev — 2008-07-22T21:22:45+00:00 URL: https://externals.io/message/39185#39202 · In reply to: #39185 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 --- ## #39212 — Hannes Magnusson — 2008-07-23T06:47:40+00:00 URL: https://externals.io/message/39185#39212 · In reply to: #39202 > Hi! > > > […] > > 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 --- ## #39215 — david.zuelke@bitextender.com — 2008-07-23T08:39:54+00:00 URL: https://externals.io/message/39185#39215 · In reply to: #39202 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! > > > […] > > 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 --- ## #39240 — Noah Fontes — 2008-07-23T17:40:55+00:00 URL: https://externals.io/message/39185#39240 · In reply to: #39215 -----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 --- ## #39264 — david.zuelke@bitextender.com — 2008-07-24T11:08:17+00:00 URL: https://externals.io/message/39185#39264 · In reply to: #39240 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: > > […] > > 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 --- ## #39316 — david.zuelke@bitextender.com — 2008-07-25T10:34:41+00:00 URL: https://externals.io/message/39185#39316 Did you yet? :) Am 24.07.2008 um 14:42 schrieb Michael Wallner: > David Zülke wrote: > > […] > > I'll commit in the next few hours if nobody objects. > > Mike --- ## #39319 — Lukas Kahwe Smith — 2008-07-25T10:44:53+00:00 URL: https://externals.io/message/39185#39319 · In reply to: #39316 > Did you yet? :) yes .. it has been commited. regards, Lukas Kahwe Smith mls@pooteeweet.org --- ## #39321 — Hannes Magnusson — 2008-07-25T10:53:36+00:00 URL: https://externals.io/message/39185#39321 · In reply to: #39240 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > David Zülke 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. > > 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 --- ## #39357 — david.zuelke@bitextender.com — 2008-07-26T20:37:25+00:00 URL: https://externals.io/message/39185#39357 · In reply to: #39321 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 --- ## #39359 — Hannes Magnusson — 2008-07-26T20:53:15+00:00 URL: https://externals.io/message/39185#39359 · In reply to: #39357 > Am 25.07.2008 um 12:53 schrieb Hannes Magnusson: > > > […] > > 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 --- ## #39360 — david.zuelke@bitextender.com — 2008-07-26T20:59:17+00:00 URL: https://externals.io/message/39185#39360 · In reply to: #39359 Am 26.07.2008 um 22:53 schrieb Hannes Magnusson: > On Sat, Jul 26, 2008 at 22:37, David Zülke > […] > > 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. > > […] > > 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... > > […] > > 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 --- ## #39423 — Edward Z. Yang — 2008-07-29T03:48:35+00:00 URL: https://externals.io/message/39185#39423 · In reply to: #39240 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 Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] --- ## #39424 — Edward Z. Yang — 2008-07-29T03:50:28+00:00 URL: https://externals.io/message/39185#39424 · In reply to: #39423 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 Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] --- ## #39428 — Hannes Magnusson — 2008-07-29T07:20:50+00:00 URL: https://externals.io/message/39185#39428 · In reply to: #39424 On Tue, Jul 29, 2008 at 05:50, Edward Z. Yang wrote: > Edward Z. Yang wrote: > > […] > > 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