Re: Bug #20308 (Feature Request)

From: Date: Fri, 29 Nov 2002 17:41:08 +0000
Subject: Re: Bug #20308 (Feature Request)
References: 1 2 3 4  Groups: php.dev 
Request: Send a blank email to php-dev+get-91928@lists.php.net to get a copy of this message
>> It looks like php_url_parse can be modified to return user and host >> for mailto schemes without making it a 'special case', but that would >> also remove the current 'path' index which would break existing PHP >> code ((bad)). >> >> So we can (A) put in a special case, or (B) not modify the function at >> all. Either way leaves someone unhappy so in the absence of a >> majority I can't help but do nothing. This request will have to >> remain open, at least for now. > > Users requests all kinds of features all the time, just because someone > will be unhappy because their request is not implemented is hardly a > reason to implement it. As a rule, special cases are bad, if you REALLY > think this is useful functionality we are better off adding a > parse_email() function, who's job would be to break email addresses > into parts. > 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@php.net?subject=Bug+20308 should be entitled to everybit as much parsing as http://joe:blow@www.php.net/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@php.net?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 depricate parse_url (perhaps with PHP 5.0). -Pollita

« previous php.dev (#91928) next »