Subject: RE: Getting Out Of The Loop optimization broken

From: "Martin Stecher" <[email-masked]>
Date: Mon, 27 Oct 2003 10:10:59 +0100

> 
> > > However, I am not sure how to document the "short circuit" code in
> > > the Core. The Core cannot assume that an application protocol has
> > > requests/responses and, hence, cannot document something like a
> > > "Respond with this response instead of forwarding original
> > > request" code.
> > >
> > > If I try to be generic and document the code as something like
> > > "adapted message is not intended for the original message
> > > recipient", we might raise red flags for those who think that IAB
> > > "OPES must not resolve URIs" concern applies in this case.
> > >
> > > Suggestions?
> >
> > I do not see that you have to document a generic short-circuit
> > thing. In OCP core it is simply about receiving application messages
> > back from the service that are (not longer) depending on the
> > original message.
> 
> A "no longer depending on (derived from?) the original" seems too
> vague to me. Even in your examples, you have cases (non-animated GIF
> and garbage-free BMP) that hardly fit this category because those
> adapted objects are derived directly from the original ones. I cannot
> think of a rule that will tell implementors exactly when to use 207
> response code.
> 
> It may help if you can give two _similar_ examples: one with 200 code
> and one with 207. Or, perhaps you can propose a better 207 code
> definition/rule?
> 
> > Sending HTTP error messages in REQMOD is a prominent example and
> > real request satisfaction another but there are more examples, even
> > for RESPMOD and in real life:
> >
> > 1. Removing animations from GIF images are possible by changing few
> > bytes in the beginning of the image and the cropping the image data
> > after the first picture. A callout service can return such adapted
> > GIF and instruct the OPES processor that it finished filtering even
> > before it has seen the rest of the GIF. Further transmission is not
> > necessary.
> 
> Why not return a 200 OK status code in this case?
> 
> > 2. Very similar from AntiVirus area: There are BMPs known to contain
> > malicious code after the real image data. A security service could
> > delete them and use the 207 result for best performance.
> 
> Why not return a 200 OK status code in this case? What are the
> performance differences that you are implying above? My understanding
> is that a regular 200 OK response will result in appropriate
> truncation of the forwarded image. 200 OK does not imply that the
> adapted length is the same as original length, does it?
> 
> > Do you now think, you can document that feature in core?
> 
> Sorry, I need to better understand how is 207 different from 200
> first. Please see the questions above.
> 

I think 207 is not longer needed. I wanted to use 207 in AME to achieve the same as with DWLY messages. Since we found that a transaction wide message (DWLY) works better than something bound to am-id, we do not longer need to distinguish 206 and 207.

I am fine with what we have in OCP core now.

Regards
Martin