Questions #1

How can the client know if the request was successful or not?
Check response status. Answers are divided by senior level. We have five groups with the following semantics:

• 
  1xx: Very rarely used. This group has only one status 100 Continue.
  
• 
  2xx: Request was successful (data received or created)
  
• 
  3xx: redirect to another resource
  
• 
  4xx: error caused by the user (no such page, no access rights)
  
• 
  5xx: server error (error in code, network, configuration)
  

What needs to be sent to the browser to redirect to another page?
The minimum response must have a status of 301 or 302. The Location header specifies the address of the resource to navigate to.
You can place HTML in the response body with a link to the new resource. Then users of older browsers will be able to navigate manually.
How to manage caching in HTTP?
There are several ways to cache data at the protocol level.

• 
  The Cache and Cache-Control headers regulate several cache criteria at once: lifetime, update policy, proxy server behavior, data type (public, private).
  
• 
  The Last-Modified and If-Modified-Since headers specify caching based on the date the document was updated.
  
• 
  The Etag header caches the document by its unique hash.
  

How are files cached at the protocol level?
When Nginx serves a static file, it adds an Etag header, the MD5 hash of the file. The client remembers this hash. The next time the file is requested, the client sends the hash. The server checks the client's hash for this file. If the hash does not match (the file has been updated), the server responds with a 200 code and uploads the current file with the new hash. If the hashes are equal, the server responds with a 304 Not Modified code with an empty body. In this case, the browser substitutes a local copy of the file.