About the use of HTTP cache validation last modified and Etag

About resource validation

• If Cache-Control Set up no-cache after , Every time the browser initiates a pair of settings Cache-Control When requesting resources
• Go to the server for a resource verification , Verify if the resource can be used , Then the local cache will be read

Cache validation process

• 1 ) The browser creates a request , The first place the request arrives is in the local cache , Of course, it is based on Cache-Control Head case
  • If you look in the local cache , If you find , Then directly return to the browser rendering page
  • In this case , It will not be transmitted through any network , That is to say from memory cache The effect of
• 2 ) If not found , Will go to the network to request , In a network request , If you pass through a proxy server ( Proxy cache )
  • First, you will find the relevant cache information on the proxy server , If found, it will be returned to the client
  • After local cache , Then return to the browser to render the page
• 3 ) If the cache information is not found on the proxy server , Then go directly to the source server to find resources
  • After getting the new content , Then level by level down to return and secondary cache
  • Finally, it is returned to the browser for page rendering

How to perform cache verification

• stay HTTP There are mainly two verified HTTP head ：Last-Modified, Etag
• Last-Modified: Last modified
  • That is to say, set the last modification time for this resource
  • Mainly with If-Modified-Since or If-Unmodified-Since Use
  • If a resource is requested , The return information includes Last-Modified Field , It specifies a time
  • The next time the browser makes a request , Will take this Last-Modified Field information
  • adopt If-Modified-Since or If-Unmodified-Since
  • Usually, the implementation of browser will choose If-Modified-Since
  • Bring it to the server in the request , The server can read If-Modified-Since Compare the last modification time of this resource
  • If the time is the same , Then it means that the resource has not been modified , The server can tell the browser that the cached information can be used directly
  • This is to compare the last modification time to verify whether the resource can use the cache , Whether to update the process
• Etag: Is a more rigorous verification
  • Its verification is mainly through data signature ： Generate a unique signature for the resource content
  • If the resource data is modified , The signature will become a new , Any modification will cause the two signatures to be different
  • The most typical method is to hash the content of resources , Get a unique value as a signature to mark this resource
  • The next time the browser makes a request , I'll take it with me If-Match or If-Non-Match Field , Its value is returned by the server Etag value
  • Compare resource signatures , Determine whether to use cache

Program example

• test.html

  <script src="/script.js"></script>
  

• server.js

  const http = require('http');
  const fs = require('fs');
  
  http.createServer((req, res) => {
        
      console.log('req come: ', req.url);
      if(req.url === '/') {
        
          const html = fs.readFileSync('test.html', 'utf8');
          //  The default is the following writeHead Set up , It's ok if you don't write 
          res.writeHead(200, {
        
              'Content-Type': 'text/html'
          });
          res.end(html);
      }
      if(req.url === '/script.js') {
        
          res.writeHead(200, {
        
              'Content-Type': 'text/javascript',
              'Cache-Control': 'max-age=2000000000, no-cache', //  Set a long value and no-cache
              'Last-Modified': '12345',
              'Etag': '666'
          });
          res.end("alert('script loaded')");
      }
  }).listen(8000, () => {
        
      console.log('server is running on port 8000');
  });
  

• Start the program ：$ node server.js

• visit ：http://localhost:8000/

• Check the browser about script.js Header information returned in ：Cache-Control, Last-Modified, Etag Test success

• Refresh the browser , This is found through panel inspection script.js Still sent a request , Not from memery cache Read from

• And it's Request Headers The request carries If-Modified-Since:12345, If-Non-Match:666 Such information

• This is set on the server Cache-Control:no-cache, 'Last-Modified': '12345', 'Etag': '666'

• The browser will bring the corresponding validation cache header information to the next time it sends a request , To verify whether the policy needs to be updated

• But we found that the browser Response It has content , And we know that there is no change in the content

• At this time, we certainly hope that the server does not need to return the actual content , Instead, read information directly from the cache

• To better explain this strategy , Let's modify the program a little

  if(req.url === '/script.js') {
        
      //  General field settings 
      let ct = 'text/javascript';
      let ccv = 'max-age=2000000000, no-cache'; //  Set a long time ,  Simultaneous setting no-cache
      let lm = '12345'; //  Set a random value first ,  Test whether the browser return header carries 
      let et = '666'; //  ditto 
      //  Read the judgment return content of the request header information 
      const etag = req.getHeader['if-none-match'];
      //  Judge the returned content according to the request information 
      if(etag === '777') {
        
          //  This condition has not been modified , Use cache settings 
          res.writeHead(304, {
        
              'Content-Type': ct,
              'Cache-Control': ccv,
              'Last-Modified': lm,
              'Etag': et
          });
          res.end(""); //  Don't update anything ,  Even if you return anything , None of this really works ( It will not be returned to the browser client ), Because it's set up 304 Of HTTP Code
      } else {
        
          //  to update 
          res.writeHead(200, {
        
              'Content-Type': ct,
              'Cache-Control': ccv,
              'Last-Modified': lm,
              'Etag': et
          });
          res.end("alert('script loaded')"); //  return js The script content 
      }
  }
  

• Modify the program , Restart the service , Refresh the browser once to initialize the program , When the browser is refreshed for the second time ( That is, when requesting the server again )

• About script.js The status code in the request information of becomes 304 Not Modified

• And the message on the sending request header has If-Modified-Since and If-Non-Match Field

• Moreover, its Response Or the previous content , And server program res.end("") It has nothing to do with your settings ( Even if set res.end("xxxyyyzzz") It is also the original content )

• If you check Disable cache, So in Request Headers No cache validation related header information will be sent on the request header

• This is a Chrome browser Disable cache The role of

Expand

• 1 ) alike , If you remove no-cache Of Cache-Control Set up
  • After restarting the service , Clean up browser cache , Refresh the browser and a series of initialization work
  • When the browser is refreshed again , script.js The file will be directly from memory cache Read from ( namely ：from memory cache)
• 2 ) If set no-store Of Cache-Control
  • namely ：'Cache-Control': no-store
  • It ignores any cache related settings , Every visit is 200, Request the latest data directly from the server
• 3 ) As for how the server really does cache verification , This involves the design of the server , Don't involve HTTP Content. , I won't go into details here
  • About Last-Modified This time field
    • You can use the attributes of the file itself , For example, the time attribute was last modified
    • If it is a resource stored in the server , You can set a field , Such as update_at It can be used for identification and update
  • About Etag
    • Every time after reading data from the server , Make a signature and compare it with the signature that received the request , This is the easiest way
    • Of course, there are other better ways to improve the performance of the server , It depends on your design