Technically the callout protocol itself does not need to be aware of the
encapsulated payload and it's specific syntax or requirements. Question
is whether the callout client and/or server need to be. As far as the
client is concerned, it depends. The client could be implemented in a
switch, not a http proxy (to pick just one example). As such it is
unlikely that the client understands the protocol fully, it would just
forward all traffic sent to port 80 to a callout server. If we require
the client to understand those issues, it will make it far more complex
than needed. As far as the callout server is concerned, the answer can
only be Yes. The callout server is operating on the payload (headers or
body, or both or part of either, whatever), so it does need to
understand the protocol, and comply to all it's rules. Other examples
would be callout server that work on SMTP, NNTP or any other protocol.
Each one of those would need to understand the respective protocol it's
dealing with.
There may be cases, where putting "intelligence" into the client would
make sense. For example the no-transform HTTP header would make it
unnecessary to send a request to a callout server. In those very
specific and rare cases I'd still leave it up to the callout server to
handle it. Still a vendor could build that checking into the client in
order to improve performance by eliminating un-needed requests. That,
however, would be implementation specific. There is no need to require
it if we assume it's already handled at the server.
Thanks, Frank
-----Original Message-----
From: owner-ietf-openproxy(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-openproxy(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of
Geetha Manjunath
Sent: Mittwoch, 17. April 2002 06:54
To: Markus Hofmann
Cc: Mark Nottingham; ietf-openproxy(_at_)imc(_dot_)org; LMM(_at_)acm(_dot_)org
Subject: Re: no-transform & Warning
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/