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
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: 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 
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-2024 The PHP Group
All rights reserved. 		Last updated: Wed Dec 04 19:01:32 2024 UTC