HTCP/0.0 超文本缓存协议( 四 )


REQ-HDRS 这些标题是由HTTP发起者提供的 。它们应包括端对端标题(end-to-end),而不是hop-by-hop标题,并且可以将它们标准化(例如:答应有“Accept:”集成 。)
3.3. DETAIL域用于TST响应消息,定义如下 。它的格式:
---------------------
RESP-HDRS: COUNTSTR
---------------------
ENTITY-HDRS: COUNTSTR
---------------------
CACHE-HDRS: COUNTSTR
---------------------
3.4. IDENTITY 用于MON请求消息和SET响应消息,其定义如下 。格式为:
---------------------
SPECIFIER
---------------------
DETAIL
---------------------
4. 缓冲标题
HTCP/0.0的 CACHE-HDRS字段是由零个或者多个下面列出来的标题组合而成的:
Cache-Vary: < header-name> ...
标题的发送端知道其内容会随着一组不同于在对象的Vary: header标题中给定的那一组的标题而变化 。假如有Cache-Vary:的话,对象的Vary: header就会失效 。
Cache-Location: : ...
标题的发送端知道有一个以上的代理缓冲区保留了一份儿此对象的拷贝 。使用HTCP探测这些缓冲区,可能会发现新的、距离近的(亦即当前更好的选择)HTCP“邻居” 。
Cache-Policy: [no-cache] [no-share] [no-cache-cookie]
标题的发送端知道此对象的缓存策略中有比在它的响应标题中所给出的更多的具体资料 。
no-cache 意思为它不可以缓冲(未给出原因),但是在同一时间里发生的请求间可共享 。
no-share 意思为它不可以缓冲(未给出原因),且通常需要每请求隧道 。
no-cache-cookie 意思为一个不同的、被遗漏的或者甚至是随机的cookies被包含在请求标题中的效果是其内容会变化,并且那个缓冲是不可取的 。
Cache-Flags: [incomplete]
标题的发送端修改了本地对象的缓冲策略,因此请求者可能需要非凡地处理这个响应,也就是说,并非必须要与对象的策略完全一致 。
incomplete e 意思是不知道在此响应中的响应标题和/或实体标题是否是完整的,而且可能不适合用作缓冲要害字 。
Cache-Expiry:
标题的发送端知道假如时间与此对象的响应标题中指示的时间不同的话,就应认为它已经过期了 。其格式与HTTP/1.1 Expires完全相同 。
Cache-MD5:
标题的发送端已为此对象计算了MD5检验和,它若与在对象的Content-MD5: header给定不一样,就会被提供的,因为此对象没有Content-MD5标题 。其格式与HTTP/1.1 Content-MD5: 完全相同 。
Cache-to-Origin:
标题的发送端已经估算了到源服务器(当作一主机名或者是文字地址)往返所需的时间 。是平均所需的秒数,用一个十进制的任意精度的、且没有指数的ASCII码表示 。是缓冲区与源数据两者之间的路由器数,用一个十进制的任意精度的、且没有指数的ASCII码表示,假如缓冲区未知则为0 。
6. HTCP 操作
HTCP/0.* 的操作编码(OPCODES)和它们的各自OP-DATA 数据定义如下:
6.1. NOP (OPCODE 0):
这是HTCP标准的“ping” 。响应者被激发,在最短的延迟时间内执行NOP指令,相应地,请求者会用NOP RTT(一个NOP回合的时间,round trip time)来配置或者映象之用 。NOP的 RESPONSE (响应)代码通常都是零(0),而且它没有 OP-DATA 数据 。若RD=0,NOP请求根本就不引起任何处理 。
6.2. TST (OPCODE 1):
测试在代理缓冲区中是否有特定内容的实体存在 。若RD=0,NOP请求根本就不引起任何处理 。
TST请求的OP-DATA数据如下:
0 (MSB)1 (LSB)
--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
0:
/ SPECIFIER /
/ /
--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---

推荐阅读