Open kevinrjones opened 10 years ago
Yes, that seems reasonable. In fact, the X-Mime-Type should probably be removed entirely, and the Content-Type should contain the MIME type of the file (for non multipart encoded requests). For multipart encoded requests, the MIME type of the file is already provided in the header section of the file's multipart boundary.
I would also, personally, change if (file.type !== "")
to if (file.type)
. That new condition will evaluate to false if file.type
is null, undefined, or an empty string, plus, it's a little easier on the eyes.
Would you like me to create a pull request for this, or for a quick change like this would it be simpler for you to update master?
When completing this task, the code should also be updated to check the custom header array first. If any user-provided headers exist, such as Content-Type, we should refrain from setting that header with some default value anywhere else. Surprisingly, XMLHttpRequest.setRequestHeader
will append the passed value if the header has already been set. This is a bit non-intuitive, and I wasn't aware of this behavior until today.
This will definitely be part of 6.0
The uploader sets the X-Mime-Type header from the file's type
xhr.setRequestHeader("X-Mime-Type", file.type);
however type is sometimes empty and this results in an empty header which is not HTTP compliant. Is it reasonable to add this check to the code?
Thanks