Milo Hyson wrote:
> I just ran into a problem with my PerlFixupHandler/PerlCleanupHandler based
> session manager (discussed earlier). It seems there's no guarantee that the
> cleanup handler will fire before the browser receives the response from the
> content handler.
um, yes there is. the content generation phase is guaranteed to be complete
before per-request cleanups run _for a single request_. that's what the request
cycle is all about.
> There's a niche case where a redirect will get to the
> browser and back to Apache before the cleanup handler has a chance to write
> the session to the database.
that's something different :) due to some long running cleanups, I can see how
a redirected response (which is a completely new request) could be initiated
before cleanups are complete, since cleanups are run after the browser is
released...
> If the redirected request needs that session
> data, there's a small chance it won't be there yet.
have you seen this? I don't recall this ever coming up before (which doesn't
mean it can't happen :)
>
> Is there any way I can guarantee (short of hacking Apache::Registry) that my
> post-content code will run before the browser gets a response?
don't confuse the issue - a redirect involves _two_ requests to the browser, not
one.
> From where I
> sit, the hack job looks like the best option right now.
perhaps your post-content code in a PerlLogHandler instead of a
PerlCleanupHandler might help if you are running into problems. the browser
isn't released from the current connection until logging is complete, so there
wouldn't be the chance that a redirect would be processed before the session is
created.
--Geoff
>
>
