RE: no-transform & Warning

--On Wednesday, April 17, 2002 23:28 +0200 Frank Berzau 
<frank(_at_)webwasher(_dot_)com> wrote:
> 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.
I was under the impression that the non-application layer intermediaries 
(e.g. things other than "proxies" or "surrogates") were out of scope for 
the work being considered by this WG.  Traffic interception/redirection 
operating at the layer you suggest above is widely agreed to be a Very Bad 
Thing in terms of the end-to-end architecture.
> 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.
Er, but seeing as the application intermediary must, by definition, 
understand the protocol that it might be operating modifications on (with 
the help of the callout system) it should already have the appropriate code 
to operate on those directives that it needs to honour.  E.g. in this case 
if there's a Cache-control: no-transform the HTTP intermediary should 
already have a code path to stop it being vectored AT ALL.
Similarly, the HTTP intermediary is the one entity in the relationship that 
likely has the best knowledge as to whether a Warning: 214 should be added 
to the outbound response headers.
[And I think I just echoed Geetha there.]

> 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/
> > >
> > >
> > >