Subject: RE: OPES protocol, pre-draft

From: "Abbie Barbir" <[email-masked]>
Date: Wed, 19 Feb 2003 13:23:15 -0500

hi,

good discussion so far. 

see inline

abbie

> -----Original Message-----
> From: Alex Rousskov [mailto:[email-masked]] 
> Sent: Wednesday, February 19, 2003 12:57 AM
> To: [email-masked]
> Subject: Re: OPES protocol, pre-draft
> 
SNIP

> If there is a consensus that OPES server cannot modify source 
> and destination info, then we can simplify the protocol a 
> little bit. Is there a consensus regarding this design 
> decision? Perhaps Abbie's poll will show...
> 

--- abbie
well, it seems we do not have one, so here, please i would like direct
votes.

Chairs, Can u please remark on this requirement???????

For the recored, I think that OPES should be able to

abbie

SNIP

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 19 Feb 2003 12:01:35 -0700 (MST)

On Wed, 19 Feb 2003, Abbie Barbir wrote:

> well, it seems we do not have one, so here, please i would like
> direct votes.
>

For the record, I also think that OPES should be able to. I think so
because (a) it allows for broader manipulations and (b) some of those
manipulations would be possible (in an awkward way) anyway, tempting
violators.

The security/privacy part of the protocol should be especially strong
when it comes to source/destination changes, of course.

An example for the item (b) above. Consider two HTTP proxies that are
chained together. The first proxy on the request path has an OPES
callout server attached. A request for origin server A arrives at the
first proxy. The callout server modifies HTTP headers so that the
request is now destined to a different origin server B. The modified
request is forwarded to the second proxy (the first proxy is not aware
of the destination changes). The second proxy is not OPES-aware. It
simply forwards the request to B. Thus, if I use two proxies, I can
implicitly modify request destination using OPES! If this can be
hacked, we would be better off allowing (and controlling) it
explicitly.

Alex.