cookies-sessions-persistence-wp.pdf | Http Cookie | Hypertext Transfer Protocol

Please download to get full document.

View again

of 7
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Information Report
Category:

Documents

Published:

Views: 4 | Pages: 7

Extension: PDF | Download: 0

Share
Related documents
Description
F5 White Paper Cookies, Sessions, and Persistence Cookies and sessions are the most useful hack invented, allowing HTTP to become stateful and applications to work on the web. But it is persistence that ties the two together and makes the web what it is today. by Lori MacVittie Technical Marketing Manager, Application Services White Paper Cookies, Sessions, and Persistence Contents Introduction Sessions Transforming the Stateless into Stateful 3 3 3 5 5 6 6 7 Cookies The Trail of Crumbs
Transcript
  Cookies, Sessions, and Persistence Cookies and sessions are the most useful hack invented, allowing HTTP to become stateful and applications to work on the web. But it is persistence that ties the two together and makes the web what it is today. by Lori MacVittie Technical Marketing Manager, Application Services F5 White Paper  2White Paper Cookies, Sessions, and Persistence Contents Introduction 3  Sessions 3 Transforming the Stateless into Stateful 3 Cookies 5 The Trail of Crumbs Leads Home 5 Persistence 6 The Tie that Binds 6 Conclusion 7  3White Paper Cookies, Sessions, and Persistence Introduction HTTP (HyperText Transfer Protocol) was designed to support a stateless, request-response model of transferring data from a server to a client. Its first version, 1.0, supported a purely 1:1 request to connection ratio (that is, one request-response pair was supported per connection). Its second version, 1.1, expanded that ratio to be N:1—that is, many requests per connection. This was done in order to address the growing complexity of web pages, including of the many objects and elements that need to be transferred from the server to the client. Somewhere along the line, HTTP became more than just a simple mechanism for transferring text and images from a server to a client; it became a platform for applications. The ubiquity of the browser, cross-platform nature, and ease with which applications could be deployed without the heavy cost of supporting multiple operating systems and environments was certainly appealing. Unfortunately, HTTP was not designed to be an application transport protocol. It was designed to transfer documents. Despite the fact that both documents and application protocols are generally text-based, the resemblance ends there. Applications require some way to maintain their state, while documents do not. Applications are built on logical flows and processes, both of which require that the application know where the user is during this time, and that requires state. HTTP is stateless, so it seems obvious that HTTP would not be appropriate for delivering applications. But it has become the de facto application transport protocol of the web. In what is certainly one of the most widely accepted, useful hacks in technical history, HTTP was given the means by which state could be tracked throughout the use of an application. That “hack” is where sessions and cookies come into play. Sessions Transforming the Stateless into the Stateful Sessions are the way in which web and application servers maintain state. These simple chunks of memory are associated with every TCP connection made to a web or application server, and serve as in-memory storage for information in HTTP-based applications. 3  4White Paper Cookies, Sessions, and Persistence When a user connects to a server for the first time, a corresponding session is created and associated with the connection. Developers then use that session as a place to store bits of application-relevant data. This data can range from important information such as a customer ID to less consequential data such as how you like to see the front page of the site displayed. The best example of the usefulness of sessions is shopping carts, because nearly all of us have shopped online at one time or another. Items in a shopping cart remain over the course of a “session” because every item in your shopping cart is represented in some way in the session on the server. Another good example is wizard-style product configuration or customization applications. These “mini” applications enable you to browse a set of options and select them; at the end, you are usually shocked by the estimated cost of all the bells and whistles you added. As you click through each “screen of options,” the other options you chose are stored in the session so they can be easily retrieved, added, or deleted. The problem is that sessions are tied to connections, and also to connections left idle for too long time out. Also, the definition of “too long” for connections is quite a bit different than when it is applied to sessions. The default configuration for Apache, for example, is to close a connection once it has been idle—that is, no more requests have been made—for 15 seconds. Conversely, a session in Apache, by default, will remain in memory for 300 seconds, or 5 minutes. Obviously the two are at odds with one another, because once the connection times out, what good is the session if it’s associated with the connection? You might think you could simply increase the connection time-out value to match the session and address this disparity. Increasing the time-out means that you’re potentially going to expend memory to maintain a connection that may or may not be used. This can decrease the total concurrent user capacity of your server as well as ultimately impede its performance. And you certainly don’t want to decrease the session timeout to match the connection time out, because most people take more than five minutes to shop around or customize their new toy. Thus, what you end up with is sessions that remain as memory on the server even after its associated connection has been terminated due to inactivity, chewing up valuable resources and potentially angering users for whom your application just doesn’t work. Luckily, this problem is solved through the use of cookies.
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks