On Thu, 16 Oct 2003, Robert Collins wrote:
I think that the solution implied by your later message (I've already
replied to that) is much better.
I will not argue with the rest of this e-mail then, except that I want
to clarify one important point.
Which directly conflicts with HTTP's hop by hop requirements - anything
that is hop by hop will break, and break badly, unless we explicitly
handle the hop by hop semantics
Origin
|
AV interceptor(OPES processor) ---- AV engine
|
Client
in this diagram, the AV interceptor is responsible for Connection:
semantics, for TE and transfer-encoding semantics, and Trailer:
semantics, to pick a few common headers. Thus: the client will see
the AV Interceptors TE headers, not the origins TE headers.
I agree, but let's not forget that our scope is OPES agents and not
the entire intermediary. A more accurate/detailed picture would look
like this:
Origin
|
HTTP proxy -?- OPES processor -*- OPES callout service
|
Client
OCP scope is the "-*-" link. All "|" links are HTTP links. OPES
processor can be viewed as an HTTP hop from HTTP proxy view _or_ it
can be integrated with the HTTP proxy. Processor traffic and actions
on the "proxy side" (the "-?-" link) would depend on the degree of
that integration. Thus, it is not accurate to say that OPES processor
has to be responsible for Connection semantics; that would depend on
the link. However, if that OPES processor is using an HTTP link (and
claims HTTP compliance), then it becomes responsible.
Finally, the callout service may be interested in hop-by-hop headers.
For example, a logging service may want to log them. Thus, it is not a
good idea to require OPES processor to strip them. We should require
correctness on "|" links. What happens on "-*-" link is not important
from HTTP point of view because "-*-" link is not an HTTP link.
Hope this clarifies,
Alex.