On 1/31/07, Todd Finney [EMAIL PROTECTED] wrote:
Wouldn't throwing a
return DECLINED unless $r-is_initial_req;
at the top of the handler fix the problem, in that case?
Probably, if you don't actually need this handler to run for the final
URI. What's the purpose of the handler?
On 1/31/07, Todd Finney [EMAIL PROTECTED] wrote:
It's responsible for making sure that the client has a session, and it
takes any of the values in the session and stores them in pnotes.
Are you sure that you had removed all of these when you did the test
of copying the session_id, and it still
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, Jan 31, 2007 at 08:29:55AM -0500, Perrin Harkins wrote:
On 1/31/07, Todd Finney [EMAIL PROTECTED] wrote:
Wouldn't throwing a
return DECLINED unless $r-is_initial_req;
at the top of the handler fix the problem, in that case?
On Jan 30, 2007, at 4:47 PM, Todd Finney wrote:
I have two servers running in the light/heavy configuration as
outlined in the guide. Both servers are 1.3.34. On the
lightweight server, my proxy section looks like this:
first off, you should be running 2.0.x by now
try this:
my
On Jan 30, 2007, at 6:44 PM, Todd Finney wrote:
The bigger, fancier test case checks all of that.
ok. great. sorry for assuming you didn't have that already -- just
have to be sure.
What I posted was a simplified test case, in order to demonstrate
the problem in as few lines of code
On 1/30/07, Todd Finney [EMAIL PROTECTED] wrote:
- When I fire up a new browser and access http://192.168.0.4/, the browser
hangs. In my bigger fancier handler with more detailed logging, it seems
to hang right before the session tie.
Any time that Apache::Session hangs, it's because of the
On 1/30/07, Todd Finney [EMAIL PROTECTED] wrote:
The sessions are modified on every request, to set a last_access time, and
they're modified on login to set an authentication token. I can't think of
circumstances under which two different requests would attempt to modify a
given session at the
