On November 29, 2002 01:05 am, Sara Golemon wrote: > >> I disagree with this, the current behaviour is imho wrong. > >> > >> mailto: is a url, rejecting the patch because it introduces a special > >> case, is not a good thing. parse_url() is for _all_ url's, not just > >> http:// url's, and besides, the current syntax for mailto is > >> completely valid, and should be parsed anyway. > >> > >> (ie, a special case shouldn't be required if the url parser was rfc > >> compliant). > > > > PHP's php_url_parse() function is not in any way limited to http:// as > > you claim, it support a large variety of valid URLs, take a look at the > > very extensive test for parse_url() function located here: > > ext/standard/tests/strings/url_t.phpt. > > Even the regular expression described in RFC 2396 does not recognize > > mailto: any differently the our very own parse_url(). > > 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. Ilia -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
