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

go to bug id or search bugs for

Bug #19876 Problem with parse_url() function...
Submitted: 2002-10-11 22:54 UTC Modified: 2002-10-12 15:11 UTC
From: onionman at home dot se Assigned:
Status: Closed Package: *URL Functions
PHP Version: 4CVS-2002-10-12 OS: Windows 2000 Pro (Sp3)
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: onionman at home dot se
New email:
PHP Version: OS:

 

 [2002-10-11 22:54 UTC] onionman at home dot se 
Snapshot used: php4-win32-200210120200.zip

This simple script parses an ftp-url:

<?php
	$url = "ftp://gandalf:mellon@www.moria.com/foo/bar/index.php?page=news";
	
	$parts = parse_url($url);
	
	echo '<pre>'."\n";
	echo print_r($parts)."\n";
	echo '</pre>'."\n";
?>

When i run the script i get this output:

Array
(
    [scheme] => ftp
    [host] => www.moria.com
    [user] => gandalf
    [pass] => mello
    [path] => /foo/bar/index.php
    [query] => page=news
)
1

Note the cropped password value... it is cropped by one charachter... last snapshot i tested (2002-10-06) did not have this behaviour.

BTW: What does the 1 that is output after the value pairs mean?

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-10-11 23:00 UTC] iliaa@php.net 
The 1 comes from 'echo print_r' you do not need to echo print_r() it'll do it automatically. The missing letter is something I am unable to replicate on any of my machines. Could you please should output of phpinfo() on your system, maybe that'll yeild some clues.
 [2002-10-11 23:26 UTC] onionman at home dot se 
Here's a link to the phpinfo at my machine:

http://onionman.homeip.net/phpinfo/

A weird thing i noticed is that if i have 'html_errors = Off' in my php.ini file, then phpinfo looses all it formatting and is unreadable... is it supposed to be like this?

Anyway... i doublechecked the parse_url bug by going back to an older snapshot (2002-10-06), and there it works like expected... and then trying latest snap again (2002-10-12), and there it's the same result as before... so either something has introduced a bug there since last week... or my machine is behaving strange... ;)

/OnionMan
 [2002-10-11 23:31 UTC] iliaa@php.net 
The lack for formatting for phpinfo() when html_errors are Off is intentional. 

parse_url() was recently rewritten from scratch that probably introduced the bug you are seeing. I'll look into it in more detail.
 [2002-10-12 03:28 UTC] sesser@php.net 
Please wait until the next developer snapshot is generated and try again.
 [2002-10-12 12:56 UTC] onionman at home dot se 
I just tried this snap: php4-win32-200210121400.zip

The result is different, but still incorrect:

Array
(
    [scheme] => ftp
    [host] => ww.moria.com
    [user] => gandalf
    [pass] => :mellon@
    [path] => /foo/bar/index.php
    [query] => page=news
)

host & pass values are wrong...

/OnionMan
 [2002-10-12 14:29 UTC] iliaa@php.net 
This bug has been fixed in CVS.

In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.

The latest snapshot has this problem fixed.
http://snaps.php.net/win32/php4-win32-200210121800.zip
 [2002-10-12 15:11 UTC] onionman at home dot se 
Yep... tested it, and it works fine now.

Thanks for the fast response and fix!  :)

/OnionMan
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Fri Nov 21 10:00:01 2025 UTC