D.2 HTCP Data Types

only for RuBoard - do not distribute or recompile

HTCP messages are built on a simple hierarchy of data types. I'll start with the most simple and finish with the complex ones.

D.2.1 COUNTSTR

A COUNTSTR is a string of ISO8859-1 (Latin-1) characters preceded by the length of the string. The string length is encoded (in network byte order) using two octets. The string is not necessarily null- terminated . For example, the following hexadecimal values encode the string "Cache" as a COUNTSTR:

 00 05 43 61 63 68 65     5  C  a  c  h  e

D.2.2 SPECIFIER

Figure D-5. HTCP SPECIFIER format

A SPECIFIER, shown in Figure D-5, encodes an HTTP request using four COUNTSTRs. It is used in TST, SET, and CLR requests , and in MON responses. METHOD, URL, and VERSION are all taken from the first line of an HTTP request. REQ-HDRS consists of all the remaining request headers.

D.2.3 DETAIL

Figure D-6 shows the DETAIL type, which is used in TST response messages. It provides the information about a cached response. These are all HTTP-style headers with CRLF line termination. RESP-HDRS is the set of HTTP response headers, as defined in Section 6.2 of RFC 2616. These include Etag , Age , and others. ENTITY-HDRS is the set of HTTP headers defined in Section 7.1 of RFC 2616. These include Expires , Last-modified , and others. CACHE-HDRS, on the other hand, are defined by HTCP, rather than HTTP. They are used to convey additional information about a resource that may prove to be useful. For example, the Cache-Location header is a list of other proxy caches that are likely to hold a copy of the object. Refer to Section 4 of RFC 2756 for the full details.

Figure D-6. HTCP DETAIL format

D.2.4 IDENTITY

As you can see in Figure D-7, IDENTITY is just a combination of SPECIFIER and DETAIL. It is used for the MON and SET opcodes.

Figure D-7. HTCP IDENTITY format

only for RuBoard - do not distribute or recompile