- From: Martin Hamilton <martin@net.lut.ac.uk>
- Date: Wed, 17 Mar 1999 14:14:43 +0000
- To: Harald Alvestrand <Harald@alvestrand.no>
- Cc: Koen Holtman <Koen.Holtman@cern.ch>, Larry Masinter <masinter@parc.xerox.com>, Keith Moore <moore@cs.utk.edu>, web@apps.ietf.org, discuss@apps.ietf.org
-----BEGIN PGP SIGNED MESSAGE-----
Harald Alvestrand writes:
| At one time at least, the ICP protocol of SQUID would ship small documents
| in UDP datagrams on the ICP response.
| That community is probably able to give practical, recent experience.
The main one is probably that ICP is gradually being abandoned in
favour of the new Cache Digest protocol. For more info, check out:
<URL:http://squid.nlanr.net/Squid/CacheDigest/cache-digest-v5.txt>
For problems with ICP returning object contents, see RFC 2186 ...
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.
... and RFC 2187 ...
o ICP_OP_HIT_OBJ is particularly vulnerable to security problems
because it includes object data. For this, and other reasons,
its use is discouraged.
o Falsifying, altering, inserting, or blocking ICP messages can
cause an HTTP request to fail only in two situations:
- If the cache is behind a firewall and cannot directly
connect to the origin server.
- If a false ICP_OP_HIT reply causes the HTTP request to be
forwarded to a sibling, where the request is a cache miss
and the sibling refuses to continue forwarding the request
on behalf of the originating cache.
Sayonara!
Martin
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv
iQCVAwUBNu+40NZdpXZXTSjhAQG16wQApJXctu2XI1tTDigKP/NGsbSS3G+98gp5
6vlgJ23+cJmtNjp9dB/GR6VR2csgDl8Jccp3Y8JJPGPGh4hEafMGcrsiWbdt3tKE
2fMROqGMrg02qwHU2KVGMnM3Lhd3B1lsAHWdjXfj6xmCOYSudobLv/zfjJxm9m0y
u2ucUaYg5Sw=
=ng4U
-----END PGP SIGNATURE-----
Received on Wednesday, 17 March 1999 10:27:33 UTC