Alex Rousskov wrote:
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.
That's fine, as long as we don't have pre-defined classes.
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.
I actually start believeing that an error should be returned in the
latter case...
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).
Agreed, good point.
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).
First of all, someone needs to articulate the desire to bypass OPES,
and this someone I would expect is the user. And I would assume that
this could be done, for example, similar to the "hard reload" feature
of Web browsers. When I hit CTRL-F% in my IE, it adds an "no-cache"
header to the outgoing HTTTP request.
-Markus