Hand to hand teaches you how to solve the redirection cache problem

Problems arise:

Test baba: The test environment is set up, so let’s pack the front end. Weber: Ok! Quickly enter the command: NPM run build:stagging Three minutes later…… Test baba: Is it the wrong bag? Why hasn’t it changed? Weber: Refresh the page! Test baba: Useless duck ~ weber: clam ~ clean browser cache! Test baba: it’s out, cow skin duck!!

At this point, I got to thinking, why is it a huge bug that requires users to manually clear the browser cache every time they publish? 1. Refresh the page and retry the doc [index.html] request, which is invalid; Clearing the browser cache does not work, indicating that the browser cached the file and the refresh request is still the previous file. 2, Webpack, output to JS, CSS hash, js, CSS should not cache.

Start screening

I. Check the WebPack configuration:

module.exports = {

  context : path.join(__dirname,'src'),

  entry:{

    main: './index.js'.

    vender:['./jquery.js'.'./test.js']

  },

  module: {

    rules:[{

      test:/\.css$/,

      use: extractTextPlugin.extract({

        fallback:'style-loader'.

        use:'css-loader'

      })

    }]

  },

  output:{

    path:path.join(__dirname, '/dist/js'),

    filename: 'bundle.[name].[hash].js'.

  },

  plugins:[

    new extractTextPlugin('.. /css/bundle.[name].[hash].css')

  ]

}

Copy the code

Found no problems with webpack packaging.

Second, there is no problem with the packaged documents.


The index. HTML file generated after packaging is introduced.


3, Check the network request and suddenly realize:

Index.html is a 304 request, which means index.html is cached.

To solve the problem

Start looking for solutions, and there are many ways, both front-end and back-end.

Considering the HTML generated by Webpack is only used as a container to import JS and CSS, the cost of not caching HTML files is actually very small. Select the following method:

1, add the HTML configuration not to cache in the HTML head header:

Note: Meta is an auxiliary tag in the HEAD area of the TML language, where the HTTP-Equiv field defines some of the behavior of the server and the user agent. In the previous specification, the http-equiv field of the meta had the following values similar to the HTTP Header caches related fields

<head>

  <meta http-equiv="pragma" content="no-cache">

  <meta http-equiv="cache-control" content="no-cache">

  <meta http-equiv="expires" content="0">

</head>

Copy the code

If this is the case, configure the index.html file under the public file.

Add add_header cache-control ‘no-cache, no-store, must-revalidate’ to nginx.conf

server {

  listen       80;

  server_name  localhost;



  root        /usr/share/nginx/html;

  index       index.html;



  location ~* \.(gif|jpg|jpeg|png|css|js|ico|eot|otf|fon|font|ttf|ttc|woff|woff2)$ {

      expires 1M;

      add_header Cache-Control "public";

  }



  location / {

      add_header Cache-Control 'no-cache, no-store, must-revalidate';

  }



  error_page  404              /index.html;

}

Copy the code

In fact, these two configurations are in the request head plus no cache HTML configuration, one in the front, one in the operation. Looking through the W3C documentation, these values have now been removed from the W3C specification fields for a good reason:

Putting caching instructions into meta tags is not a good idea, because although browsers may read them, proxies won’t. For that reason, they are invalid and you should send caching instructions as real HTTP headers.

After synthesis, the second scheme is more perfect.

Bug:

Weber: This time the nginx configuration was modified. This time the caching problem should not occur. There is no need to manually clear the browser cache. Weber: (confident little expression, expecting red hand) Something is still wrong with the duck! Still not updated! Weber: You’re asking directly, right? Did you refresh the page? Weber: Ok, I get it!

Here comes the bug. If the url is requested directly, the latest HTML file will be requested, but there are also cases where the user does not refresh the direct request.

Clear your head:

At this point, the problem is pretty clear and can be easily solved by reworking the WebPack packaging process and browser caching strategy. One, Webpack packaging:

Public /index.html: the file is a template that is processed by the HTml-webpack-plugin. During the build process, resource links are injected automatically. In addition, the Vue CLI automatically injects resource hints (preload/prefetch, manifest, and icon links (when using the PWA plug-in) as well as resource links to JavaScript and CSS files handled during the build process. Ouput files inside will inject

HTTP redirection:

The nginx configuration of the server is as follows:

If you type: https://example.com, https://example.com/a, both locate the index.html file under root and trigger the request for an HTML file.

Three, browser cache:

The request status changed to 200 after the HTML file was not cached.

Therefore, in the case of not refreshing the browser request, HTML is not requested, is still the first time to enter the URL request back HTML file, js, CSS inside is also before, so the browser will not request JS, CSS file. Solutions:

Add the version number to the AXIos request, and if the version number doesn’t match, return the code and let the front end interact with the user to see if the page has been updated and needs to be refreshed.