ietf-openproxy
[Top] [All Lists]

Re: OPES protocol, pre-draft

2003-02-19 13:37:15


On Wed, 19 Feb 2003, jfcm wrote:

Let assume that www.w3c.com says to redirect calls to www.w3.org and
that www.w3.org says to redirect calls to www.w3c.com. What happens?

A loop detection code at the second hop would see its own Via: header
already in the HTTP headers of the request and would not forward the
request further, responding with an error. This is how redirections
(and loop detection) are supposed to work today.

This issue is not directly related to OPES except that OPES callout
server might participate in loop detection by adding its own Via
headers (or application-specific equivalent). I do not know whether
the current requirement/architecture drafts consider callout server a
"proxy hop" on the application protocol path. They probably should.

But I certainly want that that type of service (I am not really
familliar with Internet protocols): is there a trick to achieve that
today?

You can certainly do the redirections today (any decent HTTP
intermediary can do that). Moreover, you can already do pretty much
anything on the traffic-modification level that OPES promises to
deliver! The reason we work on OPES is to provide a common interface
for "traffic modifiers" _and_ to address IAB concerns about them.

My understanding of the client as part of the OPES system is because
the client may interact with the OPES server. That traffic must be
left open by the OPES processor and it muts have top priority.

Example: in this redirection case, the callout server sends back a
question to the client: "this call will be rerouted are you OK?".
The OPES may also be a gateway asking for an ID/password. Or a make
a translation in an other language and to need some more information
to perform (ex. the meaning of a word in a menu).

My understanding is that OPES processor and callout server may
negotiate with each other, but may not negotiate with the data
producer or data consumer. Or, in other words, such "external"
negotiations are outside of OPES scope. However, OPES may document
application-protocol-specific(?) ways to [statically] specify data
producer's or data consumer's OPES preferences when making application
protocol transactions.

For example, a web browser may attach a "never translate the response"
OPES preference to an HTTP request, and that preference would get to
the OPES processor and/or callout server if they are in the path.

Alex.

-- 
                            | HTTP performance - Web Polygraph benchmark
www.measurement-factory.com | HTTP compliance+ - Co-Advisor test suite
                            | all of the above - PolyBox appliance

<Prev in Thread] Current Thread [Next in Thread>