php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #15432 fopen does not work with password-protected URLs
Submitted: 2002-02-07 14:01 UTC Modified: 2003-05-21 05:47 UTC
From: mqm at magma dot ca Assigned:
Status: Not a bug Package: HTTP related
PHP Version: 4.1.0 OS: Windows 2000
Private report: No CVE-ID: None
 [2002-02-07 14:01 UTC] mqm at magma dot ca
  I am trying to fetch the web page from my Linksys ADSL router, which is password-protected, but fopen does not seem to understand the URL format where a user/password is provided (like with FTP). See below.

<?php

$linksys_info_url = "http://user:password@192.168.3.1/Status.htm";
$f_page = @fopen ($linksys_info_url, "r");
if ($f_page) {
	$page_contents = fread ($f_page, 1024);
	fclose ($f_page);
	print ($page_contents);
} else {
	echo "Can't fetch the page ($linksys_info_url), so I am giving up !!";
}
?>

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-02-07 16:14 UTC] mqm at magma dot ca
Both curl and the web browser can fetch the document using the notation below, no problem (so, the user/password is correct).

I was also able to fetch a password-protected page from dhs.org via PHP, so I am not sure why it is failing for the Linksys web server. Maybe if I could debug what is being sent/received over the wire.


 [2002-02-07 17:48 UTC] edink@php.net
I cannot reproduce this neither on Linux nor on Windows 2000. Does that URL create any http redirects? Do you get any error messages if you remove @ before fopen?
 [2002-02-07 17:54 UTC] mqm at magma dot ca
curl (like wget) can fetch the page, so I don't think there are any redirects.

This is what I get if I remove the @ before fopen:

<font color=ff0000><br>
<b>Warning</b>:  fopen("http://...@192.168.3.1/Status.htm", "r") - No error in <b>C:\Xitami\webpages\test.php</b> on line <b>5</b><br>
</font>Can't fetch the page (http://user:password@192.168.3.1/Status.htm), so I am giving up !!
 [2002-02-07 18:06 UTC] edink@php.net
cURL can handle redirects on pages with password protection. PHP cannot do that yet. There must be something special about that page since I can read pages protected by password under my Apache server with no problems.

As a temporary workaround I suggeest you use cURL extension until we can find a publicly available site where this problem can be reproduced.
 [2002-02-07 18:07 UTC] mqm at magma dot ca
I used a sniffer to compare teh HTTP request from PHP (which fails) to the one from CURL (which works). Here's it:

PHP request & start of reply:

Data
S/R    Packet      Offset      Hex                                                ASCII
S      0x0001      0x0000      47 45 54 20 2F 53 74 61-74 75 73 2E 68 74 6D 20    GET /Status.htm 
S      0x0001      0x0010      48 54 54 50 2F 31 2E 30-0D 0A                      HTTP/1.0..      
S      0x0002      0x0000      41 75 74 68 6F 72 69 7A-61 74 69 6F 6E 3A 20 42    Authorization: B
S      0x0002      0x0010      61 73 69 63 20 65 44 70-6A 59 57 35 68 5A 47 46    asic eDpjYW5hZGF
S      0x0002      0x0020      76 0D 0A               -                           v..             
S      0x0003      0x0000      48 6F 73 74 3A 20 31 39-32 2E 31 36 38 2E 33 2E    Host: 192.168.3.
S      0x0003      0x0010      31 0D 0A               -                           1..             
S      0x0004      0x0000      55 73 65 72 2D 41 67 65-6E 74 3A 20 50 48 50 2F    User-Agent: PHP/
S      0x0004      0x0010      34 2E 31 2E 30 0D 0A 0D-0A                         4.1.0....       

R      0x0005      0x0000      48 54 54 50 2F 31 2E 31-20 34 30 31 20 41 75 74    HTTP/1.1 401 Aut
R      0x0005      0x0010      68 6F 72 69 7A 61 74 69-6F 6E 20 52 65 71 75 69    horization Requi
R      0x0005      0x0020      72 65 64 0D 0A 57 57 57-2D 41 75 74 68 65 6E 74    red..WWW-Authent
R      0x0005      0x0030      69 63 61 74 65 3A 20 42-61 73 69 63 20 72 65 61    icate: Basic rea
R      0x0005      0x0040      6C 6D 3D 22 4C 69 6E 6B-73 79 73 20 42 45 46 53    lm="Linksys BEFS
R      0x0005      0x0050      52 34 31 2F 42 45 46 53-52 31 31 2F 42 45 46 53    R41/BEFSR11/BEFS
R      0x0005      0x0060      52 55 33 31 22 0D 0A 43-6F 6E 74 65 6E 74 2D 74    RU31"..Content-t
R      0x0005      0x0070      79 70 65 3A 20 74 65 78-74 2F 68 74 6D 6C 0D 0A    ype: text/html..


CURL request & piece of reply:

Data
S/R    Packet      Offset      Hex                                                 ASCII
S      0x0001      0x0000      47 45 54 20 2F 53 74 61-74 75 73 2E 68 74 6D 20     GET /Status.htm 
S      0x0001      0x0010      48 54 54 50 2F 31 2E 31-0D 0A 41 75 74 68 6F 72     HTTP/1.1..Author
S      0x0001      0x0020      69 7A 61 74 69 6F 6E 3A-20 42 61 73 69 63 20 65     ization: Basic e
S      0x0001      0x0030      44 70 6A 59 57 35 68 5A-47 46 76 0D 0A 55 73 65     DpjYW5hZGFv..Use
S      0x0001      0x0040      72 2D 41 67 65 6E 74 3A-20 63 75 72 6C 2F 37 2E     r-Agent: curl/7.
S      0x0001      0x0050      39 2E 32 20 28 77 69 6E-33 32 29 20 6C 69 62 63     9.2 (win32) libc
S      0x0001      0x0060      75 72 6C 20 37 2E 39 2E-32 20 28 4F 70 65 6E 53     url 7.9.2 (OpenS
S      0x0001      0x0070      53 4C 20 30 2E 39 2E 36-62 29 0D 0A 48 6F 73 74     SL 0.9.6b)..Host
S      0x0001      0x0080      3A 20 31 39 32 2E 31 36-38 2E 33 2E 31 0D 0A 50     : 192.168.3.1..P
S      0x0001      0x0090      72 61 67 6D 61 3A 20 6E-6F 2D 63 61 63 68 65 0D     ragma: no-cache.
S      0x0001      0x00A0      0A 41 63 63 65 70 74 3A-20 69 6D 61 67 65 2F 67     .Accept: image/g
S      0x0001      0x00B0      69 66 2C 20 69 6D 61 67-65 2F 78 2D 78 62 69 74     if, image/x-xbit
S      0x0001      0x00C0      6D 61 70 2C 20 69 6D 61-67 65 2F 6A 70 65 67 2C     map, image/jpeg,
S      0x0001      0x00D0      20 69 6D 61 67 65 2F 70-6A 70 65 67 2C 20 2A 2F      image/pjpeg, */
S      0x0001      0x00E0      2A 0D 0A 0D 0A         -                            *....           

R      0x0002      0x0000      48 54 54 50 2F 31 2E 31-20 32 30 30 20 4F 4B 0D     HTTP/1.1 200 OK.
R      0x0002      0x0010      0A 43 6F 6E 74 65 6E 74-2D 74 79 70 65 3A 20 74     .Content-type: t
R      0x0002      0x0020      65 78 74 2F 68 74 6D 6C-0D 0A 45 78 70 69 72 65     ext/html..Expire
R      0x0002      0x0030      73 3A 20 54 68 75 2C 20-31 33 20 44 65 63 20 31     s: Thu, 13 Dec 1
R      0x0002      0x0040      39 36 39 20 31 30 3A 32-39 3A 30 30 20 47 4D 54     969 10:29:00 GMT
R      0x0002      0x0050      0D 0A 50 72 61 67 6D 61-3A 20 6E 6F 2D 63 61 63     ..Pragma: no-cac
R      0x0002      0x0060      68 65 0D 0A 0D 0A 3C 68-74 6D 6C 3E 3C 68 65 61     he....<html><hea



 [2002-02-07 19:00 UTC] mqm at magma dot ca
For those who can't read hexdump/ascii together:

CURL:

GET /Status.htm HTTP/1.1
Authorization: Basic eDpjYW5hZGFv
User-Agent: curl/7.9.2 (win32) libcurl 7.9.2 (OpenSSL 0.9.6b)
Host: 192.168.3.1
Pragma: no-cache
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*

PHP:

GET /Status.htm HTTP/1.0
Authorization: Basic eDpjYW5hZGFv
Host: 192.168.3.1
User-Agent: PHP/4.1.0

 [2002-02-07 19:02 UTC] mqm at magma dot ca
The problem seems to be the HTTP/1.0

If I telnet to port 80 and manually send the headers below, it all works.

GET /Status.htm HTTP/1.1
Authorization: Basic eDpjYW5hZGFv
Host: 192.168.3.1
User-Agent: PHP/4.1.0

Maybe the Linksys does not like the HTTP/1.0 line.
 [2002-02-07 22:49 UTC] shiflett@php.net
Since you can sniff traffic, can you inspect the HTTP response as well? Perhaps your LinkSys web server software is asking to upgrade to HTTP/1.1 (since "upgrading" your request's declared version appeared to solve it).

If not, it might at least reveal some sort of HTTP response code that is causing problems for PHP.
 [2002-02-08 09:33 UTC] mqm at magma dot ca
This is the response from the Linksys to PHP:

HTTP/1.1 401 Authorization Required
WWW-Authenticate: Basic realm="Linksys BEFSR41/BEFSR11/BEFSRU31"
Content-type: text/html
Expires: Thu, 13 Dec 1969 10:29:00 GMT
Pragma: no-cache

<html><head><title>401 Authorization Required</title></head>
<body bgcolor=red text=white><h1>401 Authorization Required</h1>
This server could not verify that you are authorized to access.
Either you supplied the wrong credentials(e.g., bad password),
or your browser doesn't understand how to supply the credentials
required </body></html>
 [2002-02-08 10:46 UTC] shiflett@php.net
There's the problem. Your LinkSys "web server" did not like the way PHP was passing the authorization information. However, since it used the exact same Authorization header as your browser's request, there is no good reason why the response should demand a username/password, since they were sent successfully in the initial request.
 [2003-05-20 17:34 UTC] antispam at jensenworld dot net
Unclear what the resolution was for this, is there a way to get php to say HTTP/1.1 instead of HTTP/1.0?  I am having a similar problem, but I am getting:

<br>
<b>Warning</b>:  fopen("http://...@192.168.1.1/", "r") - Inappropriate ioctl for device in <b>/home/exoplanet/devel/php_test/urlcp.php</b> on line <b>17</b><br>

Line 17 is the fopen.....
 [2003-05-20 21:26 UTC] mqm at magma dot ca
Linksys is being dumb by refusing to serve an HTTP 1.0 request. PHP is being dumb by saying it is HTTP 1.0 ( why can't it say 1.1 ? any real technical reason ?). That's basically what it boils down to.

In my case I fork wget from PHP, fetch the page saving to a file, and process it from PHP. Ugly but works. Maybe one day I'll be able to use a pure PHP solution... [sigh]
 [2003-05-21 05:47 UTC] wez@php.net
read the rfcs for the differences between http/1.1 and 1.0.
PHP uses 1.0 as it is much easier to implement.
PHP 5 *might* have 1.1 support.
If you really need advanced http usage, consider using the curl extension.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Nov 14 00:01:33 2024 UTC