Bad request for direct image upload

[osrjv]

Bad request for direct image upload

[osrjv]

@mahtin, I did end up implementing the workaround for 2.17.0 where some value is always sent with the multipart requests. But I now verified that it's no longer needed with 2.18.1.

Thanks again for the quick resolution

[mahtin]

Oops! That's not right. Five minutes later ... I seen the issue.

One of the big changes between the releases was the importing of the OpenAPI spec directly into the library such that if the call needed a specific Content-Type in the header then it would be set. So far so good.

However, it turns out that if Content-Type is value multipart/form-data and there's ZERO parameters being passed; then the Cloudflare API complains (the Bad request: multipart/form-data Content-Type has invalid syntax: lacks boundary error). Now ... you could claim that deep within Cloudflare's API they should handle this. But I'll be defensive and agree that the sender (this library) should in fact handle that case.

I added some simple code added and I'll start testing for everything similar to this API endpoint.

git diff CloudFlare/cloudflare.py 
...
+                if data is None and files is None and self.headers['Content-Type'] == 'multipart/form-data':
+                    # can't have zero length multipart/form-data and as there's no data or files; we don't need it
+                    del self.headers['Content-Type']
...

Reading the API definition at https://developers.cloudflare.com/api/operations/cloudflare-images-create-authenticated-direct-upload-url-v-2 you see the following for optional body values:

  --form expiry= \
  --form id= \
  --form metadata= \
  --form requireSignedURLs=

In testing this, see above, I can see that you must have at-least one param in order to make this work on 2.17.10 - the current release. I've been using 2.17.0 and have this working cleanly. I pass at least one parameter and it works. Look at this:

        cf = CloudFlare.CloudFlare()

        # direct_upload uses multipart/form-data and hence this info is passed as files (but None for filename)
        files = {
            ('metadata', (None, '{"foo": "bar"}')),
        }
        try:
            r = cf.accounts.images.v2.direct_upload.post(account_id, files=files)
        except CloudFlare.exceptions.CloudFlareAPIError as e:
            exit('%s: %d %s - api call failed' % ('/accounts/images/v2/direct_upload', e, e))
        print(json.dumps(r, indent=4))

Yes, the metadata is useless; however, it triggers the code to work correct. Please this this if you could.

I'll work on a fully cleaned up release later today that will be a lot more generic. However, as Cloudflare API needs at-least on parameter in the body, something must be passed.

Oh. I also did this:

import datetime

        # format future time in RFC3339 format (and do it UTC time)
        time_plus_one_hour_in_iso = (datetime.datetime.utcnow().replace(microsecond=0) + datetime.timedelta(hours=1)).isoformat() + 'Z'

        files = {
            ('expiry', (None, time_plus_one_hour_in_iso))
        }

That's actually useful. Your call.

More later.

[osrjv]

Thanks for the prompt and in-depth answer! Indeed I think the best option is to provide an expiry time - even if the issue is fixed.

[mahtin]

@osrjv - I have pushed 2.18.0 to GitHub and to PyPI. You can do the usual pip install --upgrade cloudflare to get the new release.

I will also point you to examples/example_images_v2_direct_upload.py for my code that implements that API call and show the various methods that work with specific releases of the Cloudflare Python library. I hope that code is useful.

To summarize:

• 2.14.2 or lower - no backend bug is triggered
• 2.14.3 thru 2.17.0 - this can trigger the bug; however, you can set a files= to pass at least one parameter to avoid triggering the backend bug
• 2.18.0 and above - fixed such that you don't trigger the backend bug; however, you can also pass simpler data= parameters and they will be sent correctly.

Technically, with 2.18.0 you are back to a setup where you won't trigger that issue within the backend API code running at Cloudflare if you don't pass any parameters. The exact bug was what I wrote above. If you set Content-Type to value multipart/form-data (as needed by this API endpoint) and there's ZERO parameters being passed; then the Cloudflare API complains. This is a backend bug and I've reported this to the right folks at Cloudflare.

If you upgrade and are back to a stable setup - please let me know and close the issue. I see where I created this issue and I'm sorry for that.

Thanks in advance - Martin

[mahtin]

@osrjv - make that version 2.18.1 as a wrote some test code and found a few more edge cases. This is now a lot more robust.

Also, I cleaned up examples/example_images_v2_direct_upload.py and the code is much neater now.

As I said above: If you upgrade and are back to a stable setup - please let me know and close the issue

[mahtin]

Unrelated to your issue; however 2.19.0 is now pushed because of a bad (but unrelated) bug in 2.18.? within the cli4 command. Please upgrade.