Actually my suggested decoding step doesn't work either. I don't think
there's a sound way to record the binary property without cooperation from
the clients.
-r
On Sat, Apr 18, 2020 at 4:38 PM Rodric Rabbah <rod...@gmail.com> wrote:
> 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
>
>
