Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:39360 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 71810 invoked from network); 26 Jul 2008 20:59:22 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 26 Jul 2008 20:59:22 -0000 Authentication-Results: pb1.pair.com header.from=david.zuelke@bitextender.com; sender-id=softfail Authentication-Results: pb1.pair.com smtp.mail=david.zuelke@bitextender.com; spf=softfail; sender-id=softfail Received-SPF: softfail (pb1.pair.com: domain bitextender.com does not designate 80.237.132.12 as permitted sender) X-PHP-List-Original-Sender: david.zuelke@bitextender.com X-Host-Fingerprint: 80.237.132.12 wp005.webpack.hosteurope.de Received: from [80.237.132.12] ([80.237.132.12:42560] helo=wp005.webpack.hosteurope.de) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 49/A0-02589-9209B884 for ; Sat, 26 Jul 2008 16:59:22 -0400 Received: from munich.bitxtender.net ([85.183.90.3] helo=[10.224.251.2]); authenticated by wp005.webpack.hosteurope.de running ExIM using esmtpsa (TLSv1:RC4-SHA:128) id 1KMqrF-0003Yo-QS; Sat, 26 Jul 2008 22:59:17 +0200 Cc: "Noah Fontes" , "PHP Developers Mailing List" , "Lukas Kahwe Smith" Message-ID: To: Hannes Magnusson In-Reply-To: <7f3ed2c30807261353v1fc3505en1d2bc922671cdb30@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v926) Date: Sat, 26 Jul 2008 22:59:17 +0200 References: <4885E513.6080702@bitextender.com> <48864FA5.6050104@zend.com> <48876D27.6030407@bitextender.com> <7f3ed2c30807250353g6fb37d8kc6432634173427a6@mail.gmail.com> <7f3ed2c30807261353v1fc3505en1d2bc922671cdb30@mail.gmail.com> X-Mailer: Apple Mail (2.926) X-bounce-key: webpack.hosteurope.de;david.zuelke@bitextender.com;1217105962;4a45d317; Subject: Re: [PHP-DEV] Patch for HTTP successful status codes From: david.zuelke@bitextender.com (=?ISO-8859-1?Q?David_Z=FClke?=) Am 26.07.2008 um 22:53 schrieb Hannes Magnusson: > On Sat, Jul 26, 2008 at 22:37, David Z=FClke = > wrote: >> Am 25.07.2008 um 12:53 schrieb Hannes Magnusson: >> >>> I think changing all 3xx status codes to be success is a slightly =20= >>> 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 =20 >>> out my >>> buffer. >>> >>> Now, in 5.3.0 the 304 is treated as success so I naturally discard =20= >>> my >>> buffer and print the results of the new request... Whooopsy, there =20= >>> was >>> no data :( >> >> The problem with the current behavior is that a warning is thrown, =20= >> but the >> response is empty and there is no way to even tell the status code =20= >> that you >> got back. Sure, there is the "ignore_errors" option in 5.3 that I =20 >> proposed >> back in November (which Sara committed, thanks again), but still... > > http://no.php.net/manual/en/=20 > 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 =20 response body. >> Also, to get back a 304, you'd have to send ETag and If-Modified-=20 >> Since >> headers anyway, since it is only returned for such conditional =20 >> 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 =20 current apps is quite unlikely. Unless, of course, you did the wrong =20 thing and used @file_get_contents() and stuff... >> I'm relatively indifferent on this. For purposes where I need =20 >> access to the >> info, I'll always set the "ignore_errors" option anyway. But if I =20 >> 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 =20 problem, it's very complete. You can do any kind of stuff, like =20 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 =20= it's inconsistent to handle some redirects as successful, and some as =20= erroneous... David=