RE: what-parts-to-send-or-skip

["Martin Stecher" <martin.stecher@xxxxxxxxxxxxx>]

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