Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:39357 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 66654 invoked from network); 26 Jul 2008 20:37:40 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 26 Jul 2008 20:37:40 -0000 Authentication-Results: pb1.pair.com smtp.mail=david.zuelke@bitextender.com; spf=softfail; sender-id=softfail Authentication-Results: pb1.pair.com header.from=david.zuelke@bitextender.com; 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:50444] helo=wp005.webpack.hosteurope.de) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id F1/71-55222-90B8B884 for ; Sat, 26 Jul 2008 16:37:30 -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 1KMqW6-0001y4-Gb; Sat, 26 Jul 2008 22:37:26 +0200 Cc: Noah Fontes , PHP Developers Mailing List , Lukas Kahwe Smith Message-ID: To: Hannes Magnusson In-Reply-To: <7f3ed2c30807250353g6fb37d8kc6432634173427a6@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Date: Sat, 26 Jul 2008 22:37:25 +0200 References: <4885E513.6080702@bitextender.com> <48864FA5.6050104@zend.com> <48876D27.6030407@bitextender.com> <7f3ed2c30807250353g6fb37d8kc6432634173427a6@mail.gmail.com> X-Mailer: Apple Mail (2.926) X-bounce-key: webpack.hosteurope.de;david.zuelke@bitextender.com;1217104650;3e68a9a8; Subject: Re: [PHP-DEV] Patch for HTTP successful status codes From: david.zuelke@bitextender.com (=?ISO-8859-1?Q?David_Z=FClke?=) 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