|Sessions: PHP or Apache?|
| 2:56 pm on Apr 4, 2012 (gmt 0)|
Mainly a question of curiosity.
Is session control a fundamental part of [insert favorite server here] with [insert favorite language here] as a wrapper, or is it purely part of the scripting module?
I "feel" like it's purely within the scripting module(?), because it seems outside the scope of the server's responsibility to be dealing with cookies and such, and it seems entirely within [PHP]'s scope to do so.
A cursory search, however, revealed that I don't really even know how to ask the question (to google, at least).
| 3:22 pm on Apr 4, 2012 (gmt 0)|
Firstly, it is important to realize there are sessions and cookies and they both work differently.
Sessions are a bit different, and are not stored locally on the clients computer in the same way cookies are. Sessions are stored on the web server side, and are managed by the web server itself. Sessions create a stateful environment in an otherwise stateless protocol (HTTP) by effectively "remembering" a client connected to it from one request to another. Again, PHP has access to these sessions through the web server, as well.
Hope this provides a basic understanding for you.
| 3:39 pm on Apr 4, 2012 (gmt 0)|
Thanks for the reply.
I understand the basics of cookies; I thought that Apache/PHP *used* cookies to track the sessions. If they are sent back and forth with each request/reply, then the stateless server can maintain a "state" (similar to how a "state" can be maintained by using the URL).
What other options are there? Maintaining a file on the server to track the session?
Regardless of how sessions are actually implemented, the actual question is: within what are they implemented? is it Apache or PHP that actually implements sessions (whether it be by cookie, server file, URL, whatever else)?
| 4:09 pm on Apr 4, 2012 (gmt 0)|
>> I thought that Apache/PHP *used* cookies to track the sessions
Often a cookie will be used by the browser to store the session ID. But this doesn't have the be the case.
hmm, it would seem that PHP manages the sessions directly.
When a user first enters the session-based application by making a request to a page that starts a session, PHP generates a session ID and creates a file that stores the session-related variables. PHP sets a cookie to hold the session ID in the response the script generates. The browser then records the cookie and includes it in subsequent requests.
| 4:14 pm on Apr 4, 2012 (gmt 0)|
The direct answer, since you're in the PHP forum, and in the context of PHP sessions - PHP. :-) But PHP sessions are just one implementation of maintaining state.
|Sessions are stored on the web server side, and are managed by the web server itself. |
But - it is important to note that the "connection" between the server and the client (browser) is still maintained via the PHPSESSID cookie. However, if a cookie can't be set, PHP has mechanisms internal to the language itself to maintain state via query strings.
|the actual question is: within what are they implemented? |
The above may begin to lead you to an answer. The sessions and their state are maintained by server software, in one of many ways.
There is only one way to retain a "connection" between the browser and the server, and this is with a cookie - but there are ways to fall back and maintain state.
With Apache's Authorization and Access Control [httpd.apache.org], the authentication is done with a module in Apache - but it's still server software, and it still sets a cookie to "know" which client is connected to which session. This is the one that you'll see in many implementations of PHPmyAdmin under WHM or Cpanel (for example.) The pop up login box is a bit different than most browser login boxes.
With PHP, the authorization is done within the programming language, but there are still session files created on the server that correspond to the value in the PHPSESSID cookie. If a cookie can't be set, you should implement passing the session id [php.net] as a query string parameter.
In Perl, there is no inherent session mechanisms in the language, we have to do all this stuff manually (although there are modules to help.) We have to devise our own mechanism of storing a session (generally database entries, but can be files,) create our own session id values, set and get our own cookies. Although it's more work, I wouldn't trade it for anything; this leads to a greater understanding of what's happening in PHP, and when you code it yourself, you KNOW what's happening, it's not a black box that you just hope it works. :-)
.asp, .cfm, and other languages all have the same mechanisms, but they all rely on the same basic tools: store something on the server, set a cookie to connect the client with server, and have a fallback mechanism in place if it fails.