phil ringnalda

This certainly feels like a bug in Snoopy, the HTTP client class for PHP, but I hate to have my first contact with a project be filing a bug that turns out to be just my stupidity. (So, instead, I’ll wave the bug around in public, because you don’t feel like public to me: if I had an office, you would be asking my officemates.)

$snoopy->fetch("http://user:pass@example.com") will do Basic authentication with the username “user” and password “pass” at example.com. That’s good. However, it breaks up the URL with PHP’s url_parse(), which either naively or strictly says that everything after the scheme up to the first instance of “@” is a username or a username and password, and everything after that first “@” is host and path. If your username happens to be me@example.org then properly you should use http://me%40example%2Eorg:pass@example.com. However, Snoopy doesn’t urldecode() what url_parse() passes it, and putting me%40example%2Eorg (base64_encode()ed) in the Authorization: Basic header doesn’t work. So, finally, my question is, shouldn’t Snoopy be saying

134		if (!empty($URI_PARTS["user"]))
135			$this->user = urldecode($URI_PARTS["user"]);
136		if (!empty($URI_PARTS["pass"]))
137			$this->pass = urldecode($URI_PARTS["pass"]);

even though that’s going to be a nasty surprise to anyone who has a username or password that’s something like foo%20 that they’ve been putting in without URL encoding the % sign? After all, they’re doing the wrong thing, and I just don’t see any way to push a username including an at, colon, or full stop through otherwise.