ID: 21226 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Closed Bug Type: *URL Functions Operating System: w2000 PHP Version: 4.3.0 Assigned To: iliaa New Comment:
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. My thanks to [EMAIL PROTECTED] for being persistent enough to see this matter through. Previous Comments: ------------------------------------------------------------------------ [2002-12-30 09:31:56] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php http://user:[EMAIL PROTECTED]:portnumber?foo is NOT a valid url because it is missing a path, end of story. If you try to make a request to a web server without a path you will get an error, same is true for ftp. ------------------------------------------------------------------------ [2002-12-30 04:48:06] [EMAIL PROTECTED] I have the same problem ! The problem is not discussing about port number or RFC compliance, it is just about : This was working in previous version of PHP and since 4.3.0 behavior is not the same ! ------------------------------------------------------------------------ [2002-12-30 02:31:30] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. There are two things wrong with your $url value: 1) "portnumber" is not a valid portnumber, this must be a number 2) There must be a "/" between the portnumber and ANYTHING following. This does also include the "?foo" query string specified in your case where the document requested is the directory index. ------------------------------------------------------------------------ [2002-12-30 02:03:43] [EMAIL PROTECTED] Reopening this bug. A closer look at RFC 2396 indicates that: "... This "generic URI" syntax consists of a sequence of four main components: <scheme>://<authority><path>?<query> ... . .. absoluteURI = scheme ":" ( hier_part | opaque_part ) URI that are hierarchical in nature use the slash "/" character for separating hierarchical components. ... ... hier_part = ( net_path | abs_path ) [ "?" query ] net_path = "//" authority [ abs_path ] abs_path = "/" path_segments URI that do not make use of the slash "/" character for separating hierarchical components are considered opaque by the generic URI parser. opaque_part = uric_no_slash *uric uric_no_slash = unreserved | escaped | ";" | "?" | ":" | "@" | "&" | "=" | "+" | "$" | "," ..." Later in section 3.3 of that RFC the syntax of the path component is clarified. Similar clarification is made in section 3.2 on what is considered as a correct authority component. Bottomline the $url given by the bug reporter is mostly conformant to being a hierarchical URI in nature, although not the usual case. As section 3.2 that deals w/ the authority component states that: "... The authority component is preceded by a double slash "//" and is terminated by the next slash "/", question-mark "?", or by the end of the URI. Within the authority component, the characters ";", ":", "@", "?", and "/" are reserved. ..." And that is reinforced in the BNF syntax later in the RFC. Not sure if all web servers will interpret correctly a URL w/o a path but w/ a query part immediately after the authority part, in view of the fact that the "/' in the path is usually internally mapped by the server to wherever the physical files are in the filesystem. The following code works as expected: $url = "http://user:[EMAIL PROTECTED]:8080/foo.php?bar=1&boom=0";; print_r(parse_url($url)); Giving as output: Array ( [scheme] => http [host] => www.example.com [port] => 8080 [user] => user [pass] => passwd [path] => /foo.php [query] => bar=1&boom=0 ) Tested w/ current CVS head on a RH Linux 6.1 machine: $ php_cvs -v PHP 4.4.0-dev (cli) (built: Dec 27 2002 14:00:56) Copyright (c) 1997-2002 The PHP Group Zend Engine v1.4.0, Copyright (c) 1998-2002 Zend Technologies as well as 4.3.0 (on the same OS) $ php -v PHP 4.3.0 (cli) (built: Dec 29 2002 23:59:53) Copyright (c) 1997-2002 The PHP Group Zend Engine v1.3.0, Copyright (c) 1998-2002 Zend Technologies ------------------------------------------------------------------------ [2002-12-28 09:10:25] [EMAIL PROTECTED] Thank you for your works on my report, but I'm suprised you pass this report as bogus since : - 'port' was not number in my example, but it was only to be more comprehensive. Warning is the same with a digit port. - Same example was working successfully without warning in 4.2 and previous. - parse_url function manual doesn't tell about trailing slashes before path or query part of url (I triple check ;-) - RFC 2396 (Uniform Resource Identifiers (URI): Generic Syntax) doesn't specify that you *MUST* have / after port part. So if you consider these points, either you should modify parse_url function or modify parse_url documentation. But please do not just pass report as bogus!!! At worst put it a 'closed'. Thanks for your help. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/21226 -- Edit this bug report at http://bugs.php.net/?id=21226&edit=1
