|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
[2017-01-23 11:35 UTC] cmb@php.net
-Status: Open
+Status: Verified
[2017-01-23 11:35 UTC] cmb@php.net
[2017-01-23 11:44 UTC] nikic@php.net
[2017-09-12 10:49 UTC] cmb@php.net
-Type: Bug
+Type: Documentation Problem
-Assigned To:
+Assigned To: cmb
[2017-09-12 10:49 UTC] cmb@php.net
[2017-09-12 10:58 UTC] cmb@php.net
[2017-09-12 11:00 UTC] cmb@php.net
-Status: Verified
+Status: Closed
[2017-09-12 11:00 UTC] cmb@php.net
[2020-02-07 06:06 UTC] phpdocbot@php.net
|
|||||||||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Tue Oct 28 01:00:01 2025 UTC |
Description: ------------ The userinfo part of a URL can contain %-encoding for characters which otherwise would confuse a URL parser. Thus if your username or password contains, for instance, a @, you would be entering %40 into the URL instead. PHP's parse_url function does not perform decode this encoding, but returns the 'user' and 'pass' values with it as it was in the original URL. Alternatively, if the intent is that this function keeps the encoding in the values, this should be clearly stated in the documentation. It turns out that Drupal is calling this function, seemingly assuming that it is being completely decoded. Test script: --------------- <? var_dump(parse_url('https://user%40name:pass%40word@example.com')); ?> Expected result: ---------------- array(4) { ["scheme"]=> string(5) "https" ["host"]=> string(11) "example.com" ["user"]=> string(9) "user@name" ["pass"]=> string(9) "pass@word" } Actual result: -------------- array(4) { ["scheme"]=> string(5) "https" ["host"]=> string(11) "example.com" ["user"]=> string(11) "user%40name" ["pass"]=> string(11) "pass%40word" }