Negotiation mode in execution: Prefer Header

[pcampanella]

There are different test for the synch mode. For example: /req/core/job-results-sync

Our server declares all as Asynch.

I understood from the standard that still can be a negotiation as described in: 7.11.2.3. Execution mode

Req 25 -> no header, only async app => async Req 26 -> asynch header, only async app => asynch

Recc 12 -> I think there is a typo, but ends always with asynch. And if I'm right that there is a typo (A and B ends in the same way) we should receive a wait header Recc13 -> for the client Rec 14 -> about the headers.

So I think that when all the apps declare asynch, we should force the synch execution only if we receive a Prefer header with wait value.

From our logs, we never receive the wait value in the Preference header. So our code always "decide" for asynch execution. But still the "synch" test fails.

Maybe you should add the Prefer: wait header in that case? Or it is my misunderstanding of the standard?

[ghobona]

@pcampanella I can see the typo in Recommendation 12B.

We generally do not implement executable tests for Recommendations, so it is possible that the test for Recommendation 12 is not implemented.

It is often helpful to reproduce an issue using the server that is being tested. Is the server you are testing publicly accessible?

[ghobona]

@pcampanella You can also send me the URL of the server via a direct message on gitter.im

[pcampanella]

@ghobona thanks for the feedback. About Recommendations I understand that may not be implemented. Yes we can share the address with you to make test: usually the server needs authentication. We can have a private chat on this.

[jerstlouis]

My understanding of the intent of the Standard, as I explained in https://github.com/opengeospatial/ogcapi-processes/issues/311#issuecomment-1426615556, is that if a process only declares support for async execution, execution is always expected to return a 201, never a 200.

A client wishing for async execution should still always use a Prefer: respond-async header. If both sync and async are supported, then it makes sense for the client to also indicate its preference for how long it is willing to wait for a synchronous response (e.g., Prefer: respond-async,wait=10 to wait a maximum of 10 seconds).

There is an issue with recommendation 13 for the client, since the target of OGC API - Processes is the server, not the client. All normative recommendations should be expressed in terms of the server. It should probably be rephrased as a permission for the server to respond with either sync or async, and clarified that this only applies if the process description declares support for both sync and async. (The note about the client could be kept as informative text for client developers reading the standard).

In terms of the ETS, the Sync test expecting a 200 response should only be performed on processes declaring sync execution or both sync and async execution, without using a Prefer: header. The ETS can always expect a 200 response in these cases,

The ASync test expecting a 201 response should only be performed on processes declaring only support for async execution, using a Prefer: header. If the async test is also done on a process declaring support for both sync and async, it should not fail if the server decides to return sync, because the server is allowed to do so. Using wait=[large value] should normally result in a 200 sync response, so the ETS could issue a warning / failed recommendation in this case, but the server is allowed to not honor the preference, so this cannot be a hard fail.