Description: ------------ The patches provided speak for themselves. 1) Missing value for the second parameter of $this->setOption At line 133 - $this->setOption($optionName); + $this->setOption($optionName, $value); 2) The query string should contain anything to the fragment separator, and can be '' (empty string) At line 151 - if (preg_match('@^\?([^#]+)@', $url, $reg)) { + if (preg_match('@^\?([^#]*)@', $url, $reg)) { 3) There are some missing (unused) properties that are tried to be set, and not the right one At line 311 - $this->user = false; + $this->userinfo = false; At line 312 - $this->pass = false; 4) The userinfo (user:pass) can be omitted/empty but in that case there is no need from @ separator in the normalized url At line 315 - if (preg_match('@^(([^\@]+)\@)?([^:]+)(:(\d*))?$@', $authority, $reg)) { + if (preg_match('@^(([^\@]*)\@)?([^:]+)(:(\d*))?$@', $authority, $reg)) { At line 316 - if ($reg[1]) { + if ($reg[1] && strlen($reg[2])) { P.S First I would like to apologize for the bad posted bug report (may be). Second I haven`t read RFCs but I tested the behavior with common browsers.

Radoslav, any chance of lodging other bugs for the individual problems? That way we can improve our unit test coverage :) Anyway, thanks for the patches - they are a little outdated against the CVS version, but we can still probably fix 'em.

The fixe for line 133, 311, 312 and 315 have now been applied - thanks. AFAICT line 151 has always looked like the line you are suggesting, hasn't it? WRT line 316, the RFC does not explicitly say that an empty userinfo is equivalent to a non-existing userinfo, so I am reluctant about changing this. I guess one could argue, that trying to access a resouce with an explicitly set empty password is different from accessing it without having supplied a password at all. BTW, the URL parsing done in the constructor is not trying to do any normalization but rather store the various parts in a verbatim fashion. Any normalization is done in normalize().

Wanna make a decision?

This bug has been fixed in SVN. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better. I believe all of those that make sense to fixed are already fixed in SVN.