Welcome to WebmasterWorld Guest from

Forum Moderators: coopster & jatar k

Sessions: PHP or Apache?

2:56 pm on Apr 4, 2012 (gmt 0)

5+ Year Member

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)

WebmasterWorld Senior Member eelixduppy is a WebmasterWorld Top Contributor of All Time 5+ Year Member

Firstly, it is important to realize there are sessions and cookies and they both work differently.

Cookies are stored on a clients local computer by their web browser. They are key/value data files stored in a specific location. These cookies can be manipulated via JavaScript for example (which occurs on the local machine and through the web browser) or sent back to the web server in the HTTP request. The programming language (PHP in this case) can then fetch/modify these cookies that the web server receives in the request or issue new ones.

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)

5+ Year Member

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)

WebmasterWorld Senior Member eelixduppy is a WebmasterWorld Top Contributor of All Time 5+ Year Member

>> 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)

WebmasterWorld Senior Member rocknbil is a WebmasterWorld Top Contributor of All Time 10+ Year Member

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.

<OT>Today's internet programmers are far too reliant on Javascript, cookies, and other "short cuts" that indeed make our job easier. Far too few of them consider two questions: 1) what if Javascript is disabled or otherwise fails? 2) What if cookies are disabled or otherwise fails? Enter the term "graceful degradation," the fall back to other means if these two tools fail to do what we ask (the inverse of which is "progressive enhancement.") This means you have to add more programming, some of it a significant amount, most of it only used 5-10% of the time or never used at all, to insure your application is truly a solid and reliable program. Not doing so can lose leads and sales, most of which get swept under the rug in the interest of maintaining budgets or outright laziness. Additionally, NOT doing so can lead to other holes in your logic, security issues that can cause the whole thing to implode on you. There is really no reason to NOT insure your programs work well with or without Javascript or cookies. I absolutely CRINGE and often go ballistic when someone starts an argument with "Everyone uses Javascript and cookies these days. If they don't have Javascript or cookies enabled, we don't need their business. . . . "</OT>

Featured Threads

My Threads

Hot Threads This Week

Hot Threads This Month