php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #45062 thttpd problem displaying .html pages when patched with php on 64 bits OS
Submitted: 2008-05-21 22:03 UTC Modified: 2015-05-01 19:55 UTC
Votes:2
Avg. Score:3.5 ± 0.5
Reproduced:2 of 2 (100.0%)
Same Version:2 (100.0%)
Same OS:2 (100.0%)
From: j dot orfeuil at courantmultimedia dot fr Assigned: cmb (profile)
Status: Wont fix Package: Other web server
PHP Version: 5.2.6 OS: debian 4.0 x86_64
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2008-05-21 22:03 UTC] j dot orfeuil at courantmultimedia dot fr
Description:
------------
thttpd problem displaying .html pages when patched with php :

gcc 4.1 or gcc 3.3
In all cases, thttpd and php compile well.

Compiling thttpd alone => .html files display correctly
Compiling php with thttpd (--with-thttpd option) and then thttpd => .php files display correctly but .html file cause thttpd server to crash.

This behaviour doesn't occur on an 32bits systems but only on my 64 bits debian OS.

My guess is patchning thttpd sources with php when compiling causes types problems (maybe buffer lenght problems) with 64bits OS.

Reproduce code:
---------------
Compilation options :

php first :

./configure --with-thttpd=thttpd_source_dir
make
make install

thttpd then :

./configure
make

Expected result:
----------------
Both html and php files display correctly

Actual result:
--------------
Only php files display correctly. Html files causes thttpd to crash

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2008-05-22 07:23 UTC] j dot orfeuil at courantmultimedia dot fr
thttpd v2.21b
 [2008-10-25 13:15 UTC] jani@php.net
Does someone actually maintain thttpd anymore? Have you ever heard of 
lighttpd and FastCGI..? 

 [2008-10-27 08:44 UTC] j dot orfeuil at courantmultimedia dot fr
First of all thx for the answer :)
Of course i've heard about other light web servers thx but the fact is
we already have a whole system running on thttpd.
We actually just need to move our system on a new hardware plateform (actually on many VPS on a new hardware plateform) and a new OS based on 64bits debian system. For obvious bug reasons and testing time, we just wanted to "clone" the web part as it is bugless (or at least with small ones :p)
Changing webserver would be an idea and it would probably work but we wanted to understand why there was a problem with specific 64 bits OS... (as we believe it is related to patching thttpd sources with php...) and of course, as i said before, for bug reason...

On the other hand i don't know if thttpd is still maintained and it would be recommended to change for an active project but the version we have is stable and if the bug comes from php, we would have no reason to change.

Well, hoping you can understand our needs and why we're still looking for a lead through php bugs, maybe you could help us :)

Regards
Joseph
 [2008-10-27 14:00 UTC] jani@php.net
I doubt anyone has updated the thttpd patch required so I doubt it will ever work in 64bit systems.
 [2008-10-27 14:15 UTC] j dot orfeuil at courantmultimedia dot fr
Hum ok,
this was a little bit the aim of this report... to know whether this was gonna be fixed.
Why did php support thttpd in first place if it's not supported after?
Well, if you have any lead or any patch or even a strict "no, we won't correct this" please let me know :)
Or maybe a good man could pass hereby and say : I will fix this :)
Otherwise maybe with a lead we could do it ourselves.
Thx anyway :)

Regards
Joseph
 [2008-11-15 00:38 UTC] kalle@php.net
If only a single developer inital used and developed the sapi, then other developers may not known the internals of how that sapi works for testing.

But could you provide a backtrace as described in the link below:
http://bugs.php.net/bugs-generating-backtrace.php
 [2008-11-21 15:42 UTC] j dot orfeuil at courantmultimedia dot fr
Ok thx for the answer :)
Is there any way to find out who worked on this sapi? Maybe it could help to contact him directly...

Anyway i'll try to provide a backtrace of what's going on. At least, this will make things clear and provide a lead for solving :)
Thx for this link :)

thank you guys for your help and see you soon with the backtrace.
 [2008-11-21 16:31 UTC] jani@php.net
Sascha aka sas@php.net but I don't think he's around anymore.
 [2009-07-20 22:56 UTC] kalle@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.


 [2009-07-21 07:31 UTC] j dot orfeuil at courantmultimedia dot fr
Yes that's what i thought.
This issue is not anymore an urgent problem for me but i guess it will become one again when we will be back to the task using it....

Does anyone know someone able to update thttpd patch for php on 64bits?

Thanks for your support)
 [2009-07-21 07:33 UTC] j dot orfeuil at courantmultimedia dot fr
And i still need to provide a backtrace i guess...
I'll do that as soon as i can but as i said in the previous post i'm not working on it right now.
Thx)
 [2015-05-01 19:55 UTC] cmb@php.net
-Status: Open +Status: Wont fix -Assigned To: +Assigned To: cmb
 [2015-05-01 19:55 UTC] cmb@php.net
The thttpd SAPI will be removed from PHP 7[1], so I assume nobody
will take care to fix this issue (if it hasn't already be fixed in
the meantime).

[1] <https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts#sapithttpd>
 
PHP Copyright © 2001-2020 The PHP Group
All rights reserved.
Last updated: Sun Sep 27 09:01:23 2020 UTC