Remove the "respond-sync" value (CODE SPRINT JAN 2026)

[pvretano]

Right now the standard seems to have two way of requesting synchronous execution. One way is based on the "wait" preference of the Prefer header. The other way is to use the "respond-sync" preference which is a preference defined in the OAProc standard but not in the "Prefer Header of HTTP" standard.

We should probably remove the unofficial "respond-sync" preference.

That, however, puts an extra burden on clients since there would no longer be a deterministic way to request synchronous execution for processes that support both "sync-execute" and "async-execute".

I suppose that if a server had a process "BOB" that supports both "sync-execute" and "async-execute" and the server wants to also offer a deterministic way to execute "BOB" synchronously, the server could advertise another identical process (called "BOB-SYNC" for example) that only support "sync-execute".

[fmigneault]

To be very technical about it, Prefer is never deterministic, by definition.

https://www.rfc-editor.org/rfc/rfc7240.html#section-2

The Prefer request header field is used to indicate that particular
server behaviors are preferred by the client but are not required for
successful completion of the request.

It is a good design choice as well, because even if a client requests a certain way, say wait=1000, the server is allowed to dismiss that abusive/suboptimal definition and revert to async. It does so by omitting wait from the Preference-Applied.

Therefore, it is possible currently to use Prefer: respond-async, wait=10, indicating that the client is willing to wait up to 10s for sync response, and will check the job status asynchronously beyond that. This allows the server fallback and resume the async execution, rather than killing the process when the request connection closes. Doing this fallback would reply with Preference-Applied: respond-async to indicate to the client that the wait part was not respected. If the process did complete in time, the sync response would include Preference-Applied: wait=10 instead.

This is described in: https://www.rfc-editor.org/rfc/rfc7240.html#section-2.1

If the server does not want to do the fallback behaviour, it is also allowed to reply with a 408 Timeout error (up to it to decide / not a requirement). Similarly, it could consider the Prefer more strictly (handling=strict, https://www.rfc-editor.org/rfc/rfc7240.html#section-4.4) to error out rather than use fallback behaviours. A client using Prefer: handing=strict, wait=10 parameters would be the right way to make it deterministic. With this, the client is telling the server that it does not intend to check for the job after, so auto-fallback to async is a waste of resources, and it is adequate to kill the job if sync cannot be respected.

Note

CRIM's server does not yet support the handling=strict portion, but I intend to implement it.
crim-ca/weaver#701

On the other hand respond-sync does not offer the flexibility, and is ambiguous if mixing it with respond-async.