Hi Martin,
I also think that both side should send a TE message
immediately after they do not want to send any further data
(as described in the rfc), but to free the data associated
with the whole transaction could cause trouble.
Let's assume a service that appends some data to the original
stream. If the OPES-processor sends a TE message after it has
finished data-transmission, the service could never finish
the delivery of the adapted stream, because the
OPES-processor has no data about the transaction anymore.
Very true. Therefore my memory about freeing all data after
sending the TE must be wrong ;-)
Maybe I mixed this with what we discussed with regards to CE.
I had very much in mind the order that is shown in the first
example of HTTP 4236 where the OPES processor waits until it
receives the AME from the callout server before it sends its own
TE.
But otherwise already the second example would be wrong.
So, indeed TE can only mean that no more data is sent but
more data can be received (eventually).
First of all TE is only an indication for the peer that no
more message for this transaction will follow.
Regarding timing: For the HTTP profile it is important that
the AME message is sent directly after the last chunk of
application data. The time of sending the TE should not cause
a big effect.
And what if e.g. the callout-server terminates the
transaction with an error while the processor is still
sending data. What statuscode should then be used by the
processor for its TE message?
It is intended that the callout server can send a TE while the
processor is still sending data. If an anti malware OPES service
detects malicious code in the beginning of the application data
it can replace the original application data with an end user
error message and then end the transaction. This gives the OPES
processor also the chance to stop transferring more of the original
message to the callout server and by that save resources.
The OPES processor should then send a 206 partial result with the
AME message. Nothing special has been defined for the TE in this case
I think. The transaction is still normally closed.
By the way the rfc specifies:
|> An OCP agent MUST send a Transaction End (TE) message immediately
|> after it makes a decision to send no more messages related to the
|> corresponding transaction.
Please note the "to send no more messages". But does that
mean that the agent does not want to _receive_ data related
to the transaction anymore?
Seems that it really only means no more sending but still able
to receive. (see also above)
Also please note the difference between AME (no more application
data) and TE (no more OCP messages).
Best regards
Martin Stecher