Re: Bug #20308 (Feature Request)
| From: | Ilia A. | Date: | Fri, 29 Nov 2002 14:52:20 +0000 |
| Subject: | Re: Bug #20308 (Feature Request) | ||
| References: | 1 2 3 | Groups: | php.dev |
| Request: | Send a blank email to php-dev+get-91920@lists.php.net to get a copy of this message | ||
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