Some HTTP headers I know: cache-control, e-tag, etc.

In the HTTP protocol, the explanation of some header fields is vague, and the online explanation is even a fight, such as cache-control: No-Cache. To find out this header, google has a lot of information, but many of them have their own opinions and even conflict with each other. Cache-control in HTTP headers is undoubtedly a very important header, which often involves performance issues, cache, cache proxy, and so on. Of course, there are other header fields such as last-modified, but they have very clear meanings, at least not as vague as cache-control.

Even browsers have different understandings of cache-control, which leads to different performance of this header.

A lot of information about cache-control on the internet is vague. I don't think many of them are there, or we may have ignored a few things, which makes it understandable when we look at these materials. Or the author thinks that some areas are easy to understand, so we don't need to emphasize them at all, but these ignored "prerequisites" make it difficult for us to understand even after reading the materials. Some "prerequisites" that are often ignored in the information that explains cache-control include the following:

1. Whether the cache-control is in response or request.Many materials do not specify cache-control in response when interpreting cache-control (that is, the cache-control sent when the server responds) or the cache-control in the request (that is, the cache-control sent when a resource is requested by a user agent, usually a browser ).

2. What is cache.The word "cache" has n interpretations, especially those translated from English. "Cache" can refer to the cached object or the cache system on the HTTP message chain, such as the browser cache system and the cache on the proxy server, or some proxy servers (such as squid) designed for caching, or the cache on the original server (such as the cache object of C ). On the other hand, depending on the context, "Caching" may also refer to the caching mechanism... n. So when some materials are ignored, the readers have read the old questions, but they have not yet figured out the new questions.

Speaking of the cache system on the HTTP link, we generally refer to the browser cache system and the proxy server cache.

What I know about the cache-control command is:

When cache-control appears in the request:

Cache-control: No-controlTell the cache system on the HTTP message chain (that is, the browser cache and the cache on the proxy server). This request requires that the cache be ignored together, and the original server must recalculate and generate a response to the user. Therefore, do not respond to these caches even if the local cache on the browser is not expired or the cache on the proxy server is not expired. When we force a new page in the browser (press Ctrl + F5), this header is sent (different browsers will cache-contro: No-cachel and pragam: no-Cache two headers are sent together)

Pragma: No-Cache: It is the same as cache-control: No-control, but some browsers keep this header out of compatibility with HTTP/1.0. Note:Pragma: No-CacheIt should only appear in the request, indicating that you do not want to obtain the cache. No HTTP clause defines Pragma: No-cache in response, so Pragma: No-cache in response is invalid.

When cache-control appears in response:

Cache-control: No-controlThe server tells the cache system on the HTTP message chain not to cache this response result. In fact, this is not a hundred percent positive, and different browsers seem to have different responses when receiving this header.

When the Response Header has cache-control: No-control:

Chrome: If-modified-since is sent when you access the same URL. This indicates that Chrome caches the cache even if it receives cache-control: No-contro.

Ie9: When you access the same URL again, there is no if-modified-since or other cache-related header fields, just like the first access (without cache, the cached Folder does not contain cached files. In other words, ie9 receives the cache-control: No-contro and does not cache the response content.

FF: similar to ie9 Behavior

In addition,Cache-control: No-storeIt makes sense to appear in response, which means to tell the cache system not to cache or store response content (do not store the content in any form, including in the cache folder, to avoid leakage of some sensitive information ). Chrome, ie9, and FF implement the same header. When the response with this header is received, no related cache files can be found in the cache directories of the three browsers.

 

 

Another e-tag. See http://baike.baidu.com/view/3039264.htm for details