php-developer-list | 2002112

Re: [PHP-DEV] Bug #20308 (Feature Request) From: Sara Golemon (pollita <email protected>)
Date: 11/29/02

>> I'm not so much worried about the user in this case, a few explodes
>> will keep them happy. I'm more worried about the behavior of
>> parse_url being just plain lacking.
>> mailto:pollita <email protected>?subject=Bug+20308 should be entitled to
>> everybit as much parsing as
>> email protected>?subject=Re:%20[PHP-DEV]%20Bug%20#20308%20(Feature%20Request)&replyto=1025.64.156.231.86.1038593563.squirrel <email protected>">blow <email protected>/pathto/somepage?var=value">http://joe:blow <email protected>/pathto/somepage?var=value
>>
>> The ONLY real concern here, and reason for not fixing php_url_parse,
>> comes in the fact that 'path' would no longer contain
>> 'pollita <email protected>?subject=Bug+20308' (per the example above) which
>> would likely break existing scripts.
>>
>> Perhaps the compromise is to create a new function 'parse_url_rfc'
>> (name could be better) which behaves correctly (without having special
>> cases). Then add a note to the manpage for parse_url saying to use
>> parse_url_rfc instead, and eventually deprecate parse_url (perhaps
>> with PHP 5.0).
>
> No. parse_url_rfc would be misleading because it would not follow RFC.
> There are special rules for scheme:, scheme:/ and scheme://, your
> suggested patch would actually break RFC, since mailto: is already
> parsed properly according to RFC.
> E-mail addresses are not urls, if we want to offer an email parser it
> should be separate function parse_email or something similar, there is
> no need to pollute php_parse_url() with hacks for non-intended
> functionality.

Okay, okay... I throw my hands up... 

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php