So the problem is that if the charset comes before the boundary param PHP is OK, and if it comes after the boundary param PHP shows its "MIME spec, what MIME spec?" colors once more? I guess we can try to move the charset param around... blizzard, shaver sez you can follow this up with the PHP folks?
So one option here is to have extractCharsetFromContentType set the charset position to right after the winning type if that winning type has no charset param. That would guarantee that the charset= comes before the boundary=. Christian, what do you think of that approach?
Moving to blocking p1 because of web compat
Assigning to Jonas.
The solution in comment 2 sounds like a good one FWIW. Why can't people just parse their MIME correctly :(
It seems that PHP parses headers according to obsoleted RFC 1867 where comma is mentioned as separator (section 6, Examples). Parsing of header is not too smart - it looks for substring "boundary" and then try to trim everything from next comma to end of line. This is the reason, why charset before boundary doesn't bother.
Uh... the examples section there is non-normative, and doesn't actually follow the MIME RFCs relevant at the time... I'd certainly hope no one wrote a parser based on the examples section. :( Clearly I hope in vain....
Another, possibly simpler and maybe more correct, solution is to just not append a charset at all for multipart/form-data, since the type isn't actually defined to have such a parameter. It's the responsibility of the data creator to set the charset on each part individually... Ideally there would be a simple way to tell from the type whether it wants a charset param, but there isn't. So we'd have to just hardcode the "multipart/form-data".
I managed to solve it by simply adding the charset myself before the boundary... it seems that php was taking the charset as part of the boundary string the below should fix the trick http_request.setRequestHeader("Content-Type", "multipart/form-data; charset=utf-8; boundary=---------------------------" + border);
Please not that the duplicate (and closed) Bug 416178 is more general: it affects normal XHR requests of form posts that have the standard application/x-www-form-urlencoded encoding. The appended charset= breaks many webservers and is thus considered a bad-thing-on-the-web(tm), although the HTTP spec allows it. There is *no* workaround for it and this bug will break some Ajax apps out there.
Jonas, any progress on this one?
Smaug: You have the cycles for this one?
Created attachment 304679 [details] [diff] [review] Fix
Created attachment 304680 [details] [diff] [review] Same without the extra test in the makefile
Comment on attachment 304680 [details] [diff] [review] Same without the extra test in the makefile Looks good. Feel free to land, but it wouldn't hurt to get biesis input too at some point.
The network stuff really needs review from biesi before I'd be comfortable landing it.
+ charsetStart = flatStr.Length(); should have just one space
10 years ago
Comment on attachment 304680 [details] [diff] [review] Same without the extra test in the makefile Requesting approval. I think we want to fix this for the beta... Risk should be pretty low, win is reasonably big.
Comment on attachment 304680 [details] [diff] [review] Same without the extra test in the makefile a1.9b4=beltzner
Does not fix bug 416178.