I would say, this is a requirement on the HTTP proxy servers rather than the
OPES/Callout protocol.
(a) Cache-Control: An implementation of the icap client module in the HTTP
proxy server (say squid) would have to just check for the Cache-Control
header before sending it to the ICAP server for a transformation
(reqmod/respmod). - Section 14.9.5 of RFC 2616 HTTP 1.1
(b) Warning 214: Along the same lines, the Warning header is required to be
inserted by the HTTP 1.1 complaint proxy server. ( as per section 14.46 of
RFC 2616)
Did I miss something?
regards,
Geetha
Markus Hofmann wrote:
Masms are required in order to be HTTP-compliant; therefore,
I'd say they should be part of the ICAP server's HTTP stack.
Hm, this assumes that the payload (irk Nottingham wrote:
These mechani.e. the content-path protocol) is
NOT transparent to the OPES/Callout protocol, i.e. the OPES/Callout
protocol needs to have knowledge about the sematics of the
encapsulated application protocol (HTTP in this case).
Do we want to make this assumption? Comments?
-Markus
Subject: no-transform & Warning
Date:Thu, 11 Apr 2002 13:21:45 -0700
From: Mark Nottingham
Just curious,
Is anyone aware of an OPES, ICAP or other transcoding implementation
that:
a) honors Cache-Control: no-transform
b) honors Warning: 214 Transformation applied
in either requests or responses?
--
Mark Nottingham
http://www.mnot.net/