ID: 16337 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: HTTP related Operating System: Unix based PHP Version: 4.1.0 New Comment:
RFC 2068 is obsoleted by RFC 2616, so your assumption that RFC 2068 is still adhered to is incorrect. The username:password string is base-64 encoded for Basic Authentication, which I'm going to assume you're using, since you didn't mention what type of authentication the server demands for access to http://www.example.org/. It is not URL encoded. Now, as for your bug report, why in the world would the include function *decode* the username:password string? The content coming back from the server doesn't specify the username and password to be used; that's what *you* sent. See RFC 2617 for more information about both Basic and Digest Authentication over HTTP. http://ietf.org/rfc/rfc2617.txt will point you there. I think a better understanding of this might help you solve your problem on your own. However, if this does not help, it should at least allow you to better explain what the problem is, because your reports have too many holes for me to understand what problem you are having, whether a bug in PHP or not. Previous Comments: ------------------------------------------------------------------------ [2002-04-10 20:01:07] [EMAIL PROTECTED] in case anyone wondered, the HTTP spec I am refering to, is at: http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc2068.html (Section 11.1) Since RFC 2616 doesn't specify user-pass strings, I assume this older RFC still applies. ------------------------------------------------------------------------ [2002-04-10 19:57:48] [EMAIL PROTECTED] Correction: PHP's fopen url wrapper doesn't appear to unencode ANY encodings at all. Since the HTTP spec only excludes ':' from the username (and nothing at all from the password), this bug makes many username:password pairs unusable. ------------------------------------------------------------------------ [2002-03-28 18:12:28] [EMAIL PROTECTED] When include() is called with the following syntax: include("http://username:[EMAIL PROTECTED]/";); It is the duty of the include call to tokenize the username and password, and to urldecode each of them. Why? Because things would break if a username contained 'www.example.com/?var=' or say a password contained an @. So, it is the duty of the caller to urlencode these tokens, and the duty of include (or a sub function) to unencode it after parsing. However, it has been observed in PHP 4.1.x that '%' characters (or their equivalent '%25') are not decoded properly. Prior use of this feature leads us to believe the 4.0.x series of PHP does not have this problem. We run websites with hundreds of users. We would appreciate a quick response, because we would rather not force all users with '%'s in their passwords to change them. Thank you. ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=16337&edit=1
