Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:48373
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain moonspot.net designates 72.5.90.27 as permitted sender)
Message-ID: <4BF6AD07.7090001@moonspot.net>
Date: Fri, 21 May 2010 10:55:51 -0500
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: Ralph Schindler <ralph@smashlabs.com>
CC: internals <internals@lists.php.net>
References: <4BF6A90D.8020901@smashlabs.com>
In-Reply-To: <4BF6A90D.8020901@smashlabs.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Fixes for parse_url, bug 50563
From: brian@moonspot.net (Brian Moon)

+1


Brian.
--------
http://brian.moonspot.net/

On 5/21/10 10:38 AM, Ralph Schindler wrote:
>
> Hey all,
>
> Attached is a patch to remove the warning from parse_url() in situations
> where parse_url() cannot actually parse the url. The bug report also
> claims there should be a new feature for understanding "why" a parsed
> url failed. That code currently does not exist, and the current warning
> gives no more information than simply returning false does.
>
> http://bugs.php.net/bug.php?id=50563
>
> The first patch is against trunk. I think we should at least get this
> done even if the group decides that down the line we want the why
> portion explained as well (I actually don't care about the why part).
> That feature would require that php_url_parse_ex() add some parsing
> intellignce, this would not be a 1 or 2 line feature implementation.
>
> The motivation is that since false and E_WARN are redunant, this patch
> would allow developers to STOP using @parse_url(), which we have to do.
>
> I also suggest that we apply this to the PHP_5_3 branch. This behavior
> should be backwards compatible with everyone that is actually using the
> @parse_url() in their code. The only 1-off situation that might be
> affected is if people are catching the error with an error handler and
> branching there. Why they wouldn't be branching off the false return
> value, I don't know.
>
> Both patches contain test fixes.
>
> Is there anything more I need? Is this commit worthy?
>
> Thanks,
> Ralph
>