Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:57531
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.54 as permitted sender)
Message-ID: <4F21B74A.7040104@gmail.com>
Date: Thu, 26 Jan 2012 21:27:54 +0100
User-Agent: Thunderbird
MIME-Version: 1.0
To: Chris Stockton <chrisstocktonaz@gmail.com>
CC: Kiyoto Tamura <me@ktamura.com>, internals@lists.php.net
References: <38EE3732-F134-4C02-8F93-2E9C61FD1E81@ktamura.com> <CALKFbxv7FR-kP+PTWyj58hgD78=5E2ihCTAxzdnywQfdtmkz_g@mail.gmail.com> <CEE97C0A-3BB2-4519-B5B3-FB84A22BE1B9@ktamura.com> <CALKFbxu398VGV7DavYVhpo-b6RkuEM6_XH=_GuQTZ0DqtnZN3Q@mail.gmail.com>
In-Reply-To: <CALKFbxu398VGV7DavYVhpo-b6RkuEM6_XH=_GuQTZ0DqtnZN3Q@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] A potential patch for Bug#60668
From: keisial@gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=)

About Kiyoto's patch:
Some servers would read as new headers if the newlines were just \n or \r
(which would be illegal per HTTP spec). I think the characters to ban 
are: \n \r \0

Just replace your call to zend_trim_after_carriage_return with:
+ strtok(new_value, "\r\n"); // Truncate on \n, \r and \0
+ new_value_length = strlen(new_value);




Chris Stockton wrote:
> As for the "feature" of \r\n working in user-agent init set, my main
> point is that is a BC break, since it is slightly advocated to use it
> as a hack in the docs here [1].
Adding a new header by inserting it with user_agent is a really buggy hack.
It should be documented as "in php < 5.4 it used to be possible to add a 
new
header modifying the ini user-agent. On newer versions you need to use
stream_context_set_params(, array('header' => $headers) )"
(plus a good example).
The proper stream_context_set_params way has apparently been available at
least since PHP 5.0. It's just hard to find.


> At the end of the day passing _any_
> user input to literally any php function without sanitization can be
> dangerous given the right context.
Sure, but that's no reason to not improve it, specially if you do it on 
a major
release (eg. PHP 5.4).

Even though it works, it should be obvious that it isn't expected to be 
used that way.
So there should be little problem with it going away,