Hello OpenWhiskers.
When an action is created or updated, the controller detects if the "code"
part of the HTTP Request is base64 encoded or a plain text string. The
current heuristic for detecting if the code is base64 encoded is buggy. It
uses a regex match
^([A-Za-z0-9+\/]{4})*([A-Za-z0-9+\/]{4}|[A-Za-z0-9+\/]{3}=|[A-Za-z0-9+\/]{2}==)$
which will match a 4-character string such as "abcd" or "true". This is
outlined in an issue https://github.com/apache/openwhisk/issues/4884.
We used to attempt to base64 decode the code string to determine if it was
base 64 encoded but this was replaced with the regex match. For the most
part the heuristic is OK but this is not completely sound.
I am soliciting feedback on the following schema change to the API. The
`binary` property on of the exec field is currently not required and
ignored by the controller. This forces the controller to always try to
determine the value of this property.
Instead, I'm suggesting we modify the schema to accept the binary property.
If present it is used as is and it is the caller/client responsibility to
set it accordingly. In the absence of this property in the HTTP request,
for backward compatibility, augment the heuristic to perform the expensive
decoding step as a last step in the confirmation process.
For actions already in the database (previously created actions), the
`binary` property is already set in the document in the db and can be used
as is, instead of recomputing the value.
In essence this is a step toward moving the responsibility to the clients
instead of the server.
Thoughts? In the absence of input, I will open a PR to implement the change
in this general direction. Thanks for reading this far.
-r
