I’m getting an internal server error on a request which has been working with no problems (in production) until now. It’s a PUT request to upload an image as a byte array. I’m not entirely sure when it stopped working, unfortunately. I’ve logged a few errorIDs in case this helps track down the problem.
"Internal server error with id E59BF83E-CB37-0726-FF3D-0C3B1BFBF900"
"Internal server error with id 50F7ACCB-CF05-E73C-FFDD-7B904CD87E00"
"Internal server error with id DB12EF6D-0DEF-9F76-FF5D-58915B982000"
"Internal server error with id 6CBCC844-5649-DDBC-FF35-23D94B84F600"
"Internal server error with id FB09F39A-C0E6-7D82-FF35-F4ACD434C400"
"Internal server error with id B59240D1-1C16-11F6-FFE7-673100DE0700"
The images are PNGs encoded as required by the File Service API. The URL of the requests follows the format (p_id is the unique ID of each image):
I’ve checked that the folder ‘zazzle’ does exist. I’m assuming it’s not something on my end as I would have expected a more formal error being reported in the form of:
I just tried a similar request in my app and it worked. There must be something in the request that makes it different. Would it be possible for you to capture a complete request which result in error? That is with full URL, all headers and the body?
At least we got a bit further. The error you got occurs when the body is empty and/or the Content-Type header does not start with “text/plain”. There’s got to be something there we’re missing. Would it be possible for you to make that REST request using a browser plugin? (just to have another point of reference) I just tried it with Postman using the same payload you shared with us and it worked: https://monosnap.com/file/4OBRCAbIDfymklwk1r6bi9fqrgyEz1
Just used Postman there to recreate the request and yes it’s working at this end, successfully uploading the PNG to the expected folder. Weird that this used to work. I wonder if a change in the AIR SDK has done something to change the way this kind of request is constructed. I’ll run a few tests and see if I can narrow it down any more. I’ll drop you a line if I spot anything useful.
So I eventually traced the source of the problem. Web requests made by Adobe AIR seem to specify the header “Content-Type” as “Content-type” (using lowercase ‘t’). I’ve verified this in both Fiddler and Postman. I’ve tried to force the upper casing within AIR in a variety of ways, to no avail. I’ve also rebuilt my app using older versions of the AIR SDK, in case this has been introduced since I had a working version. It would seem that AIR has probably always constructed it’s requests like this as it still doesn’t work as far back as AIR 19. Strictly speaking (from what i’ve read) HTTP 1.1 should use the upper case version (as your systems expect). Is there anything you guys can do at your end to account for a lower-case version: “Content-type”? Frustratingly this is holding back the release of our app
Thanks for digging in to figure out what’s causing it. As a workaround you could create Java or Node.JS service deployed to Backendless which would take the content as a Base64 encoded string and create a file. This would be faster than us patching the system (as simple as the fix sounds, the release process will have to take its course thus delaying your app even further. For more information on custom services, please see the documentation: https://backendless.com/documentation/business-logic/js/apieng_quick_start_guide_js.htm
