Hyper Text Caching Protocol
Earlier, we discussed ICP, a protocol that allows proxy caches to query siblings about the presence of documents. ICP, however, was designed with HTTP/0.9 in mind and therefore allows caches to send just the URL when querying a sibling about the presence of a resource. Versions 1.0 and 1.1 of HTTP introduced many new request headers that, along with the URL, are used to make decisions about document matching, so simply sending the URL in a request may not result in accurate responses.
The Hyper Text Caching Protocol (HTCP) reduces the probability of false hits by allowing siblings to query each other for the presence of documents using the URL and all of the request and response headers. Further, HTCP allows sibling caches to monitor and request the addition and deletion of selected documents in each other's caches and to make changes in the caching policies of each other's cached documents.
Screenshot 20-13, which illustrates an ICP transaction, also can be used to illustrate an HTCP transaction-HTCP is just another object discovery protocol. If a nearby cache has the document, the requesting cache can open an HTTP connection to the cache to get a copy of the document. The difference between an ICP and an HTCP transaction is in the level of detail in the requests and responses.
The structure of HTCP messages is illustrated in Screenshot 20-15. The Header portion includes the message length and message versions. The Data portion starts with the data length and includes opcodes, response codes, and some flags and IDs, and it terminates with the actual data. An optional Authentication section may follow the Data section.
(Screenshot 20-15.)
Details of the message fields are as follows:
Header
The Header section consists of a 32-bit message length, an 8-bit major protocol version, and an 8-bit minor protocol version. The message length includes all of the header, data, and authentication sizes.
Data
The Data section contains the HTCP message and has the structure illustrated in Screenshot 20-15. The data components are described in Table 20-6.
Table 20-6. HTCP data components | |
| Component | Description |
| Data length | A 16-bit value of the number of bytes in the Data section including the length of the Length field itself. |
| Opcode | The 4-bit operation code for the HTCP transaction. The full list of opcodes is provided in Table 20-7. |
| Response code | A 4-bit key indicating the success or failure of the transaction. The possible values are:
· 0-Authentication was not used, but is needed · 1-Authentication was used, but is not satisfactory · 2-Unimplemented opcode · 3-Major version not supported · 4-Minor version not supported · 5-Inappropriate, disallowed, or undesirable opcode |
| F1 | F1 is overloaded-if the message is a request, F1is a 1-bit flag set by the requestor indicating that it needs a response (F1=1); if the message is a response, F1 is a 1-bit flag indicating whether the response is to be interpreted as a response to the overall message (F1=1) or just as a response to the Opcode data fields (F1=0). |
| RR | A 1-bit flag indicating that the message is a request (RR=0) or a response (RR=1). |
| Transaction ID | A 32-bit value that, combined with the requestor's network address, uniquely identifies the HTCP transaction. |
| Opcode data | Opcode data is opcode-dependent. See Table 20-7. |
Table 20-7 lists the HTCP opcodes and their corresponding data types.
Table 20-7. HTCP opcodes | ||||
| Opcode | Value | Description | Response codes | Opcode data |
| NOP | 0 | Essentially a "ping" operation. | Always 0 | None |
| TST | 1 | 0 if entity is present, 1 if entity is not present | Contains the URL and request headers in the request and just response headers in the response | |
| MON | 2 | 0 if accepted, 1 if refused | ||
| SET | 3 | The SET message allows caches to request changes in caching policies. See Table 20-9 for a list of the headers that can be used in SET messages. | 0 if accepted, 1 if ignored | |
| CLR | 4 | 0if I had it, but it's now gone; 1 if I had it, but I am keeping it; and 2 if I didn't have it | ||
HTCP Authentication
The authentication portion of the HTCP message is optional. Its structure is illustrated in Screenshot 20-15, and its components are described in Table 20-8.
Table 20-8. HTCP authentication components | |
| Component | Description |
| Auth length | The 16-bit number of bytes in the Authentication section of the message, including the length of the Length field itself. |
| Sig time | A 32-bit number representing the number of seconds since 00:00:00 Jan 1, 1970 GMT at the time that the signature is generated. |
| Sig expire | A 32-bit number representing the number of seconds since 00:00:00 Jan 1, 1970 GMT when the signature will expire. |
| Key name | A string that specifies the name of the shared secret. The Key section has two parts: the 16-bit length in bytes of the string that follows, followed by the stream of uninterrupted bytes of the string. |
| Signature | The HMAC-MD5 digest with a B value of 64 (representing the source and destination IP addresses and ports), the major and minor HTCP versions of the message, the Sig time and Sig expires values, the full HTCP data, and the key. The Signature also has two parts: the 16-bit length in bytes of the string, followed by the string. |
Setting Caching Policies
The SET message allows caches to request changes in the caching policies of cached documents. The headers that can be used in SET messages are described in Table 20-9.
Table 20-9. List of Cache headers for modifying caching policies | |
| Header | Description |
| Cache-Vary | The requestor has learned that the content varies on a set of headers different from the set in the response Vary header. This header overrides the response Vary header. |
| Cache-Location | The list of proxy caches that also may have copies of this object. |
| Cache-Policy | The requestor has learned the caching policies for this object in more detail than is specified in the response headers. Possible values are: "no-cache," meaning that the response is not cacheable but may be shareable among simultaneous requestors; "no-share," meaning that the object is not shareable; and "no-cache-cookie," meaning that the content may change as a result of cookies and caching therefore is not advised. |
| Cache-Flags | The requestor has modified the object's caching policies and the object may have to be treated specially and not necessarily in accordance with the object's actual policies. |
| Cache-Expiry | The actual expiration time for the document as learned by the requestor. |
| Cache-MD5 | The requestor-computed MD5 checksum of the object, which may be different from the value in the Content-MD5 header, or may be supplied because the object does not have a Content-MD5 header. |
| Cache-to-Origin | The requestor-measured round-trip time to an origin server. The format of the values in this header is <origin server name or ip> <average round-trip time in seconds> <number of samples> <number of router hops between requestor and origin server>. |
By allowing request and response headers to be sent in query messages to sibling caches, HTCP can decrease the false-hit rate in cache queries. By further allowing sibling caches to exchange policy information with each other, HTCP can improve sibling caches' ability to cooperate with each other.