rfc2756.txt

本程序为在linux下实现FTP传输文件的实现

      no-cache          意思为它不可以缓冲(未给出原因)，但是在同一时间里发生的请求间可共享。

no-share          意思为它不可以缓冲(未给出原因)，且通常需要每请求隧道。

no-cache-cookie   意思为一个不同的、被遗漏的或者甚至是随机的cookies被包含在请求标题中的效果是其内容会变化，并且那个缓冲是不可取的。

   Cache-Flags: [incomplete]
      标题的发送端修改了本地对象的缓冲策略，因此请求者可能需要特别地处理这个响应，也就是说，并非必须要与对象的策略完全一致。

      incomplete   e    意思是不知道在此响应中的响应标题和/或实体标题是否是完整的，而且可能不适合用作缓冲关键字。

   Cache-Expiry: <date>
      标题的发送端知道如果时间与此对象的响应标题中指示的时间不同的话，就应认为它已经过期了。其格式与HTTP/1.1 Expires完全相同。

   Cache-MD5: <discovered content MD5>
      标题的发送端已为此对象计算了MD5检验和，它若与在对象的Content-MD5: header给定不一样，就会被提供的，因为此对象没有Content-MD5标题。其格式与HTTP/1.1 Content-MD5: 完全相同。

   Cache-to-Origin: <origin> <rtt> <samples> <hops>
      标题的发送端已经估算了到源服务器（当作一主机名或者是文字地址）往返所需的时间。<rtt>是平均所需的秒数，用一个十进制的任意精度的、且没有指数的ASCII码表示。<Hops>是缓冲区与源数据两者之间的路由器数，用一个十进制的任意精度的、且没有指数的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                            /
      /                                                               /
      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

    TST的RESPONSE（响应）编码如下：

   0   实体在响应者的缓冲区内
   1   实体不在响应者的缓冲区内

   如果RESPONSE（响应）为零（0）TST响应有如下所示的OP-DATA数据：

                 +0 (MSB)                            +1 (LSB)
      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   0: |                                                               |
      /                             DETAIL                            /
      /                                                               /
      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

   注意:  由某一确定的TST返回的响应标题可能会是一个过期的对象。请求者对这一情况应有足够的应付准备，可以采用将响应者当作此对象的资料来源（这会引起响应者完全地刷新此对象），或者选择另外一个不同响应者的方法。

   如果RESPONSE（响应）为一（1）TST响应有如下所示的OP-DATA数据：

                 +0 (MSB)                            +1 (LSB)
      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   0: |                                                               |
      /                           CACHE-HDRS                          /
      /                                                               /
      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

   6.3. MON (OPCODE 2):

    在代理存储器的本地对象仓库内监视器的活动（添加，删除，替换，等等）。因为不支持在一对UDP端点间插入HTCP交易，所以建议由请求者为每一个与其同时发出的MON请求分配一个特定的UDP端点。RD＝0的MON请求与那些RD＝1且TIME＝0的MON请求是等价的，也就是说，它们将会取消所有未完成的MON交易。

   MON请求有如下OP-DATA数据结构：

                  +0 (MSB)
      +---+---+---+---+---+---+---+---+
   0: |             TIME              |
      +---+---+---+---+---+---+---+---+

   TIME   为发起者所期望的监视输出的秒数。随后的由同一个发出者发出的带有相同的TRANS-ID 标识的MON请求应当更新正在进行着的MON交易的时间，这称为“部分重叠更新（overlapping renew）”。

   MON的RESPONSE编码如下所示：

   0   接受，OP-DATA 已有并且合法
   1   拒绝(配额错误 - 激活的MON太多了)

   如果RESPONSE 为零（0），MON响应有如下OP-DATA 数据结构：

                 +0 (MSB)                            +1 (LSB)
      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   0: |             TIME              |     ACTION    |     REASON    |
      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   2: |                                                               |
      /                            IDENTITY                           /
      /                                                               /
      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

   TIME      为此MON交易所剩余的秒数

   ACTION    为一指示一个储存区的对象操作的数值编码。
             编码如下：

             0   存储区中添加了一个实体
             1   存储区中将一个实体刷新
             2   存储区中一个实体被替换
             3   存储区中删除了一个实体

   REASON    为一指示一个操作的原因的数值编码
             编码如下:

             0   下边的编码没有涉及的其它原因码
             1   代理客户拿来此实体
             2   代理客户拿来此实体而存储区不允许
             3   代理服务器预先提供了此实体
             4   实体已过期，经由起标题
             5   由于编码如下存储限制而实体被清除(purged)

   6.4. SET (OPCODE 3):

    通知缓冲区对象标识。 这是一个“push”交易，通过共用的缓冲区可以共享信息，比如所更新年/日期/期限标题（这可能是由于原有的“304未被修改（304 Not modified）”响应导致的）或者是更新存储区标题（这可能是由于发现非官方的“修改（vary）”情况发生或者得到此实体的第二方或第三方存储区所在位置导致的）。RD 为真。

   SET请求有如下OP-DATA 数据结构：

      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   0: |                                                               |
      /                            IDENTITY                           /
      /                                                               /
      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

   RESPONSE 编码如下：

             0   标识被接受，谢谢
             1   标识被忽略，未给出原因，谢谢

   SET 响应没有 OP-DATA。

   6.5. CLR (OPCODE 4):

    告诉存储区完全清除掉一个实体。

    CLR 请求有如下OP-DATA 数据结构：

      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   0: |                   RESERVED                    |     REASON    |
      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   2: |                                                               |
      /                           SPECIFIER                           /
      /                                                               /
      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

    REASON    为一指示请求者询问的实体被移除的原因的数值编码。其编码如下：

             0   其它的原因
             1   原服务器告诉我此实体并不存在

    RESPONSE 编码如下：

             0   我曾经有过，现在没有了
             1   我有，且一直保留着，为提供原因
             2   我没有

    CLR 响应没有OP-DATA。

    没有具体指明响应、实体、或者存储区标题就清除一URI意味着清除所有的使用此URI的实体。RD 为真。

7.  安全考虑

   If the optional AUTH element is not used, it is possible for  unauthorized third parties to both view and modify a cache using the  HTCP protocol.

8.  感谢

   Mattias Wingstedt of Idonex brought key insights to the development
   of this protocol.  David Hankins helped clarify this document.

9.  参考文献

   [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
             Resource Identifiers (URI): Generic Syntax", RFC 2396,
             August 1998.

   [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter,
             L., Leach, P. and T. Berners-Lee, "Hypertext Transfer
             Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-
             Hashing for Message Authentication", RFC 2104, February,
             1997.

   [RFC2186] Wessels, D. and K. Claffy, "Internet Cache Protocol (ICP),
             version 2", RFC 2186, September 1997.

10.  作者地址

   Paul Vixie
   Internet Software Consortium
   950 Charter Street
   Redwood City, CA 94063

   Phone: [phone]
   EMail: [e-mail]

   Duane Wessels
   National Lab for Applied Network Research
   USCD, 9500 Gilman Drive
   La Jolla, CA 92093

   Phone: [phone]
   EMail: [e-mail]

11.  完整的版权声明

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

鸣谢

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Hyper Text Caching Protocol (HTCP/0.0)                  超文本缓存协议(HTCP/0.0)


RFC文档中文翻译计划