7. "Graphic HTTP" - HTTP header and HTTP collaboration server

tjhttp Seven, "Graphic HTTP" - HTTP header and HTTP collaboration server

Knowledge point

1. There are many types of request header fields. This chapter introduces the following headers, which contain a lot of content. It is enough to be familiar with common request headers.

   1. Introduction to header fields
   2. Non-HTTP1.1 header fields
   3. common header
   4. request header
   5. response header
   6. Payload header (entity header)
   7. other header fields
2. Collaboration server refers to some middleware set up for HTTP acceleration access. The content introduction is relatively lacking, and there is no personal supplement. Simply browse

7-1. HTTP headers

Although it is not usually felt, it is something that the Internet uses every day. This book spends more than 50 pages to introduce it, which shows its importance.

The HTTP header consists of three parts, the message header, the blank line and the message body. The message header contains the important transmission information of the client, and the message body is the "load data", which contains the data that needs to be transmitted to obtain the server information.

An HTTP message consists of parts such as method, URI, HTTP version, and HTTP header fields.

The following is the case information of the request message:

 GET / HTTP/1.1
Host: hackr.jp
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20100101 Firefox/13.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*; q=0.8
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

The structure of the response message is as follows:

Response message content:

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

7.0 Introduction to Header Fields

Header fields are an important part of HTTP.

HTTP header field structure

The header field consists of the key/value field name and field value, which are separated by colons. The field value can be a single value or multiple values, and multiple values ​​are separated by commas.

What if the header fields overlap? It is not clearly specified in the specification, depending on how the browser and the implementer handle it. For example, some browsers will prioritize the first header field, while others will prioritize the last header field.

Header field classification

• General Header Fields: Request and response common headers.
• Request Header Fields: The headers used when sending request packets from the client to the server.
• Response Header Fields: The headers used when returning the response message from the server to the client.
• load (entity) Entity Header Fields: The header information used in the payload part, both the client and the server may exist.

HTTP/1.1 header fields

The following are several tables about the header fields, and the four categories corresponding to the classification of the packet header fields:

Common header fields

request header fields

response header fields

payload header field

7.1 Non-HTTP/1.1 header fields

In addition to the header fields used in HTTP protocol communication, the informal header fields are summarized in RFC4229 HTTP Header Field Registrations . If you are interested, you can go directly to the web page to see the relevant white paper information.

Caching proxy behavior

The caching proxy acts through two fields: End-to-end Header and Hop-by-hop Header

For the first end-to-end header (End-to-end Header) will forward the request and response information to the final destination and must be present in the response generated by the cache, the requirement is that it must be forwarded at the same time.

The second Hop-by-hop Header is only valid for a single forwarding, and will not be forwarded if it passes through the cache or proxy. In addition, to use the hop-by-hop header, the Connection header field needs to contain the following:

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

7.2 Generic header fields

The general header field information includes the following:

7.2.1 Cache-Control

As the name implies, the header field used to operate the cache, case Cache-Control: private, max-age=0, no-cache , the cache header field basically has the following values, you need to specify the maximum response age and the maximum valid time of the cache to prevent the cache from being valid for too long and invalid for too short.

The cache request command table and response command reference table are as follows:

public directive (Cache-Control: public)

Cache-Control: public , such a header statement indicates that other users can also use this cache, which means that this is public cache information.

private directive (Cache-Control: private)

Cache-Control: private is the exact opposite of the public command. It can only be used as an object for a specific user. The cache server will cache data for a specific user, and other users do not use this behavior.

no-cache directive (Cache-Control: no-cache)

The purpose is to prevent expired resources from being returned from the cache. Indicates that each request will not accept cached data. If the request carries this instruction, it indicates that the returned content cannot be cached data.

Note ⚠️: Literally, it is easy to misunderstand no-cache as not caching, but in fact no-cache means not caching expired resources. The cache will process the resources after confirming the validity period to the origin server.

Cache-Control: no-cache=Location

If a specific parameter value is specified in cache-Control, the client cannot cache the message after receiving the header corresponding to the specified parameter value. The difference between this instruction is that the server specifies that the client is not allowed to perform caching operations.

Directives that control executable cached objects

no-store directive (Cache-Control: no-store)

​ Indicates that the request or response has confidential information. This directive specifies that the cache MUST NOT store any part of the request or response locally.

s-maxage directive (Cache-Control: s-maxage=604800 (unit: seconds)

​ is the same as the max-age directive. The difference is that the s-maxage directive is only applicable to public cache servers used by multiple users, and it is invalid for the same user to repeatedly respond to this field.

Note ⚠️: After using s-maxage, the Expire field will be ignored.

max-age directive

​ Client: Specify the resource that accepts the maximum cache time. Resources higher than this time do not accept cached data. If it is 0, it means that the source server needs to be requested every time.

max-stale directive (Cache-Control: max-stale=3600 (unit: seconds))

​ max-stale Indicates cached resources, and expires should be accepted as usual. If the command does not specify a parameter value, the client will receive a response. If the specified parameter expires, it can still be received by the client as long as it is within the specified value.

only-if-cached directive (Cache-Control: only-if-cached)

​ Indicates that only the cached resources of the target server are obtained from the cache server. If the cache server has no data, the 504 status code is returned.

504 Gateway Timeout: The server did not receive a response while acting as a gateway or proxy. The difference between 408 and 408 is that 408 is the timeout when the server accepts the client, and 504 is the timeout when the proxy receives the server.

must-revalidate directive (Cache-Control: must-revalidate)

​ Indicates that the proxy will re-verify to the origin server whether the response cache to be returned is still valid. If it is invalid, the cache server is required to return a status code of 504.

Note ⚠️: the must-revalidate directive ignores the request's max-stale directive.

proxy-revalidate directive (Cache-Control: proxy-revalidate)

​ Require all cache servers to verify cache validity before returning a response to a client's request with an instruction.

​

no-transform directive (Cache-Control: no-transform)

​ Requests and responses cannot accept media types that change the payload.

Cache-Control extension cache-extension token Cache-Control: private, community="UCI" This writing method indicates the command to change the header field through token tag extension, such as community This command does not exist, but it is implemented through such an extension compatible. But this compatibility can only be responded by the cache server that understands it, and other cache servers will ignore it directly.

7.2.2 Connection

The role of this header field is as follows:

• Controls which header fields are not forwarded to proxies.
• Manage persistent connections.

Control fields that are no longer forwarded to proxies

​ Controls the header fields that are no longer forwarded to proxies (i.e. Hop-by-hop headers).

Manage persistent connections

If the server side wants to explicitly disconnect the connection, this is done by specifying the value of the Connection header field as Close. However, it should be noted that HTTP1.1 defaults to persistent connections of Keep-Alive .

On the contrary, the previous versions are all non-persistent connections. If you want to achieve the same effect as HTTP1.1, you need Connection:Keep-Alive to complete this operation.

7.2.3 Date (Date: Tue, 03 Jul 2012 04:40:59 GMT)

​ Indicates the date and time when the HTTP message was created.

The HTTP/1.1 protocol will use the date and time format specified in RFC1123 by default:

Date: Tue, 03 Jul 2012 04:40:59 GMT

​ Versions before HTTP 1.1 use the following content, the protocol used is RFC850, and the main content is as follows:

Date: Tue, 03-Jul-12 04:40:59 GMT

​ In addition, there is another way to use the C standard library asctime() 函数 output format is the same:

Date: Tue Jul 03 04:40:59 2012

7.2.3 Pragma (Pragma: no-cache)

Pragma is HTTP/1.1 the historical legacy field of the previous version. For backward compatibility after HTTP1.0, the standard content form exists only, such as the following content: Pragma: no-cache

It is mainly used by the client to inform the server that the cached content is not accepted. This field and Cache-Control：no-cache specify the ideal cache processing.

 Cache-Control: no-cache
Pragma: no-cache

7.2.4 Trailer (Trailer: Expires)

Indicates what header fields are recorded after the body of the message, mainly used for the block transfer encoding of HTTP1.1.

 HTTP/1.1 200 OK
Date: Tue, 03 Jul 2012 04:40:56 GMT
Content-Type: text/html
...
Transfer-Encoding: chunked
Trailer: Expires
...(报文主体)...
0
Expires: Tue, 28 Sep 2004 23:59:59 GMT

The above example uses the Expires field to specify the expiration date of the resource.

7.2.5 Transfer-Encoding (Transfer-Encoding: chunked)

Specifies the encoding method used when transmitting messages. The transfer encoding of HTTP 1.1 can only be used for block transfer encoding.

7.2.6 Upgrade

Indicates an attempt to communicate with the server using a higher version of the protocol, but not necessarily the HTTP protocol, a completely different protocol can be specified.

The example in the book uses the TLS protocol for verification only. Pay attention to the details of the transmission message. For example, if Upgrade is specified in the Connection, the client and the adjacent server can be affected, so you need to specify Connection: Upgrade to take effect.

In addition, the service encounters a request with Upgrade, and can use the return code 101 as the response code to return.

The classic usage scenario of Upgrade is the WebSocket upgrade protocol.

7.2.7 Via

It is mainly used for the request and response message from the final client to the server to the transmission path. When the message passes through the proxy and gateway, the server information will be added to the Via and then forwarded. The header field Via is not only used to track the forwarding of the message, but also to avoid the occurrence of request loopback .

Each time the request passes through the proxy server, the Via field in the header will increase once. The VIa field is used to track the propagation path. It is usually used with the TRACE method. If Max-Forward becomes 0, The forwarding operation between proxy servers is stopped.

7.2.8 Warning

The Warning header of HTTP/1.1 is evolved from the response header (Retry-After) of HTTP/1.0.

The following is the corresponding composition format:

 Warning: [警告码][警告的主机:端口号]“[警告内容]”([日期时间])

Seven warning codes are defined in HTTP 1.1. Warning codes are usually only for reference and may be extended later.

7.3 Request header fields

Request headers are fields that the client passes to the server.

7.3.1 Accept (Accept: text/html,application/xhtml+xml,application/xml;q=0.)

The header field informs the server of the media types that the user agent can handle and the relative priority of the media types.

• text file

  • text/html, text/plain, text/css ...
  • application/xhtml+xml, application/xml ...

• image file

  • image/jpeg, image/gif, image/png ...

• video file

  • video/mpeg, video/quicktime ...

• Binaries used by the application

  • application/octet-stream, application/zip ...

Case:

For example, use type/subtype in this form to specify multiple media types at one time, and specify the weight value through q=？ . The default weight is 1, and the weight can be set to three decimal places. Assuming that the server can provide multiple kinds of information at one time, the media type data with the highest weight value will be provided first.

7.3.2 Accept-Charset (Accept-Charset: iso-8859-5, unicode-1-1; q=0.8)

The main function is to notify the server of the character set supported by the user agent and the relative priority of the character set. Same as the header field Accept, the weight q value can be used to represent the relative priority.

The main role of this field is the server-driven negotiation of the content negotiation mechanism.

7.3.3 Accept-Encoding (Accept-Encoding: gzip, deflate)

The main function is to inform the server of the request encoding and priority order supported by the user agent, and support to specify multi-level encoding at one time. The relevant cases of encoding are as follows:

gzip : The encoding format (RFC1952) generated by the file compression program gzip (GNU zip), using the Lempel-Ziv algorithm (LZ77) and 32-bit cyclic redundancy check (Cyclic Redundancy Check, commonly known as CRC).

compress : The encoding format generated by the UNIX file compression program compress, using the Lempel-Ziv-Welch algorithm (LZW).

deflate : Combines the zlib format (RFC1950) and the encoding format generated by the deflate compression algorithm (RFC1951).

identity : The default encoding format that does not perform compression or changes.

Note that you can also use q=? to represent the weight value, the meaning is the same as the effect of Accept, and finally pay attention to use the * number as a wildcard.

7.3.4 Accept-Language (Accept-Language: zh-cn,zh;q=0.7,en-us,en;q=0.3)

The main function is to inform the server of the natural language set supported by the user agent and the priority order, and support to specify multiple language levels at one time.

You can also use q=? Indicates the weight value, and returns the final supported language set according to the supported languages ​​as the result.

7.3.5 Authorization (Authorization: Basic dWVub3NlbjpwYXNzd29yZA==)

Like the name, the main function is to inform the server of user authentication information. This request header is often used for interface docking and development. Usually, a 401 return code will be returned for users who do not have permission to inform that they do not have permission to access the server.

7.3.6 Expect (Expect: 100-continue)

The client tells the server to use some desired behavior, but if the server doesn't understand the client's response, it will return 417. Clients use this field to indicate their expectations. But HTTP1.1 actually only specifies Expect: 100-continue , which means that clients whose status code response is 100 need to specify this field.

417 means the expectation failed

The purpose of designing the 100 (Continue) HTTP status code in the HTTP/1.1 protocol is that before the client sends the Request Message, the HTTP/1.1 protocol allows the client to determine whether the server is willing to accept the message body sent by the client (based on Request Headers). ).

The main situation is that if the client wants to pass a data packet to the server, but if the server cannot process it or refuses to process it, this field is similar to a notification in advance.

The meaning of this field is actually to add "state" to HTTP1.X, but this state cannot be regarded as a standard in a strict sense, so HTTP1.X is still stateless.

7.3.7 From

Represents the email address of the user agent. Note that sometimes the email address is recorded in the User-Agent header field because of the proxy.

7.3.8 Host (Host: www.hackr.jp )

The Host header field is the only header field in the HTTP/1.1 specification that MUST be included in a request.

Indicates the IP address and port number of the requester.

Why is the Host header necessary? This is closely related to the working mechanism of virtual hosting in which a single server assigns multiple domain names.

7.3.9 If-Match

In this way, the request header fields with the prefix If are all conditional requests. After the server receives the attached conditions, it needs to judge as true before executing the request.

As shown in the figure above, the server will only accept the request when the values ​​of if-match and Etag match, and return a response status code of 412 if they do not match. In addition, you can use an asterisk to ignore the value of Etag , and accept it as long as there are resources.

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

If the resource is later than the time specified by this field, it is hoped that the server can process the resource request, otherwise, if the resource time has not changed, a 304 response needs to be returned.

If-Modified-Since is used to confirm the validity of a local resource owned by a proxy or client .

7.3.11 If-None-Match

Contrary to If-Match Etag ---, the request is processed only when the value of If-None-Match is different from the value of ---43eced0d981210034eabec85d8c5da30---. This method is used in GET and HEAD requests Get real-time information, similar to the header field If-Modified-Since .

7.3.12 Proxy-Authorization (Proxy-Authorization: Basic dGlwOjkpNLAGfFY5)

The challenge request returned by the proxy server includes the authentication of the client, which is similar to the HTTP authentication between the client and the server.

7.3.13 Range (Range: bytes=5001-10000)

The first Range can tell the server to specify the range of resources, and the above bytes contain the resource content of 5001 to 10000 bytes.

If the relevant request can be processed, it will return a response of 206 Partial Content , if not, it will return 200 normally.

206 Partial Content: The server only sent part of the resource.

7.3.14 Referer (Referer: http://www.hackr.jp/index.htm )

The Referer header field tells the server the URI of the original resource requested.

Note that the URL of the original resource may contain some sensitive information such as ID and password. If it is written to Reffer and passed to other servers, it may be leaked.

The correct spelling of Referer should be Referrer, probably because Lao Mei thought the word was more difficult to read when it was originally designed.

7.3.15 TE (TE: gzip, deflate; q=0.5)

Indicates the encoding method and priority that the server client can handle the response, similar to the Accept-Encoding field, but mainly used for transfer encoding. You can also specify TE: trailers for chunked transfer encoding.

7.3.16 User-Agent (User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;)

User-Agent is used to convey the type of browser, and the header field will transmit the browser and user agent information to the server for processing.

7.4 Response header fields

The response header field refers to the header used when returning a response message from the server to the client.

7.4.1 Accept-Ranges (Accept-Ranges: bytes)

When the range request cannot be processed, you need to specify Accept-Ranges: none

It mainly informs the client of the request range that the server can handle, such as specifying bytes to process bytes.

7.4.2 Age (Age: 600)

Indicates how long ago the origin server created the response, the field value is seconds. If a responsive cache server is created, this time is the time from when the Age caches the response and initiates the authentication again until the authentication is completed. The proxy server needs to add the header field Age .

7.4.3 ETag (ETag: "82e22293907ce725faf67773957acd12")

A payload flag that tells the client, in a way that uniquely identifies the resource as a string. The server will assign Etag to each resource. In addition, it should be noted that the resource update needs to be kept updated as Etag .

So Etag is used to distinguish accesses with the same URI but different languages ​​to distinguish different access resources, in addition Etag there are strong and weak points, strong Etag will be in the resource When it is changed, it will be refreshed immediately, and the weak Etag W/ be added to the resource header after the resource change to identify the resource change.

7.4.4 Location (Location: http://www.usagid ...)

Used to indicate that the recipient of the response is directed to a resource at a different location from the request URL. It will also cooperate with 3xx Redirction to redirect and return. Almost all browsers will try to complete the behavior of resource redirection when they receive this field.

7.4.5 Proxy-Authenticate (Proxy-Authenticate: Basic realm="Usagidesign Auth")

The header field Proxy-Authenticate will be sent to the client through the authentication information required by the proxy server. Note that it is different from the HTTP access authentication between the server and the client, which is the authentication between the proxy server and the client.

7.4.6 Retry-After (Retry-After: 120)

This field indicates how long after the request can be retried, used with status code 503, or used with 3XX Redirect. The field value can be a number, a specific datetime, or the number of seconds since the response was created.

7.4.7 Server (Server: Apache/2.2.17 (Unix))

Notifies the client of the application information of the current server, which may include software version number information, etc.

7.4.8 Vary (Vary: Accept-Language)

Indicates that when the specified resource request is used, if the content of the Accept-language field is the same, the response will be returned directly from the cache, otherwise it needs to be returned only from the origin server.

Therefore, this field is suitable for controlling the cache, and the origin server will pass the local cache usage method and calling command to the proxy server.

If you want to get the cache, you need to get it with the request specified by the field content of Vary , so even if this request is exactly the same as the previous one, as long as the Vary of the request is inconsistent, it still needs to be obtained from the origin server.

7.4.9 WWW-Authenticate (WWW-Authenticate: Basic realm="Usagidesign Auth")

It is mainly used for HTTP access authentication, and informs the client of the authentication method suitable for accessing the specified resource of the request. If a 401 response code is returned, this field will be returned together. Note that the case here Basic realm="Usagidesign Auth" is used to indicate the protection policy of the resource.

401 Unauthorized: The client needs authorization to access the requested resource. The response content needs to include www-Authnticate header information and query information, if there is already a certificate access or 401 indicating that the certificate has not been accepted, if the 401 is the same as the previous authentication request, and the browser has performed at least one re-authentication. test, the browser should display entity information (ie, diagnostic information) contained in the response.

7.5 Payload header fields

Because of the new protocol of HTTP 2.0, we want to call it the payload header here, and the concept of the entity header has been abandoned. The payload header indicates the request header information of the entity content, which can be considered as the cargo information of the express list on the express delivery.

7.5.1 Allow (Allow: GET, HEAD)

​ Notifies the client of all HTTP methods for the specified resource. A 405 response will be returned if it is not supported.

405 Method Not Allowed : The server has received and recognized the request, but rejected the specific request method. The response MUST return an Allow header indicating the list of request methods that the current resource can accept.

 对于一些修改服务器资源数据的请求方法比如PUT和DELETE通常不被允许。

7.5.2 Content-Encoding (Content-Encoding: gzip)

Indicates the content encoding method used by the server for the body of the payload, and compresses it without losing content.

The main supported encoding methods are as follows:

• gzip
• compress
• deflate
• identity

7.5.3 Content-Language (Content-Language: zh-CN)

Tells the client the language principal used by the server.

7.5.4 Content-Length (Content-Length: 15000)

Tells the entity body part size (in bytes), but this field cannot be used once it is transmitted using content encoding.

Please refer to 4.4 of https://tools.ietf.org/html/rfc7231 for the content length calculation of the encoding format.

7.5.5 Content-Location (Content-Location: http://www.hackr.jp/index-ja.html )

Given the URI corresponding to the payload part of the message, this field indicates the URI corresponding to the resource returned by the payload of the message.

For example, the actual URI that appears in the Accept-Language field may be different from the returned URI, so it needs to be marked in this field.

7.5.6 Content-MD5 (Content-MD5: OGFkZDUwNGVhNGY3N2MxMDIwZmQ4NTBmY2IyTY==)

The client performs MD5 encryption on the content of the received packet payload to ensure the integrity of the packet during transmission.

However, it should be noted that Base64 encryption is also required after MD5 encryption of the message payload, because the HTTP header cannot record the binary content. When the message is accepted, the MD5 algorithm is also used to decrypt it, and the content of the payload is verified for integrity.

However, it should be noted that this field cannot verify whether the MD5 encryption has been tampered with while verifying the integrity, so the security guarantee is not good.

7.5.7 Content-Range (Content-Range: bytes 5001-10000/10000)

Tell the client which part of the payload returned as a response matches the range request, and which part matches the request. The unit of the field value is bytes, indicating the current sending part and the entire entity size.

7.5.8 Content-Type (Content-Type: text/html; charset=UTF-8)

Indicates the media type of the object in the payload body, which is the same as the header field Accept , and the field value is assigned in the form of type/subtype .

The parameter charset is assigned a character set such as iso-8859-1 or euc-jp .

7.5.9 Expires

The header field Expires informs the client of the date the resource will expire. If you don't want the resource to be cached, the header field is the same as the header field Date.

It should be noted that when the Cache-Control specifies the max-age command, the max-age processing will be prioritized over the header field Expires .

7.5.10 Last-Modified (Last-Modified: Wed, 23 May 2012 09:59:55 GMT)

Last-Modified indicates the time when the resource is finally modified, and actually passes Request-URI indicates the time when the resource is modified. The practical case is that it is possible to change this time when using CGI for dynamic data processing.

7.6 Header fields of the Cookie service

Although Cookie is not a specification of HTTP1.1, it is widely used in the WEB field. The basic function of cookies is to save the user's access information and state management. At the same time, writing some data to the client can simplify user operations during the next visit and reduce some pressure on the server.

7.6.1 Cookies (Cookie: status=enable)

This header field will inform the server that it wants to obtain HTTP status support management. At this time, the request will contain multiple cookies and can be sent as cookies.

For officially released cookies, since the validity period, sender's domain name and path, protocol information, etc. can be verified, it is relatively safe from external attacks.

By the way, let’s talk about the history of cookies. Cookies were originally developed and standardized by Netscape, but the following protocol specifications appeared in the subsequent development:

• Netscape Standard (de facto standard)

  Released around 1994, the current popular standard is basically the template at this time. Netscape's standard is determined by a 5-page paper written by a 24-year-old god. At present, I can't find any relevant specification links. You can refer to RFC6265 to see some Initial clues.

• RFC2109 (Mr. No. 1)

  Surprisingly, this is a standard issued by the W3C. The original intention is to be compatible with the standard formulated by Netscape (in fact, it wants to replace it), but because the standard is too strict, and many service implementers implement this standard incorrectly, it is still later. Changed back to Netscape's standard.

  • RFC 2109 - HTTP State Management Mechanism (ietf.org)
  • https://www.w3.org/Protocols/rfc2109/rfc2109.txt

• RFC2965 (No. 2 in trouble)

  RFC2965 defines Cookie2 and attempts to address the shortcomings of RFC2109 regarding Cookie1. RFC2965 aims to replace RFC2109.

  Servers sending RFC2965 cookies will use the Set-Cookie2 header in addition to the Set-Cookie header. Note that RFC2965 cookies are very port sensitive.

  RFC2965 is available at http://www.w3.org/Protocols/rfc2965/rfc2965.txt , but it actually belongs to the W3C black history and was deleted,

  Finally passed: RFC 2965 - HTTP State Management Mechanism (ietf.org) can be read to understand

  Unfortunately, the W3C was still unsuccessful, as few servers were put into use.

• RFC6265: W3C finally gave up the competition for the standard. RFC6265 is the product of redefining the standard according to Netscape's standard, and finally becomes the de facto standard in the industry. (Inherit the big brother, unify everything)

  But the result is still not using any one of the RFC protocol, the standard of Netscape.

  From the results, we can think that RFC6265 is a standard that is implemented first and then supplemented with design documents. Although RFC6265 is not an actual standard, it is a standard that is publicly recognized by the white paper. The distinction between black and white standards.

  RFC 6265 - HTTP State Management Mechanism (ietf.org)

  Tucao: Therefore, the standard that meets the market can be accepted by the public. Even a huge organization like the W3C cannot shake a recognized standard.

Finally, I would like to thank the IETF, which can be said to be the library of the Internet and the cornerstone of the development of the Internet. In addition, some black histories of RFC that were covered up by W3C were also found, haha.

The IETF is self-organized and self-managed by netizens. Anyone can participate. It is completely democratic and equal, and has no voting mechanism. It fully reflects the spirit of freedom, openness, cooperation and sharing.

The style of the first field of the cookie is as follows:

7.6.2 Set-Cookie

The basic format is as follows, some preparations before starting to use cookies:

 Set-Cookie: status=enable; expires=Tue, 05 Jul 2011 07:26:31

The basic field properties are as follows:

expires attribute : the validity period of the sent cookie, the default is the session level of the session, that is, a browser access. In addition, it should be noted that once the cookie is created on the server, it cannot be deleted casually, and the cookie information of the client can only be rewritten by overwriting.

path attribute : Restricts the sending scope directory of the specified cookie, but there is actually a way to bypass this restriction, so this attribute is not a security attribute.

domain attribute : It is safer to not specify this attribute by checking the end of the domain, because this attribute is similar to a whitelist to allow multiple domain access.

secure attribute (Set-Cookie: name=value; secure): Restricts sending cookies only on HTTPS connections. It is a relatively secure attribute, which means that cookies will be sent when the same domain name is using HTTPS, but instead of HTTP does not overwrite the client's cookie. On the other hand not specifying this property means that no recycling behavior will occur.

7.6.3 HttpOnly attribute

Introduction: It belongs to the extension function of Cookie itself, which is used to prevent JS script from stealing cookie information, that is, to prevent XSS attacks.

Declaration method:

 Set-Cookie: name=value; HttpOnly

After passing such a declaration, the JavaScript of document.cookie cannot read the 0add5487b of the Cookie of the attached HttpOnly .

In fact, the extension of HttpOnly was not invented to prevent XSS attacks, but it was widely used as an important means to mitigate XSS attacks.

An XSS attack looks like the script below:

 http://example.jp/login?ID="> <script>var+f=document.getElementById("login");+f.action="h </script><span+s=" 对请求时对应的HTML源代码（摘录）

7.6.4 Cookies (Cookie: status=enable)

The header field Cookie tells the server that when the client wants HTTP state management support, it will include the cookie received from the server in the request. Cookies can be sent more than one.

7.7 Other header fields

Other header fields are also supported by HTTP for open extensions. These fields do not conform to WEB standards and need to be decided by the implementer, but the frequency of use is not low.

7.7.1 X-Frame-Options

This field is the content of the response header. The main function is to control the display content of the Frame tag, mainly to prevent the attack method of clickjacking.

The optional contents are the following two

• DENY: Denied
• SAMEORIGIN: Same Origin Page Match License.

Mainstream browsers basically already support this field. The following is a reference for Apache:

 <IfModule mod_headers.c>
Header append X-FRAME-OPTIONS "SAMEORIGIN"
</IfModule>

7.7.2 X-XSS-Protection (X-XSS-Protection: 1)

The header field X-XSS-Protection belongs to the HTTP response header, and its main function is to control the switch of the browser's XSS protection mechanism.

grammar:

 X-XSS-Protection: 0
X-XSS-Protection: 1
X-XSS-Protection: 1; mode=block
X-XSS-Protection: 1; report=<reporting-uri>

Logo Explanation:

• 0: Disable XSS filtering.
• 1: Enable XSS filtering (usually browser default). If a cross-site scripting attack is detected, the browser will clear the page (remove unsafe parts).
• 1;mode=block to enable XSS filtering. If an attack is detected, the browser will not clear the page, but will prevent the page from loading.
• 1; report=<reporting-URI> (Chromium only) to enable XSS filtering. If a cross-site scripting attack is detected, the browser will clear the page and send a violation report using the capabilities of the CSP report-uri (en-US) directive.

7.7.2 DNT

DNT is an HTTP request header, short for Do Not Track , which is mainly used to prevent ads from grabbing personal information.

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

Here is a useful Google plugin "Ublock origin" , the icon resembles a small red shield.

The biggest feature can use the html element to directly erase the advertisement information filter element of the page, which is very easy to use.

7.7.3 P3P

P3P (The Platform for Privacy Preferences, online privacy preference platform) technology, through this header, can turn private information into a way to identify only the application.

The steps to create P3P are as follows:

Step 1: Create P3P Privacy.

Step 2: After creating the P3P privacy comparison file, save it and name it in /w3c/p3p.xml.

Step 3: After new Compact policies from P3P Privacy, output to HTTP response.

About P3P can continue to read the following content:

The Platform for Privacy Preferences 1.0 (P3P1.0) Specification http://www.w3.org/TR/P3P/

X-prefix deprecation: Use this prefix to check out non-standard parameters, and use it as an extension of non-standard parameters in turn, but in actual use, it is found that this not only leads to confusion in naming, but also may affect normal communication, so in the follow-up " RFC 6648 - Deprecating the "X-" Prefix and Similar Constructs in Application Protocols " obsolete this usage.

7-2. HTTP Collaboration Server

7.1 Multiple domain names for a single virtual machine

HTTP1.1 supports the server to build multiple sites and provides WEB hosting services, and the mapping and lookup of domain names and IPs involves DNS. The domain name needs to be parsed through DNS before it can be accessed. When the request is sent to the server, it already uses the IP way too.

7.2 Communication forwarding procedure

There are several professional terms for communication forwarding: proxy, gateway, and tunnel. The following are to distinguish their concepts one by one.

Proxy: The proxy acts as a "middleman" between the server and the client. The basic behavior of the proxy server is to receive the request sent by the client and forward it to other servers. The role of the proxy is usually to speed up the access to the target site or use it as a springboard.

Gateway: A server responsible for forwarding the communication data of other servers. It is similar to a microphone for its own position. It is responsible for transmitting the "words" of one server to another server, so the server that sends the request itself will also be regarded as the forwarded server. .

Tunnel: An application that guarantees the transfer of clients and servers over long distances.

7.2.1 Proxy

The main change information of the proxy is in the Via header information . Each proxy forwarding needs to add forwarding information in the Via header. The specific information is as follows:

For proxies, they are divided into transparent proxies and cache proxies according to whether to modify packets and whether to cache data.

• Transparent proxy : Transparent proxy refers to a proxy method that does not do any processing on request packets.
• Cache proxy : A cache proxy usually exists on a cache server. The proxy caches the data to the cache server before forwarding the response, and then returns it to the client.

7.2.2 Cache server

The role of the cache server is to reduce the burden on the server. By using the cache, the same resources can be prevented from being repeatedly returned from the source server, and resources can be obtained directly from the cache server. This part of the content is described in detail in the book "How the Network is Connected".

7.2.3 Tunnel

The tunnel can establish a communication line with other servers as required, and then use encryption methods such as SSL to communicate.

Protocols that came before HTTP

• FTP: It is earlier than the appearance of the TCP/IP protocol family. Although it is surpassed by HTTP, it is still widely used for file uploading.
• NNTP (Network News Transfer Protocol): A protocol for transferring messages in NetNews electronic conference rooms.
• Archie: A protocol for searching file information exposed by anonymous FTP.
• WAIS (Wide Area Information Servers): A protocol used to search multiple databases by keyword.
• Gopher: A protocol for finding information within computers connected to the Internet.