On Wed, 23 Apr 2003, The Purple Streak, Hilarie Orman wrote:
We've stated several times that the OPES processor and callout
server have to be in the same administrative domain for security
reasons.
I hope the above is a typo. Perhaps you meant "same trust domain"?
Requiring same administrative domain is totally unnecessary, even for
security reasons.
But, let's look at the case where they aren't, just for fun.
Suppose someone put an HTTP intermediary in their path, as you
suggest, and suppose it is an OPES process and it does HTTP content
modification, wouldn't that be a mess?
I am not sure what "as you suggest" refers to (you did not quote the
message you are responding to). If my ISP or an ISP further upstream
installed a TCP hijacking HTTP proxy and did not tell me about it
(explicitly or via a smallprint in a signed contract), then there is a
trust problem. If the installed HTTP proxy is OPES-compliant and my
browser is OPES-aware, I may be able to notice/debug it.
Even if the callout protocol is something else (SE), there might be
an OPES box doing SE modification in the path.
Yes, the specific callout mechanism is irrelevant here.
So, I'd think the callout protocol MUST carry a transport header
with "no OPES" in order to control what could turn into an
uncontrollable routing problem.
I do not understand the above. Can you elaborate? IMO, the callout
protocol MUST NOT be involved if an OPES processor was instructed to
bypass OPES transformations (that instruction may come via the
application protocol being proxied). If callout protocol is involved,
we are not bypassing. If OPES processor cannot honor a bypass
instruction, then it is either incompliant or has to talk to an OPES
processor (and not just a callout server). Either case, is out of OCP
scope.
Alex.