ietf-openproxy
[Top] [All Lists]

Re: Bypassing

2003-10-03 08:58:34

On Fri, 3 Oct 2003, Markus Hofmann wrote:

I mostly agree with Abbie's observations in that the fine-grained
BYPASS features discussed earlier in the thread are not really what
we need to do and too complicated. In particular, I'd be reluctant
to specify classes of OPES services, since we'll never be able to
predict all future OPES service classes...

We do not have to specify all classes or _any_ classes. I suggest that
we specify a URI-based interface (with a wildcard) and specify
appropriate defaults for implementations that do not understand the
meaning of a given URI. Others may use our interface and specify URI
meanings.

If a user requests non-blocking, OPES processor needs to determine
whether a "non-OPES" version is available. If yes, this version will
have to be served. If not, either an error is returned or the OPES
version is served.

Agreed.

It then boils down on how to determine whether there's a non-OPES
version available,

The exact mechanism is out of our scope. OPES systems will "determine"
somehow.

Couldn't we go that far and say that requests with non-blocking flag
are always being forwarded to the origin server.

Not in general. (a) A request may need to be modified for non-OPES
content to be served by the OPES-unaware server (e.g., a particular
header or parameter may need to be added by an OPES processor). And
(b) this is too HTTP-specific.

Now, when an error comes back (because there's no non-OPES version),
we could either leave it to the user to remove the non-blocking flag
(if wanted), or invoke the OPES service and serve the OPES version.

A user usually does not have control over low-level information such
as HTTP headers. The bypass has to be implemented entirely within the
OPES system (or it is not a bypass).

Alex.

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