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

go to bug id or search bugs for

Doc Bug #72301 filter_var($url, FILTER_VALIDATE_URL) does not support scheme-relative URLs
Submitted: 2016-05-31 09:26 UTC Modified: 2021-04-22 11:46 UTC
Votes:15
Avg. Score:4.5 ± 0.7
Reproduced:15 of 15 (100.0%)
Same Version:2 (13.3%)
Same OS:1 (6.7%)
From: ian+php at ians-net dot co dot uk Assigned:
Status: Open Package: Filter related
PHP Version: 7.0.7 OS: irrelevant
Private report: No CVE-ID: None
View Developer Edit
 [2016-05-31 09:26 UTC] ian+php at ians-net dot co dot uk 
Description:
------------
RFC3986 allows scheme relative URLs, also termed network-path references. These are commonly used to ensure the appropriate protocol is used to fetch the resource regardless of whether the resource is embedded in a http or https page.

filter_var($url, FILTER_VALIDATE_URL) does not correctly validate these URLs

See also
 https://tools.ietf.org/html/rfc3986#section-4.2
 https://url.spec.whatwg.org/#syntax-url-scheme-relative

Test script:
---------------
var_dump(filter_var("//google.com/", FILTER_VALIDATE_URL));



Expected result:
----------------
bool(true)

Actual result:
--------------
bool(false)

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2016-05-31 10:07 UTC] derick@php.net 
If this gets added, it should be done with an optional (off by default) new flag.
 [2016-06-30 15:18 UTC] apokryfos84 at gmail dot com 
The problem is that FILTER_VALIDATE_URL uses RFC 2396 which is older than RFC 3986. This would have been OK if the language was consistent in the URL RFC it was using, however parse_url seems to be using RFC3986, making the following code to behave unexpectedly. 

if (filter_var($url,FILTER_VALIDATE_URL)) {
    $parts = parse_url($url);
} 

Note: I am only assuming that parse_url uses RFC 3986 because there's a link to it in the "see also" links of http://php.net/manual/en/function.parse-url.php
 [2016-12-22 02:22 UTC] ihipop+php at gmail dot com 
I think a new flag should be add to obey the RFC3986,and compatible with the old behavior
 [2016-12-22 10:18 UTC] yohgaki@php.net
-Operating System: OpenBSD +Operating System: irrelevant
 [2016-12-22 10:18 UTC] yohgaki@php.net 
FYI. "//example.com/" is supported by parse_url() and URL rewriter by default.

https://3v4l.org/uN3I3

There is re2c URL parser. I suppose it's not merged yet. It may be better to use new URL parser and be consistent. Current URL rewriter uses the same internal function as parse_url(), so it will use re2c URL parser when it is merged.
 [2021-04-22 11:46 UTC] cmb@php.net
-Type: Bug +Type: Documentation Problem
 [2021-04-22 11:46 UTC] cmb@php.net 
This is not related to any RFC or parse_url(), but is rather
because the scheme is always required.  There was the
FILTER_FLAG_SCHEME_REQUIRED flag, but since this was implied
anyway, it is removed as of PHP 8.0.0.  I think adding a
FILTER_FLAG_SCHEME_OPTIONAL flag makes sense, and that wouldn't
affect BC.  If anybody is still interested in this, please pursue
the RFC process[1].

I'm changing this ticket to documentation issue, since the docs[2]
are misleading regarding the scheme (always required) and the host
(required except for mailto, news and file URIs).

[1] <https://wiki.php.net/rfc/howto>
[2] <https://www.php.net/manual/en/filter.filters.validate.php>
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Mon Nov 03 20:00:02 2025 UTC