php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #5942 PHP4 either does not parse html/htm files or breaks autorization
Submitted: 2000-08-03 12:08 UTC Modified: 2000-08-23 08:15 UTC
From: byg at fis dot ru Assigned:
Status: Closed Package: Scripting Engine problem
PHP Version: 4.0.1pl2 OS: FreeBSD 3.3
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: byg at fis dot ru
New email:
PHP Version: OS:

 

 [2000-08-03 12:08 UTC] byg at fis dot ru
 The smallest available script to show the bug:  <? phpinfo(); ?>

 Apache 1.3.12 RA patches PL29.7, mod_auth_pgsql 0.9.
Compiled-in modules:
  http_core.c
  mod_charset.c
  mod_env.c
  mod_log_config.c
  mod_mime.c
  mod_negotiation.c
  mod_status.c
  mod_include.c
  mod_autoindex.c
  mod_dir.c
  mod_cgi.c
  mod_asis.c
  mod_imap.c
  mod_actions.c
  mod_userdir.c
  mod_alias.c
  mod_access.c
  mod_auth.c
  mod_setenvif.c
  mod_php4.c
  mod_auth_pgsql.c

 When complied as built-in module, PHP4 either doesn't parse html/htm files or breaks normail operation
of authorization (due to wrong response 200 instead of 401). This magically depends on location of
Document_Root and httpd.conf.
 When compiled as DSO, PHP4 does not parse the stream at all.
I have tested all combination of AddType/AddHandler/mime.types and have no luck.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2000-08-03 20:01 UTC] rasmus@php.net
I am having problems parsing this bug report.  Have you registered .html as a PHP mime type?
And if you are doing Apache-level HTTP authorization, this is done well before PHP gets involved in the request process, so I don't understand that part of your bug report either.
Please try to explain yourself better and re-submit with a single problem per bug report.
 [2000-08-04 09:14 UTC] byg at fis dot ru
> I am having problems parsing this bug report.  Have you registered .html as a PHP mime type?
Yep. As I already told, I had tried all available combination of AddType/AddHandler/mime.types and I had no luck.
I'd notice that there's proven working httpd.conf, which is working fine with 3.0.16.
(AFAIK the only difference between configs for PHP3 and PHP4 modules is
application/x-httpd-php3->application/x-httpd-php conversion)
I should emphase that the behaviour depends on location of httpd.conf and Document_Root.
It either doesn't parse htm/html files or has problems with authorization.
> And if you are doing Apache-level HTTP authorization, this is done well before PHP gets involved in the request process, so I don't understand that part of your bug report either.
> Please try to explain yourself better and re-submit with a single problem per bug report.
> 
I consider that there's a PHP4 issue because:
1) with PHP3 all works fine
2) without PHP all works fine
3) PHP4 is able to break Apache output headers (due to its ability to change
Content-Type)
4) Apache level authorization seems to be work as required since it supplies the right
Error page at first stage (consequently, it has recognized .htaccess content).
I consider there's a bug in headers processing, look:

===============================
telnet www.fis.ru 8080
Trying 212.20.24.193...
Connected to relay.fis.nsk.su.
Escape character is '^]'.
get /val/val/ http/1.0

HTTP/1.1 200 OK
Date: Fri, 04 Aug 2000 02:22:14 GMT
Server: Apache/1.3.12 (Unix) PHP/4.0.1pl2 rus/PL29.4
X-Powered-By: PHP/4.0.1pl2
Connection: close
Content-Type: text/html
Expires: Thu, 01 Jan 1970 00:00:01 GMT
Last-Modified: Fri, 04 Aug 2000 02:22:15 GMT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<HEAD>
        <TITLE>??????</TITLE>
<LINK href="/Gi/Error/page.css" rel=stylesheet type=text/css>
[further there Error explanation follows - snipped]
================================
now the right one:
================================
telnet www.fis.ru 80
Trying 212.20.24.193...
Connected to relay.fis.nsk.su.
Escape character is '^]'.
get /val/val/ http/1.0

HTTP/1.1 401 Authorization Required
Date: Fri, 04 Aug 2000 02:25:03 GMT
Server: Apache/1.3.12 (Unix) PHP/3.0.16 rus/PL29.4
X-Powered-By: PHP/3.0.16
Connection: close
Content-Type: text/html
Expires: Thu, 01 Jan 1970 00:00:01 GMT
Last-Modified: Fri, 04 Aug 2000 02:25:05 GMT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<HEAD>
        <TITLE>??????</TITLE>
<LINK href="/Gi/Error/page.css" rel=stylesheet type=text/css>
[further there Error explanation follows - snipped]
==================================
The difference consist in HTTP/1.1 200 OK header which is essentially illegal here.
As a result, users see "Access denied" without prompting by their browsers to give credentials though the browsers suppose that's OK. Bad.

I guess the problem maybe not in PHP4 itself but in the way how it makes calls to libraries.
Does it possible to give me a hint where could be cause?

 [2000-08-14 06:50 UTC] byg at fis dot ru
Synopsis:
After installing PHP4 does not wanna parse .html/.htm files.
This is very strange 'cos PHP3 works just fine (I'm using the same httpd.conf and php.ini with the smallest possible
modification to reflect php3->php changing).

More:
I've checked out more accurate: this bug appears only on FreeBSD 3.3. I've upgraded one of my servers from 3.3
to 3.5 first, then to 4.1 release. Neither has the reported bug. I suppose the SuSe users, whom had reported the
similar problem, should also try to upgrade their systems as a last resort. Maybe the cause is in thread mechanism?
BTW, I'm running FreeBSD 3.2 also. It has no the bug too.

Anyway I have almost solved my problem but this bug may cause other quirks in the future.

 [2000-08-23 08:15 UTC] sniper@php.net
If problem was solved by updating your system this 
can not be problem with php4 ??

--Jani
 
PHP Copyright © 2001-2026 The PHP Group
All rights reserved.
Last updated: Sat Oct 10 20:00:02 2026 UTC