php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #7373 PHP fails with error 0 in fopen() on some URLs that IE & Netscape can
Submitted: 2000-10-20 16:04 UTC Modified: 2000-10-30 11:21 UTC
From: david at pastornet dot net dot au Assigned:
Status: Closed Package: HTTP related
PHP Version: 4.0.2 OS: Solaris 2.6
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: david at pastornet dot net dot au
New email:
PHP Version: OS:

 

 [2000-10-20 16:04 UTC] david at pastornet dot net dot au
Two issues:

Issue [1]:
     Some URLS (eg those served by the Java Server Pages
     engine contributed to apache by sun, now called
     jakarta-tomcat) fail to fopen() from PHP 3 and 4 when IE
     and Netscape can open them without a problem.  This
     is not strictly a PHP problem, but it is very easy to make
     PHP be a little more tolerant in this area.  I've included
     a fix below:- please check it for me!!

     I checked the HTTP spec and it seems that the cause of
     the problem is that jakarta-tomcats reports an HTTP status line
     that looks like "HTTP/1.1 200" and DOES NOT include a
     space character after the 200 which according to the
     spec [quoted below] likely should.  This breaks PHP, and PHP's
     error reporting in this situation is pretty abysmal.

From the HTTP spec:
   ----------------------------------------------------------------------------------------
   6.1 Status-Line

   The first line of a Response message is the Status-Line, consisting
   of the protocol version followed by a numeric status code and its
   associated textual phrase, with each element separated by SP
   characters. No CR or LF is allowed except in the final CRLF sequence.

       Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
   ----------------------------------------------------------------------------------------

I have a solution to this problem, in main/fopen-wrappers.c
in the portion of code where it reads the HTTP response from the server.

The relevant code fragment processes the "HTTP/1.x 200....." response
received from the server.

608,610c608,617
<                       if (strncmp(tmp_line + 8, " 200 ", 5) == 0) {
<                               reqok = 1;
<                       }
---
>             if (strncmp(tmp_line + 8, " 200", 4) == 0) {
>                 if(tmp_line[12] == '\0' || isspace(tmp_line[12]))
>                     reqok = 1;
>                 else
>                     php_error(E_WARNING,
>                               "Invalid HTTP response received: %s", tmp_line);
>             } else {
>                 php_error(E_WARNING,
>                           "Invalid HTTP response received: %s", tmp_line);
>             }

Issue [2]:
     I noticed this issue when chasing [1].  The replacement code I am offering
     in [1] does not correct this problem.

     The usage of tmp_line + 8 seems to violate the HTTP 1.1 spec, because for
     an example, it would be quite valid for them to introduce a new HTTP
     version "1.11" before "1.2" and this would break PHP because the status code
     would be at tmp_line + 9 instead of tmp_line + 8.

     0123456789 [tmp_line index, view this with non-proportional font]
     HTTP/1.1 200
     HTTP/1.11 200

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2000-10-30 11:21 UTC] stas@php.net
I guess this is not PHP bug - standard clearly says there should be a space.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Dec 27 15:01:29 2024 UTC