Hi,
Alex is right, the current message part handling is a mess.
I do not understand why I could forget about request satisfaction mode (short
circuits).
I tried several ways to list the possibilities of message part sending,
skipping, responding and found no easy way :-(
First here are some thoughts about short-circuits in the request-profile. I
think handling this one is not so complicated and can be added to the existing
draft:
Before the callout server sends back any application message part,
it MUST decide whether it wants to adapt the request or to short-curcuit.
It will either send back request-header, request-body, request-trailer parts
or response-header, response-body, response-trailer parts.
Some parts could be optional due to conditions defined below but it MUST NOT
mix parts of these two lists; on violation client MUST terminate transaction.
Then here some thoughts on parts in HTTP messages:
A request header is always in HTTP messages.
There are HTTP servers that do not send response headers.
OPES processor MUST either create a dummy HTTP header part,
or not use OCP/HTTP.
Trailers are often not in messages. There is no difference between
an empty trailer and a non-existing trailer.
Bodies can or cannot exist. Empty but existing bodies are technically
possible. Can an empty body be deleted without changing the meaning
of the message?
Then the best way to describe what needs to be done I found for me is a pseudo
programming language style.
I do not take the trailer parts in account, it's long enough without ;-)
OCP_Client_Send_Routine {
if ( NOT skip(request-header))
send (request-header)
if (inMessage (request-body) AND NOT skip(request-body))
send (request-body)
}
OCP_Client_Receive_Routine {
lastMessagePart = 0
while (read (newMessagePart)) {
if (newMessagePart == request-header) {
if (lastMessagePart != 0)
goto terminate_transaction;
buildHTTPMessage (newMessagePart);
} else if (newMessagePart == request-body) {
if (skip(request-header)) { // client has skipped part in send
if (lastMessagePart != 0)
goto terminate_transaction;
buildHTTPMessage (original_request-header);
} else {
if (lastMessagePart != request-header)
goto terminate_transaction;
}
buildHTTPMessage (newMessagePart);
} else if (newMessagePart == response-header) {
if (lastMessagePart != 0)
goto terminate_transaction;
buildHTTPMessage (newMessagePart);
} else if (newMessagePart == response-body) {
if (lastMessagePart != response-header)
goto terminate_transaction;
buildHTTPMessage (newMessagePart);
}
lastMessagePart = newMessagePart;
}
}
OCP_Server_Receive_Routine {
lastMessagePart = 0
while (read (newMessagePart)) {
if (newMessagePart == request-header) {
if (lastMessagePart != 0)
goto terminate_transaction;
filterHTTPMessage (newMessagePart);
} else if (newMessagePart == request-body) {
if (lastMessagePart != request-header) {
if (lastMessagePart != 0)
goto terminate_transaction;
if (skip_requested(request-header))
goto terminate_transaction;
}
filterHTTPMessage (newMessagePart);
}
lastMessagePart = newMessagePart;
}
}
OCP_Server_Send_Routine {
if (short_circuit) { // do request satisfaction
send (response-header)
if (message_has_body())
send (response-body)
} else {
if (have_received (request-header)) {
send (request-header)
} else {
if (have_own (request-header)
send (request-header)
}
if (have_received (request-body)) {
if ( NOT want_to_delete (request-body))
send (request-body)
} else {
if (have_own (request-body)
send (request-body)
}
}
}
This is not trivial and describing this in a good way is not easy.
Especially the problem that an OCP transaction that does not contain
request-body parts in neither client nor server messages can mean multiple
things:
a) There was no body part in the HTTP message and there should not be one
b) The body part has been skipped and should be used again in the adapted
message
c) The body part has been skipped and should be removed from the message
b) and c) can only be solved if we require that the callout service MUST send
an empty body part, if it wants to make sure that a skipped original part is
not included in the adapted message.
Is this the solution?
If not, we should consider to either skip the Skip-Parts feature or to redefine
it in another way.
Please check this idea:
-----------------------
Payload becomes optional in DUM messages. A new named parameter
"Skipped-Payload" has a value which is the size of the payload but the payload
itself is not sent.
The Skip-Parts negotiation remains the same but the OPES processor must still
send DUM messages including Kept parameter (becoming mandantory in this case).
The callout server replies with normal DUM or DUY messages (DUM if it wants to
replace the content it never saw, DUY if it wants the processor to re-use the
original data as usual). If the part is not sent, it shall be deleted from the
message.
The overall message part handling becomes much easier. There are DUM/DUY
messages for all message parts that are in the HTTP message and parts that are
not in the HTTP message (or that shall be deleted) will not be sent.
Does this solve the problems and does it simplify the draft and implementations?
Regards
Martin