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>
