Cookies are typically short key/value parts supported by the HTTP protocol. Their importance is in the fact that the server can send them to clients, and read and modify their value. In addition, cookies have their expiry time, which can be set, also by the server, to any intended value. Whether Interchange will try to land session cookies in clients' browsers is determined by the Cookies directive, and their default expiry time is set by SaveExpire.

Clients can control whether they reject or accept cookies from all or some sites, and can enforce their expiry time.

Web page requests arriving from users are "anonymous" and basically unrelated to each other even if they are coming from the same user. This is because the HTTP protocol is "stateless" and server can't map requests to specific clients based on just the IP addresses it sees. Therefore, cookies are a crucial mechanism for preserving state information in programs with web-based interfaces. By reading the session ID value (stored in a cookie on client's computer), the server can now recognize associate users with their ongoing, active sessions.

Interchange and its non-dependence on client cookies

Many web-based solutions require that the clients accept storage and retrieval of cookies. When cookies are not enabled on client side, the usage of the site is limited, or clients are even denied access completely. Interchange, on the other side, does not require client support for cookies. If the storage of cookies is denied or unsupported by the client, Interchange appends session information in generated URLs and uses them to continue keeping track of user sessions. (An example session ID "embedded" in an URL looks like ?id=YjiSdrek). Session IDs embedded in URLs should theoretically be equivalent to cookies, and they almost are. The drawback is namely the fact that once you visit a non-Interchange page, you lose the id= argument from the URL (because Interchange isn't there to insert it appropriately). The end result is the users will lose their session information when they return back to Interchange pages, unless they copied the session ID information and put it back in the URL manually (which is a bit too much to expect from random visitors). In practice, this isn't a problem when you're not sending users out of Interchange space, and when you build the site with this fact in mind.

When a new client accesses its first page from the Interchange catalog, Interchange sends it both the requested page and a cookie. At that point, Interchange can't know whether the client accepted the cookie or not — it has to wait for the client to initiate the second page request. (Historically, many application servers always bounced the first request to provoke the second access from the client and to check for cookie support. Interchange does not do it.)

If the user sends a cookie back to Interchange (which, as you see, can happen no sooner than on second request), Interchange knows the client is cookie-capable and there's no need to embed session ID in URLs.

One possibly confusing thing is that, by default, Interchange always appends session ID information to the URLs it generates — even if clients have no cookie-handing problems. If the scratch variable mv_no_session_id is set in the user's session, the session ID will not be appended to the URL. Furthermore, on a somewhat related note, if the scratch value mv_no_count is set, then the page count (mv_pc=random) will not be appended either. "PC" is a page counter that serves to prevent client browsers from caching pages.