Open matthias-pichler opened 3 weeks ago
As suggested by you in #978, I think we should add a new redirects
boolean property, defaulting to false
.
As a matter of consequence, when it has been set to true
, http
calls are successfull when status is in [200,399] range. When set to false
, they are considered successfull only when in [200,299] range.
WDYT?
If applicable, then we should decide the name of said property. I propose:
redirect(s)
redirection(s)
allowRedirect(s)
supportRedirect(s)
acceptRedirect(s)
...I have a strong preference for either 1 or 2, as they are single words.
Shouldn't the allow-redirects
be handled by the underlying platform? The HTTP connectors can configure if it will follow redirects automatically or not. Hence, implementors will have to bind this option to the underlying HTTP connector. I'm unsure if we should add this option to the DSL since it's an infrastructure configuration.
@ricardozanini This is IMHO definitly related to the DSL, as in some cases, an author might/have to explicitly authorize a redirect, and she might choose/have to to explicitly forbid it in others.
Delegating that to runtimes would restrict authors choice/use cases. Additionally, workflows might have completly different behaviors on implementations with different redirection strategies, which would drastically hinder portability.
My point is that any HTTP library will set the follow-redirects
property to true independently of the implementation. Do you have a use case where the DSL author should set this property to the workflow level?
Bringing this to the DSL will enforce implementations to bind the DSL to an infrastructure configuration.
Discussed in https://github.com/serverlessworkflow/specification/discussions/978
We should document that
call: http
andcall: openapi
raise acommunication
error for status codes outside of[200, 399]