Content-Transfer-Encoding in file uploading request

Question

I'm trying to upload file, using XMLHTTPRequest, and sending this headers:

Content-Type:multipart/form-data, boundary=xxxxxxxxx

--xxxxxxxxx
Content-Disposition: form-data; name='uploadfile'; filename='123_logo.jpg'
Content-Transfer-Encoding: base64
Content-Type: image/jpeg
/*base64data*/

But on server side PHP ignore header "Content-Transfer-Encoding: base64" and write base64 undecoded data directly into the file!

Is there any way to fix it?

p.s. it is very important to send data using base64

Solution 1

My previous answer was wrong

Content-Transfer-Encoding may appear in the a composite body

http://www.ietf.org/rfc/rfc2616.txt

There are several consequences of this. The entity-body for composite types MAY contain many body-parts, each with its own MIME and HTTP headers (including Content-MD5, Content-Transfer-Encoding, and Content-Encoding headers).

Solution 2

Xavier's answer doesn't sound right. RFC2616 also has this to say (section 3.7):

In general, HTTP treats a multipart message-body no differently than
any other media type: strictly as payload. The one exception is the
"multipart/byteranges"

It seems to me that section 19.4 of RFC2616 is talking about HTTP as a whole, in the sense that it uses a syntax similar to MIME (like headers format), but is not MIME-compliant.

Also, there is RFC2388. In section 3, last paragraph, it says:

Each part may be encoded and the "content-transfer-encoding" header
supplied if the value of that part does not conform to the default
encoding.

Section 4.3 elaborates on this:

4.3 Encoding

While the HTTP protocol can transport arbitrary binary data, the default for mail transport is the 7BIT encoding. The value supplied for a part may need to be encoded and the "content-transfer-encoding" header supplied if the value does not conform to the default encoding. [See section 5 of RFC 2046 for more details.]

Comments

[Scalar]

Thnx! Using base64_decode is very ugly method, but i think i have no other choice.

[mario]

The older RFC1867 for multipart/form-data is probably also relevant. It mentions Content-Transfer-Encoding for mail transports, but there's no need in HTTP. This is why PHPs rfc1867.c does not honor it.

[al45tair]

Agreed. This is definitely a bug in PHP. Both the W3C HTML docs and the RFCs you highlight make quite clear that in a POST response to a form, Content-Transfer-Encoding may be used. This makes sense because otherwise text fields might inadvertently include a MIME boundary sequence, and would all have to be sent in binary with a Content-Length.

[Admin]

This isn't a "bug" in PHP, nor is it particular to PHP. From my research into this, it appears multipart POST is a complete mess, IETF RFC are mostly useless and needs to be updated. RFC 2388 needs to be completely overhauled, so does HTML 4.01's w3.org/TR/html401/interact/forms.html reference. Basically. No modern UA use content-transfer-encoding, you must use content-type to determine the encoding. Not only that, charsets is assumed to be the same as the initial requested form's charset, and "multipart/mixed" for multiple files is not used. Just as well; KISS.

[Joakim Erdfelt]

The updated spec datatracker.ietf.org/doc/html/rfc7578#section-4.7 also drops Content-Transfer-Encoding header.