Bug 159210 – Empty Content-Type header sent when uploading a file using XMLHttpRequest and type-less Blob

• Component: XML
• Status: RESOLVED DUPLICATE

[Greg B]

In my Javascript application I upload files to Amazon S3 bucket using XMLHttpRequests using type-less blobs
e.g. var myTypeLessBlob = new window.Blob([some Uint8Array of data]). 

The reason I'm not specifying a Content-Type (instead of using, say, application/octet-stream or binary/octet-stream, 
which is what this data is technically) is because I need to support a legacy (cannot modify the code of) version of 
Java application which fetches these uploaded documents later, and S3 expects the Content-Type header value that was 
specified during upload to be the same during download later - and the legacy app doesn't specify Content-Type during
its uploads or downloads.

Anywho, this type-less blob approach for upload and subsequent download seems to work fine for me in Chrome, Firefox, IE11, 
Microsoft Edge. That is, the Content-Type header does not get sent in a PUT request to the server and later on when I download
the document it's the Amazon S3 that tells me that its in fact binary/octet-stream in its response header.

However when using Safari, I noticed that for some reason the Content-Type header gets sent as an empty string
during upload - which results in the same behaviour during the subsequent download, which causes issues when I
try to download my Safari-uploaded file in those other browsers.

Is there some reason Safari/Webkit is behaving differently to other browsers in this regard?

cheers,
Greg

[youenn fablet]

SO, XMLHttpRequest implementation sets explicitly an empty string content type in case of a blob without mime type.
According the source code, it says that it is mandated by the file API spec.
I am wondering whether that still holds and what is the rationale here.

[youenn fablet]

According to https://xhr.spec.whatwg.org/#the-send()-method and https://fetch.spec.whatwg.org/#concept-bodyinit-extract, no Content-Type header should actually be sent in the case of a type-less blob.

[youenn fablet]

(In reply to comment #2)
> According to https://xhr.spec.whatwg.org/#the-send()-method and
> https://fetch.spec.whatwg.org/#concept-bodyinit-extract, no Content-Type
> header should actually be sent in the case of a type-less blob.

http://www.w3.org/TR/XMLHttpRequest/#the-send()-method also agrees with not sending an empty-string CT header in that case.

[youenn fablet]

Created attachment 282753 [details]
Test patch

[youenn fablet]

(In reply to comment #4)
> Created attachment 282753 [details]
> Test patch

The following patch solves the issue for soup-based ports.
It makes things worse for Mac-based ports as a "Content-Type: application/x-www-form-urlencoded" is added when none is provided. It might be the underlying HTTP library that does so when requested to upload some content.

[youenn fablet]

Greg, it might be the case that using PUT in lieu of POST might not cause that issue.
I am not sure whether that would work for your case, but just in case...

[Greg B]

Hi Youenn, can you please clarify what you mean by soup-based/Mac-based?
Personally I'm mostly after this behaviour corrected in Safari browser. Also, how do we get someone to review your patch and where to from here? In regards to your last comment, I was already using PUT request when I noticed the initial issue that I reported.

[youenn fablet]

(In reply to comment #7)
> Hi Youenn, can you please clarify what you mean by soup-based/Mac-based?
> Personally I'm mostly after this behaviour corrected in Safari browser.
> Also, how do we get someone to review your patch and where to from here? In
> regards to your last comment, I was already using PUT request when I noticed
> the initial issue that I reported.

The proposed patch calls for a change in the HTTP library below WebKit for Mac ports, hence Safari. Once updated, it will be time to review and hopefully land this patch.

[youenn fablet]

Created attachment 292587 [details]
Patch

[youenn fablet]

(In reply to comment #6)
> Greg, it might be the case that using PUT in lieu of POST might not cause
> that issue.
> I am not sure whether that would work for your case, but just in case...

OK, PUT with the above patch should work for you.
POST needs additional care at a layer below.

Latest patch tries to ship the change for PUT.

[youenn fablet]

rdar://problem/27173554

[Darin Adler]

Comment on attachment 292587 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=292587&action=review

> Source/WebCore/xml/XMLHttpRequest.cpp:574
> +            else if (m_method == "POST") {
> +                // See rdar://problem/27173554. CFNetwork will put a default Content-Type value if we do no set it, but only for POST.

Why would we have cross-platform code to work around a CFNetwork-specific bug?

[youenn fablet]

(In reply to comment #12)
> Comment on attachment 292587 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=292587&action=review
> 
> > Source/WebCore/xml/XMLHttpRequest.cpp:574
> > +            else if (m_method == "POST") {
> > +                // See rdar://problem/27173554. CFNetwork will put a default Content-Type value if we do no set it, but only for POST.
> 
> Why would we have cross-platform code to work around a CFNetwork-specific
> bug?

Agreed. I thought it was ok to progressively make the correct behavior accross all methods.
We can also improve this patch to fix it permanently in XHR and temporarily in CFNetwork binding code. This may be indeed nicer.

[Darin Adler]

(In reply to comment #13)
> I thought it was ok to progressively make the correct behavior
> accross all methods.

Sorry, I don’t understand what that means.

[youenn fablet]

There are different options:

- Option 1
Wait for CF Network to get fixed so that we can fully align with XHR spec and have no content-type set in all cases.
- Option 2
Align XHR to the spec for the methods that do not exhibit the CF network issue.
Status quo for the POST method.
- Option 3
Align XHR to the spec for all methods.
When CFNetwork gets updated, POST content-type will be fixed.
- Option 4
Align XHR to the spec for all methods.
Update CF network binding code to keep the status quo for the POST method.

I initially chose option 1, but option 2 allows to ship some improvements beneficial for all ports and many users even though CFNetwork does not ship the fix.

Option 3 is ok for a new API like fetch API, but for XHR, this does not seem right in terms of compatibility.

Option 4 would probably be nicer but we would need to apply this trick at the CF network platform code for XHR requests only (It is not appealing to apply this trick for fetch API requests).

[Rob Buis]

*** Bug 189886 has been marked as a duplicate of this bug. ***

[Rob Buis]

This seems like a duplicate of https://bugs.webkit.org/show_bug.cgi?id=211999, which is up for review.

[youenn fablet]

*** This bug has been marked as a duplicate of bug 211999 ***