php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

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 Developer Edit
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: daniel-gl at gmx dot net
New email:
PHP Version: OS:

 

 [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

Pull Requests

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: Sat Dec 21 17:01:58 2024 UTC