>> 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:[EMAIL PROTECTED]?subject=Bug+20308 should be entitled to >> everybit as much parsing as >> http://joe:[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 >> '[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
