takeaway

This article mainly combs the relationship between HTTP, Session and Cookie, and you can clearly understand the answers to the following questions through this article

  1. What exactly does HTTP Stateless mean
  2. What is Session and how does it relate to HTTP
  3. The relationship between Session and Cookie
  4. Knowledge of cookies

Stateless HTTP

HTTP hypertext transfer protocol is mainly designed for communication between Web clients and Web servers, meaning that the client and server can exchange data according to the form specified by the protocol.

The specified format is the format of the packet and is not expanded here.

In simple terms, the client sends an HTTP request to a specified server, and the server returns the corresponding data when it receives the request. Modern Web applications are based on this, assembling multiple HTTP requests.

HTTP stateless means that there is no requirement in the protocol for request identification.

For the server, multiple requests from the same client are completely independent.

There is no sharing of data between these requests. The current request has no statistical relationship to previous or subsequent requests. The server treats each request as a new one, and does not associate the receipt of a request with other requests in some way.

The server is like a fish with no memory, processing requests as they come in without any recognition of the identity of the request.

When web sites were primarily static pages, the stateless HTTP protocol was just fine. But as web sites evolve, more and more complex interactions take place, requiring multiple requests to collaborate to build site data, and statelessness becomes a mess.

Imagine a stateless situation where you go shopping on a shopping website, and when you check out, you send a request, and the server gets confused about who you are, what you choose, and what you pay with.

That’s where the Session comes in.

Make HTTP a stateful Session

What is Session?

The meaning of Session is not exact. The word literally means Session, which is too abstract. There is a relatively appropriate description of Session in RFC2109

This document describes a way to create stateful sessions with HTTP requests and responses. Currently, HTTP servers respond to each client request without relating that request to previous or subsequent requests; the technique allows clients and servers that wish to exchange state information to place HTTP requests and responses within a larger context, which we term a “session”.

A Session is essentially a large context in which clients and servers can interact statically.

Session is a solution that allows clients and servers to interact statically (data state sharing between multiple requests) over the lifetime of a context (simply a period of time).

Session implementation scheme

Once you understand the purpose of the Session, you can design a scheme to implement it.

We outline here a way for an origin server to send state information to the user agent, and for the user agent to return the state information to the origin server.

One way to create a session is to design a scheme in which the source server sends state information to the client, and the client returns the state information to the source server.

In short, it is to build a state information flow mechanism between the server and the client.

Essentially, a state data is maintained between multiple requests that the server uses to identify the request.

So sessions can be built in one of the following ways

  • Query strings using urls
  • Use the hidden fields of the form form
  • Using IP address
  • Use of cookies

But the first three have problems of one sort or another,

Url query strings are explicitly exposed, requiring complex processing logic as the page moves forward and backward; Form forms hide fields and require additional maintenance costs; IP addresses are insecure and easy to forge. And these methods are separate from the HTTP protocol, a kind of hack.

Therefore, RFC2109 proposes to add a pair of packet headers to the packet header. These headers are the common set-cookie and Cookie

The origin server initiates a session, if it so desires. To initiate a session, the origin server returns an extra response header to the client, Set- Cookie.

A user agent returns a Cookie request header (see below) to the origin server if it chooses to continue a session.

The origin server may ignore it or use it to determine the current state of the session. It may send back to the client a Set-Cookie response header with the same or different information, or it may send no Set-Cookie header at all. The origin server effectively ends a session by sending the client a Set-Cookie header with Max-Age=0.

Servers may return a Set-Cookie response headers with any response. User agents should send Cookie request headers, subject to other rules detailed below, with every request.

An origin server may include multiple Set-Cookie headers in a response. Note that an intervening gateway could fold multiple such headers into a single header.

# response headersSet-Cookie: name=value; max-age=delta-seconds,otherName=value; max-age=delta-seconds Set-Cookie: name3=value; max-age=3600; domain=/# request header
Cookie: name1=value; name2=value
Copy the code

The most common way to build a Session is with cookies.

The packet header is part of the HTTP protocol, which regulates the interaction between the client and server. It can be understood that the client and server parse packets according to the specified protocol.

Build sessions using cookies

With these two fields, as soon as the server sets a set-cookie field in the response header, a piece of text data is passed from the server to the client. After receiving the response, the client parses the response header according to the HTTP specification. After identifying the field, the value of the field is saved locally according to the format. In subsequent requests, Cookie information that meets the criteria is automatically added to the request header and returned to the server. There will be a data state between the server and the client.

Note: the above behavior is designed by the HTTP specification, and the browser (user agent) convention complies with the behavior, requiring no additional work by the developer. So this way can be said to be HTTP protocol implementation, not so hack.

A simple example:

1. User Agent -> Server POST/ACme /login HTTP/1.1 [form data] User identifies self via a form. 2 HTTP/1.1 200 OK set-cookie: Customer="WILE_E_COYOTE"; Version="1"; Path="/ ACme "Cookie reflects user's identity. 3. user Agent -> Server POST/ACme/pickItem HTTP/1.1 Cookie: $Version="1"; Customer="WILE_E_COYOTE"; $Path="/acme" [form data] User selects an item for "shopping basket." 4. Server -> User Agent HTTP/1.1 200 OK Set-Cookie: Part_Number="Rocket_Launcher_0001"; Version="1"; Path="/acme" Shopping basket contains an item. 5. User Agent -> Server POST /acme/shipping HTTP/1.1 Cookie: $Version="1"; Customer="WILE_E_COYOTE"; $Path="/acme"; Part_Number="Rocket_Launcher_0001"; $Path="/acme" [form data] User selects shipping method from form.Copy the code

This is how the Session is implemented using cookies: shared state data is stored on the client in the form of cookies and is transferred between the client and the server.

But this shared state data is stored in cookies, which can cause some problems:

  1. The cookie itself has a size limit, 4KB, which may not be enough for complex applications;
  2. Local cookies are at risk of tampering, creating security issues

Therefore, a new scheme emerges on this basis: when the server sets set-cookie, it does not transfer the shared state data as the value of Cookie to the client. Instead, it creates a space for storage on the server and then returns the storage address as the value of Cookie to the client. So the client and server between the flow is only a piece of address information; This avoids the problem of insufficient cookie space, another convenient server data security is much higher than local, not easy to be tampered with.

Set-cookie: SessionId=XXXX; The name of the SessionId is also a source of confusion about the concept of a session.

The end of the

This is the relationship between HTTP, Session, and Cookie.