An ICP_OP_MISS_NOFETCH response indicates that this cache is up,
      but is in a state where it does not want to handle cache misses.
      An example of such a state is during a startup phase where a cache
      might be rebuilding its object store.  A cache in such a mode may
      wish to return ICP_OP_HIT for cache hits, but not ICP_OP_MISS for
      misses.  ICP_OP_MISS_NOFETCH essentially means "I am up and
      running, but please don't fetch this URL from me now."

      Note, ICP_OP_MISS_NOFETCH has a different meaning than
      ICP_OP_MISS.  The ICP_OP_MISS reply is an invitation to fetch the
      URL from the replying cache (if their relationship allows it), but
      ICP_OP_MISS_NOFETCH is a request to NOT fetch the URL from the
      replying cache.

   ICP_OP_DENIED
      An ICP_OP_DENIED response indicates that the querying site is not
      allowed to retrieve the named object from this cache.  Caches and
      proxies may implement complex access controls.  This reply must be
      be interpreted to mean "you are not allowed to request this
      particular URL from me at this particular time."

      Caches receiving a high percentage of ICP_OP_DENIED replies are
      probably misconfigured.  Caches should track percentage of all
      replies which are ICP_OP_DENIED and disable a neighbor which
      exceeds a certain threshold (e.g. 95% of 100 or more queries).

      Similarly, a cache should track the percent of ICP_OP_DENIED
      messages that are sent to a given address.  If the percent of
      denied messages exceeds a certain threshold (e.g. 95% of 100 or
      more), the cache may choose to ignore all subsequent ICP_OP_QUERY
      messages from that address until some sort of administrative
      intervention occurs.






 
RFC 2186                          ICP                     September 1997


   ICP_OP_HIT_OBJ
      Just like an ICP_OP_HIT response, but the actual object data has
      been included in this reply message.   Many requested objects are
      small enough that it is possible to include them in the query
      response and avoid the need to make a subsequent HTTP request for
      the object.

      CAVEAT: ICP_OP_HIT_OBJ has some negative side effects which make
      its use undesirable.  It transfers object data without HTTP and
      therefore bypasses the standard HTTP processing, including
      authorization and age validation.  Another negative side effect is
      that ICP_OP_HIT_OBJ messages will often be much larger than the
      path MTU, thereby causing fragmentation to occur on the UDP
      packet.  For these reasons, use of ICP_OP_HIT_OBJ is NOT
      recommended.

      A cache must not send an ICP_OP_HIT_OBJ unless the
      ICP_FLAG_HIT_OBJ flag is set in the query message Options field.

      ICP_OP_HIT_OBJ payload format:

        0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      /                       Null-Terminated URL                     /
      /                                                               /
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Object Size           |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
      |                                                               |
      /                           Object Data                         /
      /                                                               /
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


      The receiving application must check to make sure it actually
      receives Object Size octets of data.  If it does not, then it
      should treat the ICP_OP_HIT_OBJ reply as though it were a normal
      ICP_OP_HIT.

      NOTE: the Object Size field does not necessarily begin on a 32-bit
      boundary as shown in the diagram above.  It begins immediately
      following the NULL byte of the URL string.






 
RFC 2186                          ICP                     September 1997


   UNRECOGNIZED OPCODES
      ICP messages with unrecognized or unused opcodes should be