Thanks Jon Strabala for helping me out with this. I was able to reproduce the scenario with your handler. Turns out that our parser handles escaped and unescaped strings differently and our appcode endpoint deals with unescaped strings in their raw form.
The function code from the /appcode endpoint wasn't escaped during GET explicitly to improve readability (i.e we don't JSON Marshal it during the HTTP response). The idea is that the user can actually store and handle the appcode in files and edit it using any text editor.
Coming to the issue that we're seeing, turns when you use a combination of --data and @ to read from a file, the carriage returns and newlines are stripped off from the data before sending it in the request. This won't be a problem when the data is JSON since the strings are escaped and stripping \n & \r only means messing with the indentation of the file. However this can cause problems with code since some lines might get commented out or it can alter the meaning of the code (this might depend on the code, the handlers which I was using didn't have any comments on them – this is why I was not able to reproduce the issue).
On the contrary, using --data-binary doesn't strip \n and \r from the payload and the meaning remains intact. This is why using --data-binary works flawlessly. Refer curl documentation from here for more details
Jon Strabala I think we should document the end point to use --data-binary instead of --data to avoid confusion while reading from a file here onwards. Be mindful that this is not the case when I am not using @ to read from a file. Using --data should work just fine if I'm passing a string.