HTTP Caching

Cache-control: specifies the difference between no-cache and no-store

I didn’t know the difference between no-cache and no-store. This time, the effects of both were verified in the project through experiments. In nginx, do the following configuration: set cache-control to no-store to check the effect of the page.

location ~* /intelligence/(.*)\.(js|css) { root /usr/app/frontend/; index index.html; add_header Cache-Control 'no-cache'; Proxy_set_header Connection ""; try_files $uri $uri/ /index.html; autoindex off; }Copy the code

No-cache indicates that the server must be checked anyway, that is, 200 from disk/from memory is not possible, and the best result is 304. No-store, on the other hand, means that it will never be cached, which means that the server will only return 200. Not 200 from disk/from memory, not 304.

Cache-control: the difference between private and public

Is whether the cache server is allowed to cache resources. Private does not allow caching, public does allow caching.

HTTP proxy software

fiddler charls anyproxy

The reverse proxy

X-forward-for, x-real-ip The former is a number of IP addresses, that is, one IP address is recorded every time a node passes through. The latter means that only the original client IP is recorded.

csrf vs click-jacking

The CSRF just needs to be accessed click-jacking means that the user also needs to click to form it

CSRF takes effect for three reasons:

  1. Cookies are automatically added to the request header
  2. Form submission is not restricted across domains (language design)
  3. Js can automatically submit forms (language design)

Ways to prevent:

  1. Prevents non-domain requests in the browser address bar from carrying cookies
  2. Change the form submission to an Ajax request

Samesite: strict | lax | none limit form form submission

X-frame-option: SameOrigin limits iframe click hijacking.