This chapter mainly explains the structure of the HTTP header and the usage of each field in the header.

1. HTTP header

The figure above shows the structure of an HTTP request packet.

HTTP request packets consist of methods, URIs, HTTP versions, and HTTP header fields.

Example of request header information:

Hackr.jp User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; The rv: 13.0) Gecko / 2010010 Accept: text/HTML and application/XHTML + XML, application/XML. Q = 0.9 * / *; q=0 Accept-Language: ja,en-us; Q = 0.7, en. Q =0.3 accept-encoding: gzip, deflate DNT: 1 Connection: keep-alive if-modified-since: Fri, 31 Aug 2007 02:02:20 GMT If-None-Match:"45bae1-16a-46d776ac"
Cache-Control: max-age=0
Copy the code

An HTTP response packet consists of the HTTP version, status code (number and cause phrase), and HTTP header field.

The following figure shows the HTTP response packet structure:

Header instance of response message:

HTTP/1.1 304 Not Modified
Date: Thu, 07 Jun 2012 07:21:36 GMT
Server: Apache
Connection: close
Etag: "45bae1-16a-46d776ac"
Copy the code

HTTP header fields

2.1 HTTP header Field Structure

The HTTP header field transmits important information, and its structure is basically as follows:

Header field name: field valueCopy the code

Such as:

The content-type: text/HTMLCopy the code

In addition, some header fields can have multiple values, as shown below:

Keep-alive: timeout=15, Max =100Copy the code

2.2 HTTP header Field Types

HTTP header fields are classified into four types based on their actual use.

  • Generic header field: Indicates the header field used by both request and response packets.
  • Request header field: Indicates the header for sending request packets from the client to the server. Supplementary information about the additional content of the request, client information, and priority of the response content.
  • Response header field: indicates the header of the response packet sent from the server to the client. Additional content added to the response also requires additional content information from the client.
  • Entity head field: Header used for the entity part of request and response messages. Added information related to entity content such as the update time of resource content.

2.3 HTTP header Fields overview

2.3.1 General header field
Header field name instructions
Cache-Control Controls the behavior of caching
Connection Hop – by – hop header and connection management
Date Date and time when the packet was created
Pragma Packet instructions
Trailer View the header at the end of the packet
Transfer-Encoding Specifies the transmission code of the packet body
Upgrade Upgrade to another protocol
Via Proxy server information
Warning Error notification
2.3.2 Request header Field
Header field name instructions
Accept The type of media that the user agent can handle
Accept-Charset Preferred character set
Accept-Encoding Priority content encoding
Accept-Language Preferred language (natural language)
Authorization Web Information Authentication
Expect Expect specific behavior from the server
From Email address of the user
Host The server where the resource is requested
If-Match Compare Entity Tag (ETag)
If-Modified-Since Compares the update times of resources
If-None-Match Compare entity tags (as opposed to if-match)
If-Range Send scope requests for entity Byte when the resource is not updated
If-Unmodified-Since Compare resource update times (as opposed to if-modified-since)
Max-Forwards Maximum transmission hop by hop
Proxy-Authorization The proxy server requires authentication information of the client
Range Byte range request for the entity
Referer The original acquirer of the URI in the request
TE Priority of transmission encoding
User-Agent HTTP client program information
2.3.3 Response header Field
Header field name instructions
Accept-Ranges Whether to accept byte range requests
Age Calculate the elapsed time of resource creation
ETag Matching information of resources
Location Causes the client to redirect to the specified URI
Proxy-Authenticate The proxy server authenticates the client
Retry-After Request the timing of the request to be made again
Server HTTP server installation information
vary Proxy server cache management information
WWW-Authenticate Authentication information about the server to the client
2.3.4 Entity header Field
Header field name instructions
Allow HTTP methods supported by the resource
Content-Encoding The encoding method applicable to the entity body
Content-Language The natural language of entity subjects
Content-Length Size of entity body in bytes
Content-Location Replace the URI of the corresponding resource
Content-MD5 The packet digest of the entity body
Content-Range The location range of the entity body
Content-Type The media type of the entity body
Expires The date and time when the entity body expires
Last-Modified When the resource was last modified

These are some of the most common HTTP header fields.

In addition, there are some non-HTTP /1.1 specification header fields are also used more, such as set-cookie, Cookie, etc.

In addition, HTTP headers are divided into two types — end-to-end headers and hop-by-hop headers — based on the behavior that will be defined as cached and uncached proxies.

The header field of the end-to-end header class is forwarded to the final recipient of the request/response and must be stored in the response generated by the cache, specifying that it must be forwarded;

The hop – by – hop header is only valid for a single forward and will not be forwarded because it passes through a cache or proxy. Versions after HTTP/1.1 that use hop-by-hop headers require a Connection header field.

The following fields belong to the hop-by-hop header field:

  • Connection
  • Keep-Alive
  • Proxy-Authenticate
  • Proxy-Authorization
  • Trailer
  • TE
  • Transfer-Encoding
  • Upgrade

All other fields are end-to-end header fields.

Let’s start with the details of the header fields.

2.4 HTTP/1.1 General header fields

Against 2.4.1 cache-control

You can manipulate how the Cache works by specifying the header field cache-control.

Cache-control instruction arguments are optional, separated by commas. This header field can be used in both request and response.

Cache-Control: private, max-age=0, no-cache
Copy the code

Cache-control commands are as follows:

Request instructions:

instruction parameter instructions
no-cache There is no Force revalidation to the source server
no-store There is no No content of the request or response is cached
Max – age = [s] necessary The maximum age value of the response
Max – stale (= [s]) Can be omitted Accept the response that has expired
Min – fresh = [s] necessary The expected response within the specified time is still valid
no-transform There is no Agents cannot change media types
only-if-cached There is no Get resources from the cache
cache-extension New Instruction Token (token)

Response instruction:

instruction parameter instructions
public There is no Caching of responses can be provided to any party
private Can be omitted Returns a response only to a specific user
no-cache Can be omitted You must verify its validity before caching
no-store There is no No content of the request or response is cached
no-transform There is no Agents cannot change media types
must-revalidate There is no Cacheable but must be validated with the source server
proxy-revalidate There is no The intermediate cache server is required to validate the cached response
Max – age = [s] necessary The maximum age value of the response
S – maxage = [s] necessary The maximum age value for the public cache server response
cache-extension New Instruction Token (token)

An instruction specifying whether to cache or not:

Public instruction

Cache-Control: public
Copy the code

When you specify the use of a public directive, it makes it clear that other users can take advantage of the cache.

Private instruction

Cache-Control: private
Copy the code

When the private directive is specified, the response is only for a specific user as an object. When the object makes a request to the server, the server returns the cached resource.

No – the cache instructions

Cache-Control: no-cache
Copy the code

The purpose of this directive is to prevent the use of expired cache resources.

If a client sends a request that contains the no-cache directive, it indicates that the client will not accept an expired cached response. The intermediate proxy server must then forward the request to the source server.

If the response from the server contains the no-cache command, the cache server cannot cache the resource, and the source server will not confirm the validity of the resource requested by the cache server and will not cache the resource response.


Directives that control executable cache objects:

No – the store instruction

Cache-Control: no-store
Copy the code

When using the no-store directive, it is implied that the request or response contains confidential information.

This directive therefore states that the cache cannot store any part of the request or response locally.

Pay attention to

In a literal sense, it’s easy to think of no-cache as not caching, but in fact no-cache means not caching expired resources. The cache verifies the validity of the resources to the source server before processing them. No-store is really not caching.


Directives specifying cache duration and authentication:

S – maxage instructions

Cache-control: smax-age=604800 (unit: second)Copy the code

This directive has the same function as max-age except that the S-maxage directive is only suitable for common cache servers used by multiple users.

When using the smax-age directive, the Expires field and the max-age directive are ignored.

Max – age instructions

Cache-control: max-age=604800 (unit: seconds)Copy the code

When a client sends a request that contains a max-age directive, the client receives the cached resource if the cache time value is determined to be smaller than the specified value. In addition, when a max-age value of 0 is specified, the cache server usually needs to forward requests to the source server (equivalent to no-cache).

When the server returns a response containing a max-age command, the cache server does not verify the validity of the resource. The max-age value represents the maximum time that the resource has been cached.

A server running HTTP/1.1 caches that also has an Expires header field will process the Max-age directive first and ignore the Expires header field. The opposite is true for servers running HTTP/1.0.

Min – fresh instructions

Cache-control: min-fresh=60 (unit: second)Copy the code

The Min-fresh directive requires the cache server to return cached resources that have not expired by at least the specified time.

Max – stale instructions

Cache-control: max-stale=3600 (unit: second)Copy the code

Using max-stale indicates that stale cache resources are accepted. The following values indicate the specific expiration time, indicating that the response cannot be outdated beyond the given time. If no value is passed, the client will accept it no matter how long it takes.

Only – if – cached command

Cache-Control: only-if-cached
Copy the code

Use this directive to indicate that the client will only require the target resource to be returned if it is cached locally by the cache server. That is, only cached resources are accepted without checking the validity of the resources to the source server. If the local cache of the proxy server does not respond, 504 Gateway Timeout is displayed.

Must revalidate instructions

Cache-Control: must-revalidate
Copy the code

Using this directive, the proxy verifies again to the source server that the response cache to be returned is currently valid.

A must-revalidate directive ignores a max-stale directive.

The proxy – revalidate instructions

Cache-Control: proxy-revalidate
Copy the code

This directive requires all cache servers to verify the validity of the resource before receiving a response from a client with this directive.

No – the transform command

Cache-Control: no-transform
Copy the code

This directive states that the cache cannot change the entity’s media type either in the request or in the response.

This prevents caching or proxy compression of images and similar operations.

2.4.2 Connection

This header field does two things:

  • Control is no longer forwarded to the agent’s first self-carry
  • Managing persistent Connections
Connection: the name of the header field that will not be forwardedCopy the code

This statement indicates that the specified header field is no longer forwarded to the next level server (possibly a proxy).

In addition to the above features, this header can also manage persistent connections:

Connection: close
Copy the code

This directive explicitly specifies to disconnect the current connection. (HTTP/1.1 all connections are long connections by default)

Connection: keep-alive
Copy the code

The above directive explicitly specifies that the current connection is a long connection. (Available before HTTP/1.1)

2.4.3 Date

This field indicates the date and time when the HTTP packet is created.

Date: Tue, 03 Jul 2012 04:40:59 GMT
Copy the code
2.4.4 Pragma

This field is a legacy of HTTP/1.1 and is defined for backward compatibility.

Pragma: no-cache
Copy the code

with

Cache-Control: no-cache
Copy the code

Function consistent.

2.4.5 Trailer

This field indicates which header fields are recorded after the packet body and can be used in HTTP/1.1 block transmission.

2.4.6 Transfer – Encoding

This header field specifies the encoding used when transmitting the body of the message.

Transfer-Encoding: chunked
Copy the code
2.4.7 Upgrade

This header field is used to detect whether HTTP and other protocols can be upgraded to a higher version for communication, and its parameter value can be used to specify a completely different communication protocol.

From 2.4.8 Via

The header field is used to trace the transmission path of request and response packets between the client and the server.

When a packet passes through a proxy or gateway, information about the server is appended to the header field Via and then forwarded. In addition, this field can not only be used to trace packet forwarding, but also avoid request loopback.

Each proxy server adds information about its own server to Via.

1.0 and 1.1 indicate the HTTP version of the server.

2.4.9 Warning

This header is a self-contained warning that usually tells the user about some cache-related issues in the following format:

Warning: [Warning code][Warning host: port number][Warning content] ([date and time])Copy the code

For specific warning codes, see Table 6-7 in Diagram HTTP.

2.5 Request header Field

The field in the request header is used in the request packet sent from the client to the server.

2.5.1 the Accept
Accept: text/html,application/xhtml+xml,application/xml; Q = 0.9 * / *; Q = 0.8Copy the code

This header field informs the server of the media types that the user agent can handle and the relative priority of the media types. You can specify multiple media types at once using the type/subtype format.

Common media types:

  • Text file:

    text/html,text/plain,text/css,application/xhtml+xml,application/xml...
    Copy the code
  • Image files

    image/jpg,image/gif,image/png...
    Copy the code
  • Video file

    video/mpeg,video/quicktime...
    Copy the code
  • The binary file used by the application

    application/octet-stream,application/zip...
    
    Copy the code

Multiple protocols are separated by commas, with a semicolon before the media type and a semicolon after the weight.

When the server serves multiple types of content, the media type with the highest weight is returned first.

2.5.2 the Accept – Charset
Accept-Charset: iso-8859-5,unicode-1-1; Q = 0.8Copy the code

This field can be used to inform the server of the character set supported by the user agent and the weight of the character set.

2.5.3 Accept – Encoding
Accept-Encoding: gzip,deflate

Copy the code

This field is used to inform the server of the content encoding supported by the user agent and the priority of the content encoding format.

Here are some of the most commonly used content encoding formats:

  • gzip

    An encoding format (RFC1952) generated by the file compression program gzip (GNU zip).

  • compress

    Encoding format generated by the UNIX file compression program COMPRESS.

  • deflate

    A combination of zlib format and deflate compression algorithm generated encoding format.

  • identity

    Default encoding format that does not compress or does not change.

2.5.4 Accept – Language

Tell the server what natural language it can handle.

Accept-Language: zh-cn,zh; Q = 0.7, en - us, en. Q = 0.3Copy the code
2.5.5 Authorization

This field is used to tell the server about the authentication information of the user agent.

Authorization: Basic dWVub3NlbjpwYXNzd29yZA==

Copy the code
2.5.6 Expect
Expect: 100-continue

Copy the code

The client uses this field to tell the server that it expects a particular behavior.

If the server does not understand this particular behavior, it will return an error of 417 Expectation Failed.

2.5.7 the From
From: [email protected]

Copy the code

This field is used to tell the server the E-mail address of the user using the user agent.

2.5.8 Host
Host: www.hackr.jp

Copy the code

Most of the time a server deployed on multiple sites, corresponds to the multiple domain name, when the DNS to the server, we need to know is which website, user access to assign to the corresponding port to the corresponding procedures for processing, so the Host user access is used to inform the server Host name and port number.

The Host header is the only header field that must be included in the request.

If the server does not have a host name, send a null value.

2.5.9 If – Match

A request header field in the form of if-xxx can be called a conditional request. Once the server receives a conditional request, it will only execute the request if it determines that the condition is true.

If-Match: "123456"

Copy the code

This header field is one of the strings that tells the server the value of the entity tag (ETag) used to match the resource. The server compares the field value of if-match with the ETag value of the resource and executes the request only If the two values are consistent. Otherwise, the feed Failed response is returned with status code 412.

When * is used, the server matches any ETag value.

2.5.10 If – Modified – Since

This header field specifies a point in time after which the request will be answered if the resource has been modified.

If-Modified-Since: Thu, 15 Apr 2004 00:00:00 GMT

Copy the code

If the resource has Not been Modified since this point in time, a response with the 304 Not Modified status code is returned.

2.5.11 If – None – Match

This field has the opposite effect to if-match. The request is answered only if the value of this field does not match the resource’s ETag.

2.5.12 If – Range

If the value of this field matches the value of the ETag or the date and time of the update, it is treated as a range request; If there is no match, all resources are returned.

2.5.13 If Unmodified — Since
If-Unmodified-Since: Thu, 03 Jul 2012 00:00:00 GMT

Copy the code

The header field, contrary to if-Modified-since, tells the server that the specified resource is processing the request only If there is no change after the specified date, otherwise it returns the 412 Precondition Failed state code.

2.5.14 Max – Forward

When a request is sent through the TRACE method or the OPTIONS method that contains the header field max-forward, this field specifies the maximum number of servers that can pass through as a decimal integer.

Max-Forward: 10

Copy the code
2.5.15 Proxy – Authorization
Proxy-Authorization: Basic dGlwObjkNLAGFfY5

Copy the code

This field informs the server of the information required for authentication between the client and the proxy server.

2.5.16 Range
Range: bytes=5001-10000

Copy the code

This field is suitable for scope requests that fetch only part of the resource, and it tells the server the specified scope of the server resource that it needs.

The server that receives a request with this field returns a 206 Partial Content response, or a 200 OK response with all resources if it cannot process the range request.

2.5.17 Referer
Referer: http://www.hackr.jp/index.htm

Copy the code

This header field tells the server the URI of the original resource requested.

According to this field, the server can know from which address the current request was redirected. For more information on Referer, read Ruan Yifeng’s blog: HTTP Referer Tutorial.

2.5.18 TE
TE: gzip, deflate. Q = 0.5Copy the code

This field tells the server the Transfer Encoding and relative priority of the response that the client can process, similar to transfer-encoding.

2.5.19 the user-agent
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; The rv: 13.0) Gecko / 20100101 Firefox / 13.0.1Copy the code

This field sends information about the browser and user agent name that created the request to the server. When a crawler makes a request, it is possible to add the author’s address to this field.

It is worth mentioning that some websites will implement anti-crawler strategy, they will verify whether the user-Agent field is from the browser, if not, they will reject the crawler request; So if you want to continue to get the information you want, you will use this field to forge the crawler into a browser.

2.6 Response header Field

The response header field is the field used in the response packet returned by the server to the client, which is used to supplement the additional information of the response, server information, and additional requirements for the client.

2.6.1 Accept – Ranges
Accept-Ranges: bytes

Copy the code

This field is used to tell the client whether the server can handle a range request to specify a resource for a portion of the server side. Bytes when the server is able to handle client range requests, and None when the server is unable to handle client range requests.

2.6.2 Age
ETag: 600

Copy the code

This header field tells the client how long ago the source server created the response, and the value of the field is in seconds.

If the server that creates the response is a cache server, the Age value refers to the time between the second initiation of authentication and the completion of authentication.

2.6.3 ETag
ETag: "82e22293907ce725faf67773957acd12"

Copy the code

The header field, ETag, tells the client about the entity’s identity. It is a way to uniquely mark a resource as a string. The server assigns an ETag value to each resource.

When the resource is updated, the ETag value is also updated. When ETag values are completed, there is no uniform algorithm rule, only assigned by the server.

The URI that accesses a resource generally does not change, but when the resource itself changes, the ETag corresponding to the resource is updated.

Strong ETag and weak ETag

ETag values are strong and weak. Strong ETag values will change no matter how slight the resource changes, while weak ETag values will change only when the resource fundamentally changes and produces differences.

2.6.4 Location
Location: http://www.usagidesign.jp/sample.html

Copy the code

This header field can direct the client receiving the response to a resource different from the location of its request URI.

Basically this field is used in conjunction with the 3XX redirection status code.

2.6.5 Proxy – Authenticate
Proxy-Authenticate: Basic realm="Usagidesign Auth"

Copy the code

This header field sends the authentication information required by the proxy server to the client.

2.6.6 Retry After
Retry - After: 120Copy the code

This header field tells the client how long it will take to initiate the request again. This field can be specified as a specific time or the number of seconds after the response was created.

2.6.7 Server

This header field tells the client about the HTTP server application installed on the current server.

Server: Apache / 2.2.17 (Unix)Copy the code
2.6.8 than
Vary: Accept-Language

Copy the code

This header field controls the cache, and the source server communicates commands to the proxy server about how the local cache is used.

In particular, this header field specifies an additional header field, such as accept-encoding above. If the value of the specified field has not changed, the cache resource is used; If the value of a specified field changes, you need to request the latest resource from the source server.

This field can specify user-Agent to prevent the mobile browser from accessing the PC page cache.

When this field is specified as *, all requests are treated as unique and cached.

2.6.9 WWW – Authenticate
WWW-Authenticate: Basic realm="Usagidesign Auth"

Copy the code

This header field is used for HTTP access authentication.

2.7 Entity head field

The entity header field is the header used by the entity part contained in the request message and response message, and is used to supplement the update time and entity-related information of the content.

2.7.1 Allow
Allow: GET, HEADCopy the code

This header field notifies the client of HTTP methods supported by the server. When the server receives an unsupported HTTP method, the server returns the 405 Not Allowed status code.

2.7.2 the Content – Encoding
The Content - Encoding: gzipCopy the code

This header field tells the client the content encoding format to use for the body of the entity.

For details, see 2.5.3 Accept-encoding.

2.7.3 the Content – Language
The Content - Language: useful - CNCopy the code

This header field is used to inform the client of the natural language used by the entity body.

2.7.4 Content – Length
The Content - Length: 15000Copy the code

This header field indicates the size (in bytes) of the entity body.

You cannot use the content-Length header field if you use the content-encoding transfer for the entity body.

2.7.5 Content – the Location
The Content - the Location: http://www.hackr.jp/index-ja.htmlCopy the code

This header field gives the URI corresponding to the packet body. When the page Content returned is different from the actual object requested, the header content-location field specifies the URI.

2.7.6 Content – MD5
Content-MD5: OGFkZDUwNGVhNGY3N2MxMDIwZmQ4NTBmY2IyTY==

Copy the code

The client hashes the received packet body using the MD5 algorithm and compares it with the content-MD5 value to verify the integrity of the received packet body.

The calculation method of the hash algorithm is mainly used to prevent the transmission content from being tampered, because the results obtained after the calculation of the same input through the hash algorithm are the same, and the results obtained after the calculation of different input through the hash algorithm are basically not repeated. This is why many sites that provide resources for download also provide HASH values for resources.

But content-MD5 is unreliable because if the Content of the transport body can be modified, the value of content-MD5 may also have been modified to be unreliable. To ensure that resources are not tampered with, it is best to use HTTPS.

2.7.7 Content – Range
Content-Range: bytes 5001-10000/10000

Copy the code

For a scope request, this header field tells the client which parts of the entity of the response returned comply with the scope request, in bytes.

2.7.8 Content-Type
Content-Type: text/html; charset=UTF-8

Copy the code

This header field specifies the media type within the entity body.

2.7.9 Expires
Expires: Wed, 04 Jul 2012 08:26:05 GMT

Copy the code

This header field tells the client the date when the resource will expire.

If the header field cache-control has a max-age instruction, the max-age instruction is processed first.

2.7.10 Last-Modified
Last-Modified: Wed, 23 May 2012 09:59:55 GMT

Copy the code

This header field indicates when the resource was finally modified.

2.8 is the header field of the Cookie service

The working mechanism of Cookie is user identification and state management.

Header field for cookie service:

Header field name instructions The first type
Set-Cookie Cookie information used to start state management Response header field
Cookie Cookie information received by the server Request header field
2.8.1 Set – cookies

When the server is ready to manage the state of the client, various messages are notified.

The table below lists the field values for set-cookie.

attribute instructions
NAME=VALUE The key and corresponding value assigned to the Cookie
expires=DATE Validity period of Cookie
path=PATH Use the file directory on the server as the appropriate object for cookies (default to the file directory where the document resides if not specified)
Domain = domain name The domain name used as the Cookie object (default if not specified to the domain name of the server that created the Cookie)
Secure Cookies are sent only for SECURE HTTPS communication
HttpOnly Restrict cookies so that they cannot be accessed by JavaScript

The following details the individual properties of cookies.

  • Expires: This property specifies the expiration date when the browser can send a Cookie. When the Expires attribute is omitted, it is only valid for the duration of the browser Session. This is usually limited to before the browser is closed.

    It is also important to note that once a Cookie is sent from the server side to the client, there is no way to explicitly delete the Cookie on the server side. Deletion can only be achieved by overwriting existing cookies.

  • Path: This property is used to restrict the file directory to which cookies are sent. But there are other ways to get around this limitation, so don’t expect too much from it.

  • Domain: The domain name can match the end. For example, if domain is example.com, www.example.com and www2.example.com can also access cookies. Therefore, it is more secure not to specify the domain name, because by default only the domain name of the currently responding server can access the Cookie.

  • Secure: This property restricts the Web page from sending cookies only when an HTTPS secure connection is made. When this property is omitted, the Cookie is accessible to the specified domain name of both HTTP and HTTPS.

  • HttpOnly: This property prevents JavaScript from reading cookies.

2.8.2 cookies
Cookie: status =enable

Copy the code

The header field Cookie tells the server that when the client wants HTTP state management support, it includes the Cookie obtained from the server in the request.

2.9 Other header Fields

HTTP header fields are self-extensible, so there are some non-standard header fields in Web server and browser applications.

Here are some of the more common non-standard header fields:

  • X-Frame-Options
  • X-XSS-Protection
  • DNT
  • P3P
2.9.1 X – Frame – the Options
X-Frame-Options: DENY

Copy the code

This header field belongs to the HTTP response header and is used to control the display of Web content within the Frame tag of other Web sites. Its main purpose is to prevent clickjacking attacks.

Frame labels include iframe, Frame, and Object

This field can specify three types of values:

  • DENY: Refuses to be nested within a Frame, even if the page is under the same domain name
  • SAMEORIGIN: This page can only be embedded in the Frame of the same domain page
  • ALLOW-FROM uri: indicates that a page can be nested within a specified source
2.9.2 X – XSS – Protection

This field belongs to the response header. It is a policy against cross-domain scripting attacks and is used to enable or disable the browser XSS defense mechanism.

The field can be set to two values:

  • 0: Sets XSS filtering to invalid state
  • 1: XSS filtering is set to a valid state
2.9.3 DNT
DNT: 1.Copy the code

The header field belongs to the HTTP request header. DNT is short for Do Not Track, indicating that personal information is refused to be collected.

0 means consent to be tracked and 1 means refusal to be tracked.

2.9.4 P3P

This header field belongs to the response header, which makes personal privacy on the site understandable only by using P3P technology.