How does a User maintain State with CGI?

Oh, those were the days, weren't they? The wild west of the web. Back in 2000, as a Perl-CGI programmer, maintaining state with CGI was a bit of an art, since HTTP, the backbone of internet communication, is stateless by nature. But hey, where there's a will, there's a way! At its core, maintaining state is all about keeping track of user interactions across multiple requests. It's like remembering what you talked about with a friend over a series of phone calls. In Perl-CGI, you had a few tricks up your sleeve to handle this:

1. Cookies: These are like little breadcrumbs that a user's browser keeps and sends back with every request. In Perl, you could use the CGI.pm module to easily set and retrieve cookies. Once set, a cookie might store a user's ID or preferences, and you could read that cookie on subsequent requests to remember who's who.
2. Hidden Form Fields: Another popular technique was to use hidden fields in HTML forms. Say a user was moving through a multi-page form. You could 'remember' the data from previous pages by storing it in hidden fields, which get submitted along with the rest of the form. The user doesn't see these fields, but the server gets the data.
3. URL Rewriting: In this approach, you could add session information directly into the URL of links in your HTML pages. When a user clicks a link, the server receives this information and can maintain the user's state. One thing to be aware of is that this can clutter up your URLs, and if a user bookmarks a URL, they might end up bookmarking their session information too!
4. Server-Side Sessions: The most secure and reliable way to maintain state was with server-side sessions. This method typically involves giving the client a unique session ID, often via a cookie. This ID would be like a key to a box on the server where you could store all kinds of information about that session. Because the data is kept server-side, it's secure and not directly reliant on the client's browser.

As you can see, maintaining state in Perl-CGI during the dot-com era required a blend of creativity and technical acumen. But hey, that's what made it fun, right?

One way to achieve state with a CGI solution is for the first CGI program to write out HTML that includes another form.
Some of the information the CGI program knows, like the user name from the first form, is written out as hidden form fields in the HTML. The ACTION parameter on this second form is another CGI program, and this second CGI program will have all the information from the first form as well as from the second. This technique works, but it is difficult to write, and harder still to maintain when your forms change.

The Hypertext Transfer Protocol (HTTP) is the network protocol that web servers and client browsers use to communicate with each other. HTTP is the language of the web. HTTP connections are initiated by a client browser that sends an HTTP request. The web server then responds with an HTTP response and closes the connection. If the same client requests another resource from the server, it must open another HTTP connection to the server. The server always closes the connection as soon as it sends the response, whether or not the browser user needs some other resource from the server.
Because the web server always disconnects after it responds to a request, the web server does not know whether a request comes from a user who has just requested the first page or from a user who has requested nine other pages before. As such, HTTP is said to be stateless.
The consequences of an application being stateless are as follows. Consider, for example, a user who is shopping at an online store. As usual, the process starts with the user searching for a product. If the product is found, the user then enters the quantity of that product into the shopping cart form and submits it to the server. If the user is not yet checking out, he or she still wants to buy something else. So she searches the catalog again for the second product. The first product order has now been lost, however, because the previous connection was closed and the web server does not remember anything about the previous connection.
The good news is that web programmers can work around this, and this module discusses techniques for that. The solution is called user session management where the web server is forced to associate HTTP requests and client browsers.