php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #15885 thttpd can't serve 0 byte files with PHP patches
Submitted: 2002-03-05 12:59 UTC Modified: 2002-11-06 11:17 UTC
From: daniel-gl at gmx dot net Assigned:
Status: Closed Package: Other web server
PHP Version: 4.1.2 OS:
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem:
24 + 12 = ?
Subscribe to this entry?

 
 [2002-03-05 12:59 UTC] daniel-gl at gmx dot net
PHP for thttpd sets TG(hc)->file_address = (char *)1 to mark a connection as "don't close".
thttpd used this value to mark files without mapped memory (0 byte files). When such a file is requested, the client hangs.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-11-03 11:07 UTC] iliaa@php.net
Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip


 [2002-11-04 15:34 UTC] daniel-gl at gmx dot net
Sorry, I don't remember that password after 8 months.
Hmm... file_address is still set to (char *)1... 
Anyway, it appears to be ok now.

But I noticed another difference between thttpd with and without php4-latest. Plain thttpd 2.21b issues a 408 after exactly 1 minute when the client has not sent any request. With php4-latest the connection is just closed without any error and the time is sometimes as short as 4 seconds. My 2.22beta4 with (patched) PHP 4.1.2 reacts correctly like plain thttpd.
 [2002-11-06 11:17 UTC] sas@php.net
The zero-size file problem was caused by a conflict of special values between mmc and php.  The conflict has been resolved for some time.

The observed difference in expiring connections is true.  Note however that the new behaviour conforms to RFC 2616.  Especially, section 8.1.4 states:

"A client, server, or proxy MAY close the transport connection at any time. [..]

"This means that clients, servers, and proxies MUST be able to recover from asynchronous close events. [..]
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sun Mar 03 00:01:29 2024 UTC