How to describe the interaction between the web server and the web client?

Question

Currently, I have the following understanding (which, I believe, is incomplete and probably even incorrect).

The web server receives a request from the client. Requests come to a certain "path" ("address", "URL") and have a certain type (GET, POST and, possibly, something else?). GET and POST requests can also contain variables and their values ​​(which can be at least a "dictionary" or an "associated array"). GET request parameters are set in the address bar (for example: http://example.com?x=1&y=2 ), and POST request parameters are set by the client (user) via web forms (in other words, the user fills out the form and clicks "Submit" ").

In addition to this, we have a so-called SESSION (also known as COOKIES). This works as follows. When a web server receives a request (such as GET or POST), it (the web server) checks the values ​​of the sent parameters and is based on the fact that it generates and sends back to the client’s HTML code, which is displayed in the browser (and visible to the user). In addition to this, web servers send some parameters (which again can be thought of as a "dictionary" or "associative arrays"). These parameters are stored by the browser somewhere on the client side, and when the client sends a new request, it also sends back the session parameters received earlier from the web server. Actually the server says: you will get it from me, remember it, and the next time you talk to me, give it back (so I can recognize you).

So, I do not know if the client can see what exactly is in the session (what parameters are and what values ​​they have), and if the client can change the values ​​of these parameters (or add or remove parameters). But what a user can do, he can decide not to accept a cookie (or session).

There is also something called "local storage" (available in HTML5). It works as follows. Like SESSION, this is some information sent by the web server to the client, as well as stored (stored) by the client (if the client wants). Unlike a session, it is not sent back to the client on the server. Instead, client-side JavaScripts (sent by web servers as part of the HTML code) can access information from local storage.

What I'm still missing is how AJAX works. This is similar to the fact that clicking something in the browser, users send (via the browser) a request to the web server and wait for a response. The browser then receives a response and uses it to change (but not replace) the page that the user observes. I am missing how the browser knows how to use the response from the web server. It is written in HTML code (something like: if you click it, send this request to the web server and use its response (the provided content) to change this part of the page).

Answer 1

I am going to answer your questions about AJAX and LocalStorage, also at a very high level, since your definition strikes me as such at a high level.

AJAX stands for A synchronous J avaScript a nd X ML. Your browser uses an object called XMLHTTPRequest to establish an HTTP request with a remote resource.

The client, the client, does not pay attention to what is included in it. All he has to do is provide the request with URLs, in a way and, if necessary, the payload of the request. The payload is most often a parameter or group of parameters accepted by the remote server.

The request object has several methods and properties, and also has methods for processing the response.

What I am missing is how the browser knows how to use the response from the web server.

You just tell what to do with the answer. As mentioned above, the request object can also be informed about what to do with the response. He will listen to the answer, and when this happens, you tell the client what to do with him.

Is this (answer) written in HTML?

Not. The answer is written regardless of what the server was serving. Most often it is Unicode. A common way to service a response is with a JSON (Object Object Notation).

Whatever happens afterwards is purely a matter of implementation.

Localstorage

There is also something called "local storage" (it is available in HTML5). It works as follows. As a SESSION, this is some information sent through a web server to a client, and the client is also stored (saved) (if the client wants)

Not exactly. Local storage is a truly new feature introduced with HTML5. This is a new way to store data in the client and is unique to the source . By origin, we refer to a unique protocol and domain.

The lifetime of the local storage object on the client (again, for its unique origin) is entirely up to the user. However, of course, the client application can manipulate the data and decide what is inside the local storage object. You are right that it is stored and can be used in the client using JavaScript.

Example. Some web tracking tools want some kind of backup plan if the server that collects user data is unavailable for some reason. A web tracker, sometimes presented as a plugin for JavaScript, can first record any event to the local storage and release it only when the remote server confirms that it received the event successfully, even if the user closed the browser.

Answer 2

I have summarized your main questions along with a short answer right below them:

one:

Can the client see what exactly is in the session?

A: No. The client only knows the "SessionID", which is metadata (all other session data is stored only on the server, and the client cannot see or change it). SessionID is used by the server only to identify the client and map the application process to it in the previous state. HTTP is a stateless protocol, and this classic method allows you to use it as a state. There are very rare cases when the full session data is stored on the client side (but in such cases, the server must also encrypt the session data so that the client cannot see / change it). On the other hand, there are web clients that do not have the ability to store cookies at all, or they have features that prevent the storage of cookies (for example, the ability of a user to reject cookies from domains). In such cases, the workaround is to enter the SessionID in the URL parameters using HTTP redirects.

2:

What is the difference between HTML5 LocalStorage and Session?

LocalStorage can be considered as the client’s own session data, or rather, a local data store in which the client can save / save data. Only the client (mainly from javascript) can access and modify the data. Think of it as persistent storage supported by javascript (with an advantage over cookies that you can control which data, structure and format you want to keep). It is also more beneficial than storing data in cookies, which have their own restrictions, such as the size and structure of the data.

3:

How does AJAX work?

In very simple words, AJAX means loading data on demand over an already loaded (HTML) page. A typical HTTP request will load all the page data, while an ajax request will load and update only part of the (already loaded) page. The AJAX request is very similar to the standard HTTP request. Ajax requests are controlled by javascript code, and this can enrich the interaction with the page. You can request specific data segments and refresh sections of the page.

Now, if we remember the old days when any interaction with the website (for example, logging in to the system, switching to other pages, etc.) required a full page reload? Then there was a lot of unnecessary traffic to perform any simple action. This, in turn, affected the responsiveness of the site, user experience, network traffic, etc. This was due to the inability of browsers (at that time) [a.] To execute a parallel HTTP request to the server and [b] render a partial view of the HTML. Modern browsers come with these two functions that allow you to use AJAX technology, that is, call asynchronous (parallel) HTTP requests (Ajax HTTP requests), and also provide a mechanism for changing the DOM on the fly through javascript (real-time manipulation of the HTML object model) .

Please let me know if you need more information on these topics, or if anything else I can help you.

For a deeper understanding, I also recommend this article with a good web search history , as it explains how it all started from the moment HTML was created, and what was the purpose (to identify [at the time] rich documents) and then how HTTP was originally created and what problem was solved (at that time - "migrate" static HTML). This explains why this is a stateless protocol. Later, as HTML and WEB evolved, other needs arose (for example, the need to interact with the end user), and then the Cookie engine expanded the protocol to allow communication with the client server with the state using session cookies. Then came Ajax. Currently, cookies also have their own limitations, and we have LocalStorage. Did I also mention WebSockets?

Answer 3

First of all, it's just an explanation to clarify your mind. To explain this in more detail, we need to write a book. That was said, I will go step by step.

---

Request

A request is a client requesting / sending data to a server.
This request contains the following parts:

• URL (protocol + hostname / IP + path)
• Method (GET, POST, PUT, DELETE, PATCH, etc.)
• Some parameters are optional (the method for sending them depends on the method)
• Some headers (metadata sent to the server)
• Some additional cookies
• optional SESSION identifier

Some explanations about this:

• Cookies can be set by the client or server, but they are always stored in the client’s browser. Therefore, the browser can decide whether to accept or not, or delete or modify them.
• The session is stored on the server. The server sends a session identifier to the client to be able to reassign it in any future request.
• Session and cookies are two different things . One of them is server-side, and the other is client-side.

---

Ajax

I omit the meaning of the abbreviation, as you can easily use it.

The great thing about AJAX is the very first A, which stands for asynchronous , which means that the JS engine (in this case, the built-in browser) will not block until the response returns.

To understand how AJAX works, you should know that it is very similar to a general request, but with the difference that it can be launched without reloading the web page.

The content of the answer is what you want. From some HTML to a JSON string. Even plain text.

The way the answer is processed depends on the implementation and programming. As an example, you can simply alert() to get the result of an AJAX call or add it to the DOM element.

---

Local storage

This has nothing to do.

Local storage is simply the disk space offered by the browser, so you can save data in a browser that is saved even if the page or browser is closed.

Example

Chrome offers a javascript API for managing local storage. This is the client side, and you can programmatically access this repository and do CRUD operations. It is just like a non-SQL relational database in a browser.

Answer 4

1. Establish a connection

The most common way that web servers and clients interact is through a connection that follows a Transmission Control Protocol or TCP . In principle, when using TCP, a connection is established between client and server machines through a series of back-and-forth checks. Once the connection is established and open, data can be sent between the client and server. This connection can also be called Session .

There is also UDP or the User Datagram Protocol , which has a slightly different way of communicating and comes with its own set of pros and cons. I believe that recently some browsers may have started using a combination of the two to get the best results.

There is still a ton to say, but if you are not going to write a browser (or become a hacker), this should not depend too much on you.

2. Sending packages

Once the client-server connection is established, data packets can be sent between them. TCP packets contain various bits of information that aid in the exchange of data between two ports. For web programmers, the most important part of the package will be the section that includes the HTTP request .

HTTP , Hypertext Transfer Protocol is another protocol that describes what the makeup / format of these client-server messages should look like.

The simplest example of the corresponding part of the packet sent by the client to the server is as follows:

 GET /index.html HTTP/1.1 Host: www.example.com 

The first line here is called the Response line . GET describes the method to be used (others include POST, HEAD, PUT, DELETE, etc.) /index.html describes the requested resource. Finally, HTTP/1.11 describes the protocol used.

The second line in this case is the only header field in the request, in which case it is the HOST field, which is a kind of alias for the server IP address given by DNS.

[Since you mentioned this, the difference between a GET request and a POST request is simply that the parameters in the GET request (for example: form data) are included as part of the Response line , while the parameters in the POST request will be included as part of the Message Body (see below).]

3. Receive packets

Depending on the request sent to the server, the server will scratch its head, think about what you asked, and respond accordingly (otherwise, how do you program it).

Here is an example of sending a response packet from the server:

 HTTP/1.1 200 OK Content-Type: text/html; charset=UTF-8 ... <html> <head> <title>A response from a server</title> </head> <body> <h1>Hello World!</h1> </body> </html> 

The first line here is the Status Line , which includes a numerical code along with a brief text description. 200 OK obviously means success. For example, most people are also familiar with 404 Not Found .

The second line is the first of the Response Header Fields . Other fields added include date , Content-Length and other useful metadata.

Below the headers and the desired blank line, finally, the (optionally) Message Body . Of course, this is usually the most exciting part of the answer, as it will contain things like HTML for our browsers, to display JSON data for us, or almost everything you can encode in the return .

4. AJAX, asynchronous JavaScript and XML

Based on all this, AJAX is easy enough to understand. In fact, packets sent and received may look identical to non-ajax requests.

The only difference is how and when the browser decides to send the request packet. Typically, when a page is refreshed, the browser sends a request to the server. However, when issuing an AJAX request, the programmer simply tells the browser to send the packet to the NOW server, and not to refresh the page.

However, given the nature of AJAX requests, typically a Message Body will not contain the entire HTML document, but will request smaller, more specific bits of data, such as a request from a database.

Then your JavaScript, which calls Ajax, can also act based on the response. Any JavaScript method is available, since an Ajax call is another JavaScript function. This way you can do something like innerHTML to add / replace content on your page with the HTML returned by the Ajax call. Alternatively, you can also do something like calling Ajax, which just needs to return True or False, and then you can call some JavaScript function with an if else statement. As you can hope, Ajax has nothing to do with HTML for a single word, it's just a JavaScript function that makes a request from the server and returns a response, whatever it may be.

5. Cookies

The HTTP protocol is an example of an idle protocol . This basically means that each pair of Request and Response (as we described) is processed independently of other requests and responses. Thus, the server does not need to track all the thousands of users who currently require attention. Instead, it can simply respond to each request individually.

However, sometimes we want the server to remember us. How would it be unpleasant if every time I inspected my Gmail I had to register again because the server forgot about me?

To solve this problem, the server can send cookies , which will be stored on the client machine. The server can send a response that tells the client that the cookie has been saved and what it should contain. The client browser is responsible for storing these cookies on the client system, so the location of these cookies will depend on your browser and OS. It is important to understand that these are just small files stored on the client machine that are actually readable and writable by anyone who knows how to find and understand them. As you can imagine, this poses several different potential security threats. , cookie, . ( cookie, , , , , , cookie.

, , Cookie Request Header Fields , : ", , , , " " , , ", .

6.

HTML5 Cookies. cookie, . .

, .

7.

, . -, Google.