|  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
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
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 install

thttpd then :


Expected result:
Both html and php files display correctly

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


Add a Patch

Pull Requests

Add a Pull Request


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]
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 :)

 [2008-10-27 14:00 UTC]
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 :)

 [2008-11-15 00:38 UTC]
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:
 [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]
Sascha aka but I don't think he's around anymore.
 [2009-07-20 22:56 UTC]
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 for *NIX and 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.
 [2015-05-01 19:55 UTC]
-Status: Open +Status: Wont fix -Assigned To: +Assigned To: cmb
 [2015-05-01 19:55 UTC]
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] <>
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Jul 19 23:01:29 2024 UTC