Bug #1249 Updated: url_parse() is a bit too strict

ID: 1249 Updated by: sniper Reported By: kundrat@general-it.sk Old-Status: Critical Status: Closed Bug Type: URL related Operating system: PHP Version: 4.0 Assigned To: Comments: Fixed in CVS. Now it behaves more consistently. ie. if ? is present, the query key is set. And if # is present, the fragment key is set. --Jani Previous Comments: --------------------------------------------------------------------------- [2001-05-07 12:54:49] derick@php.net marking as fix before 4.0.6 --------------------------------------------------------------------------- [2001-05-07 07:57:14] cardinal@php.net If this isn't a bug, it is at least an inconsistency. parse_url('?') doesn't set a query key parse_url('?#fragment') does Neither URL has what I would consider a query string, but the query key is set in the second case. That behavior should be consistent one way or the other, imho. --------------------------------------------------------------------------- [2001-05-02 21:12:26] sniper@php.net To PHP-developers: Does anyone have any thoughts about this? (IMO, this isn't any bug) --Jani --------------------------------------------------------------------------- [2001-02-22 12:23:56] kundrat@general-it.sk If you get URL as user input it can be bogus. parse_url could be very useful to find if the URL is bogus and what parts of it are bogus. Another point is, that even bogus looking URL's could be valid (partial only). Also i believe that parse_url('path?') wouldnt have quere set (although i cant verify it at the moment). And the last point is correctness. Even if it is not significant, it would be nice if it behaved the expected way. --------------------------------------------------------------------------- [2001-02-22 10:56:18] stas@php.net I, personally, don't see why it has to parse such bogus URLs at all... Any arguments? --------------------------------------------------------------------------- The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online. ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=1249&edit=2