It's a big headache at the beginning, haha, this thing is really boring and boring, but I often use this knowledge in recent studies, so it's more reassuring to go through it once. In the previous blog, we discussed the header of the http message, which is divided into request header and response header. The request header is mainly composed of request line, request field, general field, and entity field, and the response header is also composed of response line, response header field, general header field, entity header field, etc.
These fields have different purposes, and each field has its own different instructions, so the overall look is still a bit complicated, but it doesn't matter, keep an image one at a time, and you will learn about several frequently used ones in the follow-up continuous learning. Only one field can be grasped and deepened.
1. Response header field
The response header field is the field used by the server to return the response message to the client, and is used to supplement the additional information of the response, server information, and additional requirements for the client.
1.1 Accept-Ranges
Accept-Ranges: bytes
The header field Accept-Ranges is used to inform the client whether the server can handle the range request to specify to obtain a certain part of the resource on the server side.
There are two types of field values that can be specified,可处理范围请求时指定其为 bytes，反之则指定其为 none。
1.2 Age
Age: 600
The Age header field tells the client how long ago the origin server created the response. The unit of the field value is seconds.
If the server that created the response is a cache server, the Age value refers to the time value from when the cached response initiates authentication again to when the authentication is completed. The proxy must add the header field Age when creating the response.
1.3 ETag
ETag: "82e22293907ce725faf67773957acd12"
The first field ETag can inform the client entity identity. It is a way to uniquely identify resources in the form of strings. The server will assign a corresponding ETag value to each resource.
Also, when the resource is updated, the ETag value also needs to be updated. When generating the ETag value, there is no uniform algorithm rule, but only assigned by the server.
When a resource is cached, it is assigned a unique identifier. For example, when using a Chinese version browser to visit http://www.google.com/, the resources corresponding to the Chinese version will be returned, while when using an English version browser to visit, the resources corresponding to the English version will be returned. The URI is the same for both, so specifying a cached resource by URI alone is quite difficult. If the connection is interrupted and reconnected during the download process, the resource will be specified according to the ETag value.
Strong ETag value and weak Tag value
Strong ETag value – no matter how small the entity changes will change its value.
Weak ETag value – The weak ETag value is only used to indicate whether the resources are the same. The ETag value is changed only when the resource has fundamentally changed, making a difference. In this case, W/ is appended to the beginning of the field value.
1.4 location
Location: http://www.usagidesign.jp/sample.html
Use the Location header field to direct the recipient of the response to a resource that is at a different location than the request URI.
Basically, this field will cooperate with the 3xx: Redirection response to provide the redirected URI.
Almost all browsers will forcibly try to access the prompted redirect resource after receiving a response containing the header field Location.
1.5 Proxy-Authenticate
Proxy-Authenticate: Basic realm="Usagidesign Auth"
The header field Proxy-Authenticate will send the authentication information required by the proxy server to the client.
It behaves similarly to HTTP access authentication between client and server, except that the authentication behavior is between client and proxy. When authentication is performed between the client and the server, the header field WWW-Authorization has the same function. The following chapters will elaborate on HTTP access authentication.
1.6 Retry-After
Retry-After：120
The header field Retry-After tells the client how long after it should send the request again. It is mainly used with status code 503 Service Unavailable response or 3xx Redirect response.
Field values can be specified as specific datetimes (Wed, 04 Jul 2012 06:34:24 GMT, etc.), or as seconds since the response was created.
1.7 Server
Server: Apache/2.2.17 (Unix)
The first field Server tells the client the information about the HTTP server application installed on the current server. Not only will the name of the software application on the server be marked, but it may also include the version number and options enabled during installation.
1.8 Vary
When the proxy server receives a request with the Vary header field specifying to obtain resources, if the value of the Accept-Language field used is the same, then the response will be returned directly from the cache. On the contrary, you need to obtain the resource from the source server before returning it as a response
The first field Vary can control the cache. The origin server communicates to the proxy server instructions on how to use the local cache.
After the proxy server receives the response from the source server that contains the item specified by Vary, if you want to cache again, only the request that contains the same header field specified by Vary will be cached. Even if a request is made for the same resource, the resource must be obtained from the source server again because the header fields specified by Vary are different.
1.9 WWW-Authenticate
WWW-Authenticate: Basic realm="Usagidesign Auth"
The first field WWW-Authenticate is used for HTTP access authentication. It informs the client of the authentication scheme (Basic or Digest) and the challenge (challenge) with parameter prompts applicable to the resource specified by the access request URI. The status code 401 Unauthorized response must have the header field WWW-Authenticate.
2. Entity header field
The entity header field is the header used by the entity part contained in the request message and the response message,用于补充内容的更新时间等与实体相关的信息。
2.1 Allow
Allow: GET, HEAD
The first field Allow is used to inform the client that all HTTP methods that can support the resource specified by the Request-URI. When the server receives an unsupported HTTP method, it 405 Method Not Allowed returns a status code in response. At the same time, all supported HTTP methods will be written into the header field Allow and returned.
2.2 Content-Encoding
Content-Encoding: gzip
The first field Content-Encoding will inform the client server of the content encoding method selected for the body part of the entity. Content coding refers to compression without loss of entity information.
2.3 Content-Language
Content-Language: zh-CN
The first field Content-Language will inform the client of the natural language used by the entity body (referring to languages such as Chinese or English).
2.4 Content-Length
Content-Length: 15000
The first field Content-Length indicates the size of the entity body (in bytes). The Content-Length header field can no longer be used when performing content-encoding transmission on the entity body. Since the calculation method of the size of the entity body is slightly complicated, it will not be expanded here. Readers who want to find out, can refer to 4.4 of RFC2616.
2.5 Content-Location
Content-Location: http://www.hackr.jp/index-ja.html
The header field Content-Location gives the URI corresponding to the body part of the message. Different from the header field Location, Content-Location indicates the URI corresponding to the resource returned by the message body.
For example, for a server-driven request using the header field Accept-Language, when the returned page content is different from the actual requested object, the URI will be written in the header field Content-Location. (When visiting http://www.hackr.jp/, the object returned is http://www.hackr.jp/index-ja.html and similar situations)
2.6 Content-MD5
The client will perform the same MD5 algorithm on the received message body, and then compare it with the field value of the header field Content-MD5
Content-MD5: OGFkZDUwNGVhNGY3N2MxMDIwZmQ4NTBmY2IyTY==
The header field Content-MD5 is a string of values generated by the MD5 algorithm. Its purpose is to check whether the message body remains intact during transmission and to confirm the arrival of the transmission.
The 128-bit binary number obtained by executing the MD5 algorithm on the message body is encoded by Base64, and the result is written into the Content-MD5 field value. Since the binary value cannot be recorded in the HTTP header, it must be processed by Base64 encoding. To ensure the validity of the message, the client as the receiver will perform the same MD5 algorithm on the message body again. After the calculated value is compared with the field value, the accuracy of the message body can be judged.
With this approach, sporadic changes in content are unverifiable and malicious tampering cannot be detected. One of the reasons is that if the content can be tampered with, it means that the Content-MD5 can also be recalculated and then tampered with. Therefore, the client in the receiving phase cannot realize that the message body and the header field Content-MD5 have been tampered with.
2.7 Content-Range
Content-Range: bytes 5001-10000/10000
For range requests, the header field Content-Range used when returning the response can tell the client which part of the entity returned as a response matches the range request. The field value is in bytes, indicating the size of the current sending part and the entire entity.
2.8 Content-Type
Content-Type: text/html; charset=UTF-8
The header field Content-Type specifies the media type of the object within the entity body. Like the header field Accept, field values are assigned in the form of type/subtype.
2.9 Expires
Expires: Wed, 04 Jul 2012 08:26:05 GMT
The header field Expires will inform the client of the expiration date of the resource. After the cache server receives the response containing the header field Expires, it will respond to the request with a cache, and the copy of the response will be kept until the time specified by the value of the Expires field. When the specified time expires, the cache server will turn to the source server to request resources when the request is sent.
When the source server does not want the cache server to cache the resource, it is better to write the same time value in the Expires field as the header field Date.
However, when the header field Cache-Control specifies a max-age directive, the max-age directive will be prioritized over the header field Expires.
2.10 Last-Modified
Last-Modified: Wed, 23 May 2012 09:59:55 GMT
The header field Last-Modified indicates when the resource was last modified. Generally speaking, this value is the time when the resource specified by the Request-URI was modified. However, when using CGI scripts for dynamic data processing, this value may become the time when the data is finally modified.
3. The first field for Cookie service
Cookies, which manage the state between the server and the client, are widely used in Web sites, although they are not included in RFC2616 of the standardized HTTP/1.1.
The working mechanism of cookies is user identification and state management. In order to manage the user's status, the Web site will temporarily write some data into the user's computer through the Web browser. Then when the user visits the Web site, the previously issued Cookie can be retrieved through communication.
When calling the Cookie, since the valid period of the Cookie and information such as the sender's domain, path, and protocol can be verified, the data in the officially released Cookie will not be leaked due to attacks from other Web sites and attackers.
As of May 2013, there are the following four types of cookie specification standard documents.
Specifications promulgated by Netscape Corporation
Netscape Communications Corporation designed and developed cookies and formulated related specifications. Around 1994, cookies were officially used in the Netscape browser. The most popular cookie method is also based on this.
RFC2109
An enterprise attempts to standardize cookie specifications with independent technology. The original intention was to interact with the standards developed by Netscape, but unfortunately subtle differences occurred. Now the standard has faded into obscurity.
RFC2965
In order to end the browser war caused by the standard difference between Internet Explorer browser and Netscape Navigator, RFC2965 defines new HTTP headers Set-Cookie2 and Cookie2. In fact, they are hardly ever used.
RFC6265
regards the standard developed by Netscape as the industry de facto standard (De facto standard), and redefines the product of the Cookie standard.
The most widely used cookie standard today is not any one defined in the RFC. It is an extension of the standard established by Netscape.
This section follows with a description of the most widely used standards currently in use. The header fields related to cookies are listed in the table below.
3.1 Set-Cookie
Set-Cookie: status=enable; expires=Tue, 05 Jul 2011 07:26:31
When the server is ready to start managing the state of the client, it will notify various information in advance. The following table shows some field values of the set-cookie field:
expires attribute
The expires attribute of a cookie specifies how long the browser can send the cookie for.
When the expires attribute is omitted, its validity period is limited to the period of maintaining the browser session (Session). This is usually limited until the browser application is closed.
Also, once the cookie is sent from the server to the client, there is no way on the server to explicitly delete the cookie. However, the substantive deletion of client-side cookies can be achieved by overwriting expired cookies.
path property
The path attribute of the cookie can be used to limit the file directory of the sending range of the specified cookie. However, there are other ways to circumvent this restriction, and it seems that its effectiveness as a security mechanism cannot be expected.
domain attribute
The domain name specified by the domain attribute of the cookie can be matched with the end. For example, when example.com is specified, besides example.com, www.example.com or www2.example.com can send cookies.
Therefore, it is safer not to specify a domain attribute, other than to send cookies for specific domain names.
secure attribute
The secure attribute of Cookie is used to restrict the Web page to send Cookie only when HTTPS secure connection.
When sending a cookie, the method of specifying the secure attribute is as follows.
Set-Cookie: name=value; secure
The above example will only recycle cookies under the condition of https://www.example.com/ (HTTPS) secure connection. That is to say, even if the domain name is the same as http://www.example.com/ (HTTP), cookie recycling will not occur.
When the secure attribute is omitted, cookies will be recycled regardless of HTTP or HTTPS.
HttpOnly attribute
The HttpOnly attribute of Cookie is an extended function of Cookie, which prevents JavaScript scripts from obtaining Cookie. Its main purpose is to prevent cross-site scripting (Cross-site scripting, XSS) from stealing cookie information.
The method of sending a cookie specifying the HttpOnly attribute is as follows.
Set-Cookie: name=value; HttpOnly
With the above settings, it is usually also possible to read cookies from within a web page. But using document.cookie of JavaScript, it is impossible to read the contents of the cookie with the HttpOnly attribute attached. Therefore, it is impossible to use JavaScript to hijack cookies in XSS.
Although it is an independent extension function, the current mainstream browsers such as Internet Explorer 6 SP1 and above have already supported this extension. Also, by the way, this extension was not developed to prevent XSS.
3.2 Cookie
Cookie: status=enable
The header field Cookie will inform the server that when the client wants to obtain HTTP state management support, it will include the Cookie received from the server in the request. When multiple cookies are received, they can also be sent as multiple cookies.
4. Other header fields
HTTP header fields are self-extensible. Therefore, in the application of Web servers and browsers, various non-standard header fields will appear.
Next, we describe some of the most commonly used header fields.
- x-frame-options
- x-xss-protection
- dnt
- p3p
4.1 X-Frame-Options
X-Frame-Options: DENY
The header field X-Frame-Options belongs to the HTTP response header, which is used to control the display of website content in the Frame tag of other Web sites. Its main purpose is to prevent clickjacking (clickjacking) attacks.
The header field X-Frame-Options has the following two field values that can be specified.
- DENY : Deny
- SAMEORIGIN : Allowed only when pages under the same domain name (Top-level-browsingcontext) match. (For example, when the http://hackr.jp/sample.html page is specified as SAMEORIGIN, then the frames of all pages on hackr.jp are allowed to load the page, while pages with other domain names such as example.com are not allowed )
- ALLOW-FROM: You can define the page address that allows the frame to load
The browsers that support this header field are: Internet Explorer 8, Firefox 3.6.9+, Chrome 4.1.249.1042+, Safari 4+ and Opera 10.50+, etc. All major browsers now support it.
It would be ideal to pre-set the X-Frame-Options field value on all web servers.
Note: Regarding clickjacking attacks
Click-to-touch attacks can be understood as using the ifram tag to load the target website (victim website) into the camouflaged page (the hacker's attack machine), so that the buttons for sensitive operations overlap with some buttons on the camouflaged page, and then use css styles Hide such target pages so that the inside of the fake page looks the same as a normal web page. The so-called malicious attack is realized after tricking the user into clicking a fake button.
Because the user's click is clicked elsewhere during the whole process, it is called a click hijacking attack. Of course, this problem can be solved by setting the x-frame-options header.
4.2 X-XSS-Protection
X-XSS-Protection: 1
The header field X-XSS-Protection belongs to the HTTP response header, which is a countermeasure against cross-site scripting attacks (XSS), and is used to control the switch of the browser's XSS protection mechanism.
The field values that can be specified in the header field X-XSS-Protection are as follows.
- 0 : set XSS filtering to invalid state
- 1: Set the XSS filter to an effective state
Note: This thing is useless now. After all, because the browser's restrictive capabilities are often bypassed or because it is too strict to affect access, developers simply cancel such a defense mechanism and leave it to the server to solve it by itself.
You can refer to the explanation on MDN for further understanding
https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers/X-XSS-Protection
4.3 DNT
DNT: 1
The header field DNT belongs to the header of the HTTP request, where DNT is the abbreviation of Do Not Track, which means that personal information is refused to be collected, and it is a method of refusing to be tracked by precise advertisements.
The field values that can be specified in the header field DNT are as follows.
- 0 : Agree to be tracked
- 1: Refuse to be tracked
Since the function of the header field DNT is valid, the Web server needs to
support DNT accordingly.
4.4 P3P
P3P: CP="CAO DSP LAW CURa ADMa DEVa TAIa PSAa PSDa IVAa IVDa
The header field P3P belongs to the corresponding header of HTTP. By using P3P (The Platform for Privacy Preferences, online privacy preference platform) technology, the personal privacy on the Web site can be made into a form that can only be understood by the program to protect user privacy. the goal of.
To configure P3P, follow the steps below.
Step 1: Create P3P Privacy
Step 2: After creating the P3P privacy control file, save it and name it in /w3c/p3p.xml
Step 3: After creating the Compact policies from P3P privacy, output them to the HTTP
response
Please refer to the link below for detailed specification standards of P3P.
The Platform for Privacy Preferences 1.0（P3P1.0）Specification
Abolition of the X- prefix in the protocol:
In various protocols such as HTTP, the prefix X- is added to non-standard parameters to distinguish them from standard parameters and make it possible for those non-standard parameters to be extended. However, this simple and crude approach has all kinds of harm and no benefit, so it is proposed to stop this practice in "RFC 6648 - Deprecating the “X-” Prefix and Similar Constructs in Application Protocols”. However, no change should be required for X- prefixes already in use.
At this point, I believe that everyone has some understanding of common http header fields. For more detailed content, you can refer to the book "Illustrated http", which is very detailed.