Full header information not sent to companion on Firefox for XHR/URL upload about uppy

[Murderlon]

That's odd, not sure how as we just use the XMLHttpRequest API to add headers, so it might be a browser bug?

I have created a new util (#5073) to refactor xhr-upload (#5074) in preparation for aligning the api with tus (#5094). Maybe these change will already help 🤔

[Kelketek]

@Murderlon Maybe, but I think there's more to it than that. One especially weird thing I saw when chasing down this bug was that the Chrome-sourced requests were proxied through Cloudflare like normal requests from the client are. However the Firefox ones bypassed it, and contacted localhost, following the hosts file. When I removed the hosts entry, they both ended up proxying through Cloudflare, but the Firefox one didn't contain the headers.

It suggests that the request to the backend on Chrome comes from the client whereas the request on Firefox comes from Companion. If they both came from companion I'd expect that they'd both have respected the hosts file. If they'd both come from the client I'd have expected the headers to be fully included. I'm not sure why they behave differently.

[Murderlon]

Just so I understand, are you testing local uploads to your backend or remote uploads with Companion? You mention Companion but also "drag and drop from one window in your browser", which wouldn't use Companion.

Do you see this problem without your nginx setup?

[Kelketek]

@Murderlon Remote uploads with companion. I meant to say 'from one tab to another'-- if I drag an image from one website to Uppy, it sends along the URL and Companion helps fetch it and upload it. This works in Chrome but not Firefox.

I haven't tried it without NginX. I'm not sure I'd get more clarity without NginX, since I'd have to set up a very different configuration that couldn't leverage using the same host/port combo, which I imagine would introduce more problems and significantly different config.