Req #70588 [Com]: tel:nnnn URLs are converted to host+port incorrectly

From: Date: Thu, 11 May 2017 10:00:22 +0000
Subject: Req #70588 [Com]: tel:nnnn URLs are converted to host+port incorrectly
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-209055@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=70588&edit=1 ID: 70588 Comment by: christoph at burschka dot de Reported by: jcnventura at yahoo dot com Summary: tel:nnnn URLs are converted to host+port incorrectly Status: Not a bug Type: Feature/Change Request Package: URL related Operating System: Ubuntu LTS 14.04 PHP Version: 5.6.14RC1 Block user comment: N Private report: N New Comment: In a strict parser, "tel:nnn" would not be a special case at all - the obstacle here is that parse_url accepts partial non-URLs like "host:port", rather than requiring a URL to begin with either a scheme: or "//". That can't be changed without breaking compatibility. Maybe a better approach here is to add an optional strict mode that accepts "scheme:path[?query][#fragment]", "scheme://host[:post][/path][?query][#fragment]" and "//host[:port][/path][?query][#fragment]", and rejects everything else? Previous Comments: ------------------------------------------------------------------------ [2015-09-27 10:44:14] requinix@php.net Okay, so if parse_url() is going to support tel too, what about the rest? Like data and irc and magnet and mailto and news and the couple hundred others that exist? http://www.iana.org/assignments/uri-schemes/uri-schemes.xml Putting aside how a telephone is not a URL in the first place, parse_url() is suited to one job and it does it well, so supporting others would be a good idea for an extension or userland library. ------------------------------------------------------------------------ [2015-09-27 09:14:23] chx@php.net So I think this is a feature request. ------------------------------------------------------------------------ [2015-09-27 09:13:21] chx@php.net I am not sure what could be done here. Every bit of code out there that codes around tel: recognized as it is recognized now will immediately break if this is changed. That's probably undesired. The BNF of RFC 3966 says telephone-uri = "tel:" telephone-subscriber and telephone-subscriber is not a path, not a port, no, it's a telephone-subscriber. Considering the above, I'd recommend a new optional telephone-subscriber return key in parse_url and a constant accordingly and not changing any of the previous values. ------------------------------------------------------------------------ [2015-09-26 14:04:28] jcnventura at yahoo dot com I now believe this is a real bug, as tel: is still both a URI and a URL. According to the available info, a URI is either a URL or a URN (or both). To be a URN, it must start with "urn:", which it clearly does not, thus confirming its status as a URL. ------------------------------------------------------------------------ [2015-09-26 12:49:46] jcnventura at yahoo dot com While technically true, the fact was that tel: WAS a URL before, and it's still wildly used out there. parse_url("tel:911") should be able to call 911, and not try to connect to port 911 on the tel host. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=70588 -- Edit this bug report at https://bugs.php.net/bug.php?id=70588&edit=1

« previous php.bugs (#209055) next »