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

go to bug id or search bugs for

Bug #7615 Session management in thttpd / proxy problem
Submitted: 2000-11-03 05:11 UTC Modified: 2001-12-10 19:05 UTC
From: tictactux at surfeu dot ch Assigned:
Status: Closed Package: Other web server
PHP Version: 4.0.3pl1 OS: Linux 2.2.17 (Slackware 7.1)
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: tictactux at surfeu dot ch
New email:
PHP Version: OS:

 

 [2000-11-03 05:11 UTC] tictactux at surfeu dot ch 
I installed thttpd-2.20b with PHP 4.0.3pl1 with --with-trans-sid, --with-imap --with-sockets --with-thttpd.
I have Squirrelmail and Dragonflymail installed to check them out. Both worked.
When trying to access them via a company's firewall, login was not possible, neither via trans-sid nor cookies. I ran a network trace against both thttpd and apache (on which the very same box with the very same apps work) and saw that thttpd is very quick (as not to say impatient) at session build-up. It simply does not seem to wait until the client had answered *all* questions. It seems that the client has no time to transmit session IDs *and* POSTing the login information.
I've read somewhere that someone had as similar problem with apache which he solved by adding a delay in the session-buildup routine.
I don't know if this is a thttpd problem or php-in-thttpd problem. Other pages (that had nothing to do with session stuff) just work fine.

For the time being, I leave apache installed although its footprint is way bigger than thttpd's...

Regards, Ben

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2000-12-22 20:02 UTC] sas@php.net 
Do I understand you correctly that thttpd/PHP does not read the POST data completely?  If that is the case, PHP might not be able to get the correct POST data.

Can you provide an example for this situation (i.e. a form which gets submitted to a server which displays the variables it received)?
 [2000-12-26 04:51 UTC] tictactux at surfeu dot ch 
I think the initial post pretty much sums it up. I haven't got any sample page/app ready with authentication, cookies _and_ a firewall in between. But Dragonflymail/Squirrelmail is pretty easy to install and should yield the desired behaviour.
Don't you have kinda regression test suites ready at php's?
Now this would be a very useful addition.

Regards, Ben
 [2001-05-01 08:58 UTC] jmoore@php.net 
Can you please try this without the firewall inbetween you and the webserver and see if the firewall delay is causing the problem or if it is definatly a PHP-Thttpd problem.

- James
 [2001-05-02 03:18 UTC] tictactux at surfeu dot ch 
James,
This works OK:
thttpd <-> Firewall w/NAT <-> Internet <-> ISP <-> Client

This doesn't:
thttpt <-> Firewall <-> Internet <-> ISP <-> Proxy <-> Client

Seems that either thttpd/php does not deliver the 'proxy-no-cache' pragma or that the proxy filters out the 'no-cache' pragma on the way to the client browser.

Regards, Ben
 [2001-12-10 09:56 UTC] sas@php.net 
The POST problem has been fixed in CVS finally. Thanks for your report.
 [2001-12-10 19:05 UTC] tictactux at surfeu dot ch 
Issue closed. Thanks for your efforts.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Wed Apr 24 04:01:30 2024 UTC