Amusing those MIME headers in the HTTP protocol

HTTP protocol is our most commonly used protocol, we surf the Internet through the browser, download the file, upload the data a lot of it is used, but I used to it is mengmengdongdong, gradually, I have some sentiment, so it is recorded here. This article will try to use witty strokes to introduce those MIME header field header fields in HTTP.

Scenario One: Use wget to download a source package, such as the ATS 5.3 version, using the following command:

Wget-d "HTTP://MIRROR.BIT.EDU.CN/APACHE/TRAFFICSERVER/TRAFFICSERVER-5.3.0.TAR.BZ2"

We focus on the response header section:

http/1.1 tells us that we are using the 1.1 version of the HTTP protocol, and now HTTP/2 is out, but we don't see much of it;

The number OK tells us the response status code is 200, is the normal return data, the other has a lot of response code, such as 2XX,3XX,4XX,5XX, etc., do not elaborate;

Server tells us that the software is Nginx, version is 1.1.9, and now the latest version has been to 1.8.x;

Content-type tell us the type of response, here is the C + + source, of course, application/octet-stream, and other pictures, videos, json,html,xml and the like;

Content-length tells us the length of response body, that is, the size of the source packet bytes;

Date tells us the time from the server to get the source package, and my current difference of 8 hours, is estimated to be the time zone setting problem;

Last-modified told us that the ATS 5.3 source package on the server time, just its external release time;

Connection: Tell us, c/s direct connection to maintain the way, here the keep-alive said is KeepAlive, not immediately disconnect, if there are other requests, can be reused here TCP connection;

Accept-ranges tells us to start receiving from the required bytes;

Thus, these response headers are very reference, can provide us with a wealth of information.

Scenario two: Using Curl to download an ordinary Web page file using the ATS 5.3, use the following command:

Curl-o/dev/null-vx 127.0.0.1:8081-h "ACCEPT-ENCODING:GZIP,DEFLATE,SDCH" "http://news.sohu.com"

The same head is not repeated here.

Vary tells us that the different values of the accept-encoding head should be differentiated to obtain different copies of the document, such as gzip compressed, deflate compressed, not compressed, these are different copies;

Cache-control tell us the cache rule, here is not to change the document, document the maximum survival period is 120 seconds, from the cache to get the file to start computing, more than 120s to the server to verify again;

Expires tells us that at that specified moment, this document is expired and must be re-requested from the source station;

Content-encoding tells us that the document was compressed using gzip;

Age tells us that the lifetime of the document, the document that was just acquired, the current deposit is 0;

Proxy-connection tells us that the network connection between Curl and proxy is keepalive;

Via tells us that the request from the source station to the client through the agent situation, here only after a proxy ATS 5.3, note that the following cache conditions [CMSSFW] indicates that the source is retrieved;

X-rs,fss-cache is the source station custom header, do not make representations.

To repeat the above request several times, we get

We see a few differences:

The age value has changed, originally is 0, is now 8, indicating that the document in the ATS cache survived for 8 seconds, its maximum survival is 120 seconds, for a news portal, this is reasonable, 120 seconds after the content must be refreshed page;

The cache state in the VIA header is changed and is now [CRs F], which represents the hotspot content obtained from RAM in ATS;

Scenario Three: Range request and check whether the server supports the breakpoint continuation function

The-r/--range option in the Curl command line supports sending a range request to the server, and the-i option specifies that the response header information is displayed

Note that the return status code is 206,

Accept-ranges tells us whether the server supports the specified range request and what kind of fragment request, here is the byte

Content-range tells us the byte position of this part in the entire return body, because we are requesting the first 10 bytes of the picture, so the Content-range value is bytes 0-9/1575, and the following 1575 is the total number of bytes in the picture.

Above is the response header information that curl gets, where if you can find Content-range, it indicates that the server supports the continuation of the breakpoint, and some servers return accept-ranges. The Nginx server supports the continuation of the breakpoint by default, without any additional configuration.