Uploading files via workers


#1

Hi,
I’m trying to implement uploading of files to Google Cloud Storage via the workers.
I built the whole process but I’m now stuck on one last thing.
Background:
We have a web app that you can upload any type of file with it to our servers.
We decided to switch from a VM server to using the GCS platform. All the requests are routed through Cloudflare, Therefore I created a route for the worker to process these requests.
I built the whole process for obtaining an access token for GCS and it uploads and creates the file in the desired bucket but this file is corrupt.

The upload originally is done with a multipart/form-data body format and I can extract the FormData object from the formData() method of the incoming request.
Then I can get(‘file’) form the FormData object I get. I believe that the problem is that in Cloudflare workers I don’t have the File object that the formData object should return when I call formData.get(‘file’) instead it returns the data as a string. I tried to add the returned object directly as the GCS requests body but as I said the resulting file is corrupt.

How can I get around this?


#2

Hi @noam4,

I’m afraid we don’t yet implement the File API, so FormData isn’t conformant in this area. The only workaround I can think of in the meantime is to upload the file in its own POST/PUT request via fetch() in the browser. Would that be feasible in your use case?

Harris


#3

Thanks for your reply but unfortunately I can’t change the way the files are uploaded.
I’m now trying to make a rough implementation of the FormData extraction that will suit our needs.
If you have a better solution please let me know.

Thanks,
Noam


#4

Hi @noam4,

That’s basically what I would do, too. There probably exists a pure-JS multipart/form-data parser that you could bundle into your script (e.g. with Webpack), then parse the raw data returned from await response.arrayBuffer().

I will also look into whether we can add the necessary part of the File API to support FormData correctly. It should be trivial, but if any scripts in the wild rely on the current buggy behavior then we’ll need to figure out a way to migrate them before suddenly changing the API behavior.

Harris