ietf-openproxy
[Top] [All Lists]

Re: Bypassing

2003-10-01 10:57:39

On Wed, 1 Oct 2003, Martin Stecher wrote:

some questions about how to fill the Bypass section in the http
adaption document.

0. Information missing in other drafts?
draft-ietf-opes-end-comm-02 does not include any information about bypassing.
draft-ietf-opes-iab-02 only points out that the tracin information can be 
later
used to request OPES bypass.
Do we need more elaboration on bypassing in draft-ietf-opes-end-comm?

Yes. I also included a note about that in my review (sent to the list
an hour or so ago).

1. What to bypass?
There are trace headers OPES-System, OPES-Processor and OPES-Service.
Which ones make sense to use in bypassing?
Usually it will not be possible to bypass an OPES-Processor but is it required
to ask for bypassing of all OPES services that an OPES processor uses?
So, do we need one, two or three OPES-Bypass headers?

For simplicity and generality, I would suggest one header. Each OPES
entity above must be identified by its URI. So, assuming different
kinds of entities have different URIs, one header to bypass anything
is sufficient. Of course, some entities (on any level) may not be
bypass-able for a given application message. That's OK.

2. Wildcards
I guess we want to allow something like
  OPES-Bypass: *
to request bypassing of all OPES services.

Yes.

Did we ever think about different classes of services? It could make
sense to allow all non-modifying OPES services, i.e. those that do
some logging/reporting wihtout touching the data at all or those
that block the complete message on policy violation (e.g. virus
found) but would not alter the page itself.

Good point. I would suggest that we standardize URIs that identify
overlapping "classes" or "types" of OPES entities:
        - modifying (forwarding with modifications other than traces)
        - blocking (not forwarding)
        - reading (forwarding without modifications other than traces)
        - logging (keeping a portion of a message beyond message TTL)
        - unknown (the entity in charge of bypass does not know the
          class of an entity it forwards OPES traffic to)

More or better class names, anyone?

One could argue that pure "reading" entities do not exist. We can
leave it as a loophole for statistics-collecting entities, but note
that statistics collection at a "reading-only" entity MUST NOT include
storing samples of any size.

This addition will not affect OPES-Bypass header syntax or semantics.
We are still doing a URI match. It's just that some entities are known
by several URIs (unique one and a "group/class" URI). See below for an
example.

I guess due to the notification/tracing dilema in almost all cases,
the HTTP server will not know about single OPES services to bypass
and if it is concerned about OPES services it has to request bypass
of all or at least of some sort of OPES services.

I agree that it would take some advance configuration support on
processor side to implement bypass, but it is probably relatively easy
to document in the draft. Eventually, it may become implemented:

        id:         unique URI

        aka:        classification URIs (at least one SHOULD be
                    present since we have an unknown category)

        protocol:   internal info describing
                    ways to communicate with the service
                    (ICAP, OCP, plugin, etc.)

        bypassable: yes/no (indicates whether requests to
                    bypass the service should be honored)

HTH,

Alex.


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