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 Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: jcnventura at yahoo dot com
New email:
PHP Version: OS:

 

 [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

Pull Requests

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 Dec 27 07:01:28 2024 UTC