... Not an easy task...
First question I would ask myself is if I really have to support this 7 years old browser with 0% of usage?
Feature detection:
We can now since quite recently check what a FormData contains through its get()
, has()
, entries()
, values()
etc. methods. But the first specifications and implementations didn't had these methods and hence didn't offer any mean to detect this particular flow.
I don't have such an Android 4 browser to check, but I guess they didn't had any of these methods either...
An other modern and a bit hackish way to check would be to use a ServiceWorker, which should be able to intercept a dummy request, letting you know if your Blob was well appended, but once again, ServiceWorkers didn't exist 7 years ago.
This leaves us with an ugly browser identification, rather than a feature-detection (e.g navigator.userAgent
parsing). I can't advice doing so because it's so prone to err that it might be better just letting your user know it failed in your server response.
Workaround
The ability to send a generated Blob as binary through an other mean than FormData has only appeared a few months ago, and currently only Blink browsers do support it natively, and FF through a bug exploit.
This means that the only workaround for your users on Android Browser 4.xxx and for all the browsers that didn't support this method, would be to save the generated Blob on their device, and then to pick it from an <input>
and send it through a normal HTML <form>
, but this is assuming they will be able to even save this Blob on their device, and I can't tell for sure...
Or you could maybe send a 30% bigger base64 representation of this data.
Or, probably the best is to let them know they should update their browser because it's really dangerous to have such an old browser facing the web nowadays.
So a small recap of the less bad possibilities:
- Check if FormData is available. Otherwise fallback to an ugly b64 in a
<form>
- Send a first time with optimal Blob as multi-part.
- On server: check if the received Blob is empty. In this case, let the front-side know from a custom response.
- If server said it failed, send again, this time as b64. Since the first time was empty, it should not have been a too heavy request anyway.