php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Request #70588 tel:nnnn URLs are converted to host+port incorrectly
Submitted: 2015-09-26 11:25 UTC Modified: 2015-09-27 10:44 UTC
From: jcnventura at yahoo dot com Assigned:
Status: Not a bug Package: URL related
PHP Version: 5.6.14RC1 OS: Ubuntu LTS 14.04
Private report: No CVE-ID: None
View Add Comment Developer Edit
 [2015-09-26 11:25 UTC] jcnventura at yahoo dot com 
Description:
------------
When calling parse_url with tel:nnnn with n <= 65535, the valid URL according to RFC 3966 gets converted to a host+port pair. The code in ext/standard/url.c (php_url_parse_ex) should be fixed to detect the tel schema and not goto parse_port in this case.


Expected result:
----------------
var_export(parse_url("tel:65535"));
array (
  'scheme' => 'tel',
  'path' => 65535,
)

var_export(parse_url("tel:65536"));
array (
  'scheme' => 'tel',
  'path' => 65536,
)


var_export(parse_url("tel:6000"));
array (
  'scheme' => 'tel',
  'path' => 6000,
)


var_export(parse_url("tel:600000"));
array (
  'scheme' => 'tel',
  'path' => '600000',
)

Actual result:
--------------
var_export(parse_url("tel:65535"));
array (
  'host' => 'tel',
  'port' => 65535,
)

var_export(parse_url("tel:65536"));
false // Tries to match with a port, but outside range.


var_export(parse_url("tel:6000"));
array (
  'host' => 'tel',
  'port' => 6000, // Shouldn't be a port !?
)


var_export(parse_url("tel:600000"));
array (
  'scheme' => 'tel',
  'path' => '600000', // Expected result.
)

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2015-09-26 11:32 UTC] requinix@php.net
-Status: Open +Status: Not a bug
 [2015-09-26 11:32 UTC] requinix@php.net 
tel: is a URI, not a URL, and as the note in parse_url's documentation says,
>This function is intended specifically for the purpose of parsing URLs and not URIs.
 [2015-09-26 12:49 UTC] 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.
 [2015-09-26 14:04 UTC] 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-27 09:13 UTC] 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-27 09:14 UTC] chx@php.net
-Type: Bug +Type: Feature/Change Request
 [2015-09-27 09:14 UTC] chx@php.net 
So I think this is a feature request.
 [2015-09-27 10:44 UTC] 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.
 [2017-05-11 10:00 UTC] christoph at burschka dot de 
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?
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Fri Apr 19 04:01:28 2024 UTC