Since this problem is probably not common with the password field, maybe
search(b,"/")==-1 && search(b,":")==-1)
would be a better kludge.
Is this malformed format widespread enough to warrant a change in the library? Why not just fix the string before you feed it into Standards.URI and maybe report the site/tool that generates it?
I'm not going to run a proxy in between just because there might be a malformed URI returned as a 302 redirect.
pike-devel@lists.lysator.liu.se