rfc2756.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 844 行 · 第 1/3 页


RFC 2756         Hyper Text Caching Protocol (HTCP/0.0)     January 2000


   LENGTH      is the number of octets used by the AUTH, including the
               LENGTH field itself.  If the optional AUTH is not being
               transmitted, this field should be set to 2 (two).  LENGTH
               can include padding, which means that not all octets
               reserved by LENGTH will necessarily be consumed by
               SIGNATURE.

   SIG-TIME    is an unsigned binary count of the number of seconds
               since 00:00:00 1-Jan-70 UTC at the time the SIGNATURE is
               generated.

   SIG-EXPIRE  is an unsigned binary count of the number of seconds
               since 00:00:00 1-Jan-70 UTC at the time the SIGNATURE is
               considered to have expired.

   KEY-NAME    is a COUNTSTR [3.1] which specifies the name of a shared
               secret.  (Each HTCP implementation is expected to allow
               configuration of several shared secrets, each of which
               will have a name.)

   SIGNATURE   is a COUNTSTR [3.1] which holds the HMAC-MD5 digest (see
               [RFC 2104]), with a B value of 64, of the following
               elements, each of which is digested in its "on the wire"
               format, including transmitted padding if any is covered
               by a field's associated LENGTH:

               IP SRC ADDR                           [4 octets]
               IP SRC PORT                           [2 octets]
               IP DST ADDR                           [4 octets]
               IP DST PORT                           [2 octets]
               HTCP MAJOR version number             [1 octet]
               HTCP MINOR version number             [1 octet]
               SIG-TIME                              [4 octets]
               SIG-EXPIRE                            [4 octets]
               HTCP DATA                             [variable]
               KEY-NAME (the whole COUNTSTR [3.1])   [variable]

   2.8.1.  Shared secrets should be cryptorandomly generated and should
   be at least a few hundred octets in size.

3.  Data Types

   HTCP/0.* data types are defined as follows:








Vixie & Wessels               Experimental                      [Page 6]

RFC 2756         Hyper Text Caching Protocol (HTCP/0.0)     January 2000


   3.1. COUNTSTR is a counted string whose format is:

                 +0 (MSB)                            +1 (LSB)
      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   0: |                             LENGTH                            |
      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   2: |                                                               |
      /                              TEXT                             /
      /                                                               /
      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

   LENGTH  is the number of octets which will follow in TEXT.  This
           field is *not* self-inclusive as is the case with other HTCP
           LENGTH fields.

   TEXT    is a stream of uninterpreted octets, usually ISO8859-1
           "characters".

   3.2.  SPECIFIER is used with the TST and CLR request messages,
   defined below.  Its format is:

      +---------------------+
      |        METHOD       | : COUNTSTR
      +---------------------+
      |         URI         | : COUNTSTR
      +---------------------+
      |       VERSION       | : COUNTSTR
      +---------------------+
      |       REQ-HDRS      | : COUNTSTR
      +---------------------+

   METHOD    (Since HTCP only returns headers, methods GET and HEAD are
             equivalent.)

   URI       (If the URI is a URL, it should always include a ":"<port>
             specifier, but in its absense, port 80 should be imputed by
             a receiver.)

   VERSION   is an entire HTTP version string such as" HTTP/1.1".
             VERSION strings with prefixes other than "HTTP/" or with
             version numbers less than "1.1" are outside the domain of
             this specification.

   REQ-HDRS  are those presented by an HTTP initiator.  These headers
             should include end-to-end but NOT hop-by-hop headers, and
             they can be canonicalized (aggregation of "Accept:" is
             permitted, for example.)




Vixie & Wessels               Experimental                      [Page 7]

RFC 2756         Hyper Text Caching Protocol (HTCP/0.0)     January 2000


   3.3.  DETAIL is used with the TST response message, defined below.
   Its format is:

      +---------------------+
      |      RESP-HDRS      | : COUNTSTR
      +---------------------+
      |     ENTITY-HDRS     | : COUNTSTR
      +---------------------+
      |     CACHE-HDRS      | : COUNTSTR
      +---------------------+

   3.4.  IDENTITY is used with the MON request and SET response message,
   defined below.  Its format is:

      +---------------------+
      |      SPECIFIER      |
      +---------------------+
      |        DETAIL       |
      +---------------------+

4.  Cache Headers

   HTCP/0.0 CACHE-HDRS consist of zero or more of the following headers:

   Cache-Vary: <header-name> ...
      The sender of this header has learned that content varies on a set
      of headers different from the set given in the object's Vary:
      header.  Cache-Vary:, if present, overrides the object's Vary:
      header.

   Cache-Location: <cache-hostname>:<port> ...
      The sender of this header has learned of one or more proxy caches
      who are holding a copy of this object.  Probing these caches with
      HTCP may result in discovery of new, close-by (preferrable to
      current) HTCP neighbors.

   Cache-Policy: [no-cache] [no-share] [no-cache-cookie]
      The sender of this header has learned that the object's caching
      policy has more detail than is given in its response headers.

      no-cache          means that it is uncacheable (no reason given),
                        but may be shareable between simultaneous
                        requestors.

      no-share          means that it is unshareable (no reason given),
                        and per-requestor tunnelling is always
                        required).




Vixie & Wessels               Experimental                      [Page 8]

RFC 2756         Hyper Text Caching Protocol (HTCP/0.0)     January 2000


      no-cache-cookie   means that the content could change as a result
                        of different, missing, or even random cookies
                        being included in the request headers, and that
                        caching is inadvisable.

   Cache-Flags: [incomplete]
      The sender of this header has modified the object's caching policy
      locally, such that requesters may need to treat this response
      specially, i.e., not necessarily in accordance with the object's
      actual policy.

      incomplete   means that the response headers and/or entity headers
                   given in this response are not known to be complete,
                   and may not be suitable for use as a cache key.

   Cache-Expiry: <date>
      The sender of this header has learned that this object should be
      considered to have expired at a time different than that indicated
      by its response headers.  The format is the same as HTTP/1.1
      Expires:.

   Cache-MD5: <discovered content MD5>
      The sender of this header has computed an MD5 checksum for this
      object which is either different from that given in the object's
      Content-MD5:  header, or is being supplied since the object has no
      Content-MD5 header.  The format is the same as HTTP/1.1 Content-
      MD5:.

   Cache-to-Origin: <origin> <rtt> <samples> <hops>
      The sender of this header has measured the round trip time to an
      origin server (given as a hostname or literal address).  The <rtt>
      is the average number of seconds, expressed as decimal ASCII with
      arbitrary precision and no exponent.  <Samples> is the number of
      RTT samples which have had input to this average.  <Hops> is the
      number of routers between the cache and the origin, expressed as
      decimal ASCII with arbitrary precision and no exponent, or 0 if
      the cache doesn't know.














Vixie & Wessels               Experimental                      [Page 9]

RFC 2756         Hyper Text Caching Protocol (HTCP/0.0)     January 2000


6.  HTCP Operations

   HTCP/0.* opcodes and their respective OP-DATA are defined below:

   6.1. NOP (OPCODE 0):

   This is an HTCP-level "ping."  Responders are encouraged to process
   NOP's with minimum delay since the requestor may be using the NOP RTT
   (round trip time) for configuration or mapping purposes.  The
   RESPONSE code for a NOP is always zero (0).  There is no OP-DATA for
   a NOP.  NOP requests with RD=0 cause no processing to occur at all.

   6.2. TST (OPCODE 1):

   Test for the presence of a specified content entity in a proxy cache.
   TST requests with RD=0 cause no processing to occur at all.

   TST requests have the following OP-DATA:

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

   RESPONSE codes for TST are as follows:

   0   entity is present in responder's cache
   1   entity is not present in responder's cache

   TST responses have the following OP-DATA, if RESPONSE is zero (0):

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

   Note:  The response headers returned by a positive TST can be of a
          stale object.  Requestors should be prepared to cope with this
          condition, either by using the responder as a source for this
          object (which could cause the responder to simply refresh it)
          or by choosing a different responder.






Vixie & Wessels               Experimental                     [Page 10]

RFC 2756         Hyper Text Caching Protocol (HTCP/0.0)     January 2000