On Mon, 27 Oct 2003, Martin Stecher wrote:
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.
Alex.