|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
[2015-07-01 12:17 UTC] flavio dot cambraia at yahoo dot com dot br
Description:
------------
The parsed url must have at least 6 chars after colon or it returns false.
Test script:
---------------
<?php
$res = parse_url("/busca/?fq=B:20001");
var_dump($res);
echo "<br>";
$res = parse_url("/busca/?fq=B:200013");
var_dump($res);
echo "<br>";
$res = parse_url("/busca/?fq=home:01234");
var_dump($res);
echo "<br>";
$res = parse_url("/busca/?fq=home:012345");
var_dump($res);
echo "<br>";
?>
Expected result:
----------------
The first and third parse return false. The second and fourth are ok.
It happens because of the colon char. It needs at least 6 chars after colon to parse correctly.
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
|
|||||||||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Wed Oct 29 03:00:01 2025 UTC |
Good catch, Yasuo. Thanks. I'm, however, not sure if the change is worth an entry in UPGRADING – it might mostly add noise. I can imagine only rather weird edge cases to be affected, such as: php -r "var_dump(parse_url('//u?er@example.com:8888/foo.bar'));" Which currently gives: bool(false) and after the patch: array(2) { ["path"]=> string(3) "//u" ["query"]=> string(27) "er@example.com:8888/foo.bar" } Both not very useful, the latter being definitely wrong wrt. RFC 1738, though. Maybe it's better to revert the commit? Then again, the latter result is correct wrt. RFC 3986. It seems to me that we need to decide which RFC is catered to by parse_url().