Hi Alex,
thank you for summarizing this so well.
I agree to all facts but #7:
7) Adapting just HTTP headers is less common than
adapting bodies. Moreover, adapting just HTTP
headers may be done better via a dedicated
profile
There are many services that only deal with headers, especially in the request
profile.
Examples are privacy filters (delete Referer and Cookie headers) and URL
blocker.
Given the above, I conclude that:
- We should keep AM-Part and Aux-Part to accommodate (A),
to have an interface for auxiliary parts in RESPMOD,
and to support short-circuit operation.
Yes.
- We should rely on OCP Core "getting out of the
loop" mechanisms to accommodate (B). That would
let us terminate data transmission early enough,
though not as early as with Skip-Part in some
cases. We should delete the Skip-Part interface.
Probably yes.
I have a little concern about the "early enough".
Let's take a service in RESPMOD that deletes cookies from
HTTP headers, nothing else. If that service is not fast
in responding and sending the i-want-out message, the OPES
processor will send much data of the body, wasting bandwidth.
- Optionally, we could add an optional Last-Needed-Part
parameter to NR to allow specifying the _last_
original part needed by the service and being semantically
equivalent to receiving (later) a corresponding Want-Use
parameter with the actual size of all parts up to the
last one. Processors MAY ignore Last-Needed-Part.
With these rules, Last-Needed-Part does not introduce
any new complicated requirements/dependencies.
Martin, do you think the above would be sufficient to accommodate most
of our needs? If yes, do you think adding Last-Needed-Part is worth
the trouble?
How do you see my concern above? Is it only valid for esoteric services?
Last-Needed-Part would address this. But maybe we can add anoter
parameter "Pause-Offset" to the feature which acts as a data-pause
pre-request. It requests a first data-paused message after n bytes
of the original body.
As with data-pause, OPES processor SHOULD honor this request.
This will be similar to the Preview feature of ICAP/1.0.
I think this fits even better into OCP context and can also be used
for other purposes (always where we have to assume that the callout
service is not as fast as the OPES processor).
Regards
Martin