|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
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
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 Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: ian+php at ians-net dot co dot uk
New email:
PHP Version: OS:


 [2016-05-31 09:26 UTC] ian+php at ians-net dot co dot uk
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

Test script:
var_dump(filter_var("//", FILTER_VALIDATE_URL));

Expected result:

Actual result:


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2016-05-31 10:07 UTC]
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
 [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]
-Operating System: OpenBSD +Operating System: irrelevant
 [2016-12-22 10:18 UTC]
FYI. "//" is supported by parse_url() and URL rewriter by default.

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]
-Type: Bug +Type: Documentation Problem
 [2021-04-22 11:46 UTC]
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] <>
[2] <>
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Feb 29 05:01:28 2024 UTC