Gerald Richter wrote:
The problem seems directly attributable to a 500
configuration error
occuring with a request that was using the session. These
configuration errors were occuring because of an error in our code
which was causing Storable to fail. It seems like the next
>
> > The problem seems directly attributable to a 500
> configuration error
> > occuring with a request that was using the session. These
> > configuration errors were occuring because of an error in our code
> > which was causing Storable to fail. It seems like the next
> connection
> >
> The problem seems directly attributable to a 500
> configuration error occuring with a request that was using
> the session. These configuration errors were occuring
> because of an error in our code which was causing Storable to
> fail. It seems like the next connection to a process that
Gerald Richter wrote:
Ok - I've done that. The SES: message always comes from the
parent process so it is not always easy to match the SESSION
data to the child process that is actually performing the request.
The question is, what are you seeing in case of the problem you have. Could
>
> Ok - I've done that. The SES: message always comes from the
> parent process so it is not always easy to match the SESSION
> data to the child process that is actually performing the request.
>
The question is, what are you seeing in case of the problem you have. Could
you quote the SES:
Ok - I've done that. The SES: message always comes from the parent
process so it is not always easy to match the SESSION data to the child
process that is actually performing the request.
I am wondering if my problems may be caused by using the stock threaded
perl even though we are using the old
nal Message-
> From: ___cliff rayman___ [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, September 14, 2005 6:56 AM
> To: embperl@perl.apache.org
> Subject: Session Problems Due to Apache Calling Back Into Itself
>
> It seems that when a REDIRECT is requested, apache/mod_perl
&
oops - editing below
___cliff rayman___ wrote:
It seems that when a REDIRECT is requested, apache/mod_perl chooses to
call back into itself, or resuse the same connection. In any case,
when certain redirects occur, the session is not written and the next
connection to use the process now has
It seems that when a REDIRECT is requested, apache/mod_perl chooses to
call back into itself, or resuse the same connection. In any case, when
certain redirects occur, the session is not written and the next
connection to use the process now has the same session id and session
data. It is not y
It seems that when a REDIRECT is requested, apache/mod_perl chooses to
call back into itself, or resuse the same connection. In any case, when
certain redirects occur, the session is not written and the next
connection to use the process now has the same session id and session
data. It is not y
10 matches
Mail list logo
