Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:39359
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 72.14.214.239 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:cc:in-reply-to:mime-version
         :content-type:content-transfer-encoding:content-disposition
         :references;
        b=am3tLgqUe2Bz+tK+k69WmyIlpYj1yH/7iuAqZ019uWe4rO0XONUjBCSqS/nNW+IN6I
         j8ZjZBZ2Da3Qo/s4IpESYkiwkUETGtceeIi9UTc9x45wiKRFvYLZBnoGYWlD5OpcgB8/
         IsndnpAvEyBe7sJpLIoOXbK9AqUcB1qE/pfBw=
Message-ID: <7f3ed2c30807261353v1fc3505en1d2bc922671cdb30@mail.gmail.com>
Date: Sat, 26 Jul 2008 22:53:15 +0200
To: "=?ISO-8859-1?Q?David_Z=FClke?=" <david.zuelke@bitextender.com>
Cc: "Noah Fontes" <noah.fontes@bitextender.com>, 
	"PHP Developers Mailing List" <internals@lists.php.net>, 
	"Lukas Kahwe Smith" <mls@pooteeweet.org>
In-Reply-To: <A7949F33-A4CC-4779-A226-FB2E5EE1B3E8@bitextender.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <4885E513.6080702@bitextender.com> <48864FA5.6050104@zend.com>
	 <B31EBBD3-6B33-4BEE-8997-E09D5293053B@bitextender.com>
	 <48876D27.6030407@bitextender.com>
	 <7f3ed2c30807250353g6fb37d8kc6432634173427a6@mail.gmail.com>
	 <A7949F33-A4CC-4779-A226-FB2E5EE1B3E8@bitextender.com>
Subject: Re: [PHP-DEV] Patch for HTTP successful status codes
From: hannes.magnusson@gmail.com ("Hannes Magnusson")

On Sat, Jul 26, 2008 at 22:37, David Z=FClke <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 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 th=
e
> response is empty and there is no way to even tell the status code that y=
ou
> got back. Sure, there is the "ignore_errors" option in 5.3 that I propose=
d
> 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 t=
he
> 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