I am an event. I only happen if you don't attend. If you show up, I'm canceled. Sometimes cookies are served. I produce no output, everything that happens in me is hidden, and httpwebwitch needs to debug me today. Who am I?
Sounds like a virus!
What is it that you're trying to see? A process? Server side/Client side? I guess as this is something that is only present IF you have actioned by pressing a button, or mousing over something.. Other than that - no idea - though very intrigued. Good luck on this endeavour...
Sounds like some form of HTTP timeout.
Cron was my guess too
ahh, no sorry you're all wrong. on Friday I was debugging the garbage collection routine that prompts the expiry of a session.
>> I only happen if you don't attend. If you show up, I'm canceled.
if you refresh a page that's uses the session, the session doesn't expire. Looking at the contents of $_SESSION changes the session. It's rather schroedingeresque.
>> Sometimes cookies are served.
PHP's default session behaviour is to send a cookie header in the response
>> I produce no output, everything that happens in me is hidden
It's not the result of a normal request/response process prompted by a browser, so there's no convenient output, thus nothing that you can echo out to a browser to see if the process worked.
In this situation, most of your debugging methods won't work. Tricky stuff, because it happens only if the expiry lapses, and any hit to the session will extend it. To expire the session, you need to knock back the expiry on it (or else you're stuck waiting until it expires), then hit the server to trigger GC, but Not in a way that accesses your session (because that will extend the expiry again)
Overriding the default session behaviour is a finicky business, but there are situations when you need to get your hands dirty in it. For instance, when developing a server-side API that requires authentication, you'll likely want to store your sessions in a mysql database, not in /tmp files. This gives your app immediate access to the sessions, so your app can establish authentication for requests. It's also useful to override the session handler if your app accepts the session token as something other than a cookie, which is quite common if you're designing an app for something other than a web browser.
It's done using session_set_save_handler() [php.net]
So how do you debug a process that has no output, and happens outside the context of a browser-origin request?
one easy way: liberal use of error_log() [us.php.net]
error_log() sends a string into the error log. And viewing the real-time contents of your error log is quite simple. Go into an SSH terminal and navigate to your error log - it's often in /var/log/httpd/ - and do this command:
tail -f error_log
the "tail -f" is a great trick to know. It flows the data from error_log - any new appended lines - straight onto the screen. When that's running, you can trigger your session expiry (if you know how) and you'll see the output of error_log() appear in the terminal window.
If you don't want to use error_log, you can output to a file using file_put_contents() [php.net], with "FILE_APPEND" as the third argument. That accomplishes the same thing.
So why'd anyone need to hook into the garbage collection routine?
In my case there are connections to other servers that are established when a session is created, that needed to be forcibly closed when a session expires. So, in the "destroy" and "gc" parts of the session handler, I needed the handler to do a little extra work. This can only be done if you've overridden the default session handler with your own.
It's powerful stuff.
On the same topic how to purge your Apache error log:
/etc/httpd/logs # mostly resides in there
-bash-3.2# > error_log <----- Use to empty log
that's nifty henry0, I usually do this:
#> echo "" > error_log
which is basically taking an empty string and writing that as the content of error_log.
your way is more succinct