CPURLConnection multipart/form-data POST problems

[Layton Duncan]

I'm having some problems with this HTTP POST request code, the form data never actually reaches the server. Is there anything obviously wrong with this code? This has been working up until upgrading to Safari 5 today.

Thanks,
Layton

var boundary = "----MISFormBoundaryMTCcH1pthhYPYEpV";

var httpBody = [[CPString alloc] init];
httpBody = [httpBody stringByAppendingFormat:"--%@\r\n", boundary];
httpBody = [httpBody stringByAppendingFormat:"Content-Disposition: form-data; name=\"fields\"\r\n\r\n%@\r\n", fields];
httpBody = [httpBody stringByAppendingFormat:"--%@\r\n", boundary];
httpBody = [httpBody stringByAppendingFormat:"Content-Disposition: form-data; name=\"calculations\"\r\n\r\n%@\r\n", calcs];
httpBody = [httpBody stringByAppendingFormat:"--%@\r\n", boundary];
httpBody = [httpBody stringByAppendingFormat:"Content-Disposition: form-data; name=\"table\"\r\n\r\n%@\r\n", table];
httpBody = [httpBody stringByAppendingFormat:"--%@\r\n", boundary];
httpBody = [httpBody stringByAppendingFormat:"Content-Disposition: form-data; name=\"query\"\r\n\r\n%@\r\n", query];
httpBody = [httpBody stringByAppendingFormat:"--%@--\r\n", boundary];

var request = [CPURLRequest requestWithURL: "http://domain/get_records_and_calculations.php"];
[request setHTTPMethod:"POST"];
[request setValue:"multipart/form-data; boundary=----MISFormBoundaryMTCcH1pthhYPYEpV" forHTTPHeaderField:"Content-Type"];
[request setHTTPBody:httpBody];
_setValueConnection = [CPURLConnection connectionWithRequest:request delegate:delegate];

[ajumell]

Try using "application/x-www-form-urlencoded;" as Content-Type. It
may work.

[Layton Duncan]

That sounds like a horrible hack. The post data doesn't match that content type anyway. I'd prefer not to change the body format either. Seems strange that this fails on Safari 5 but works fine pre 5

Must be something in the way i'm using it.

Layton

> --
> You received this message because you are subscribed to the Google Groups "Cappuccino & Objective-J" group.
> To post to this group, send email to objec...@googlegroups.com.
> To unsubscribe from this group, send email to objectivej+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/objectivej?hl=en.
>

[Ross Boucher]

Possibly try upgrading, a few things were changed in CPURLConnection last week.

[ajumell]

Sorry. I am not an expert. When i was trying to send data using POST
method I could not read it at the server at first. Then I used the
"application/x-www-form-urlencoded;" as Content-Type and it worked. So
I mentioned it. If I am wrong I am extremely sorry about it.

[Layton Duncan]

Bug still persists with latest master.

I've done some sniffing and comparing Safari 5 with 4.0.2, it seems Safari 5 is injecting "; charset=UTF-8" to the end of Content-Type header.

I've tracked it down to the "; charset=UTF-8" appended to the Content-Type which is causing the problem. Intercepting the request using a proxy and removing the "; charset=UFT-8" from the Content-Type header before it's sent to the server results in a successful response from the server.

So the question is, is this a Safari bug? Or *should* injecting the charset parameter still work, in which case it's an Apache bug?

Layton

[Ross Boucher]

Two things worth checking:

If you add the charset in Safari 4 yourself, does it also fail?

Does it work with another server?

[Layton Duncan]

> If you add the charset in Safari 4 yourself, does it also fail?

Affirmative

> Does it work with another server?

Bit of a mission to test that to be honest. But ironically, this is Safari 5 talking to latest OS X Server (almost) default Apache2 install. Maybe it's apache not expecting UTF-8? Although interestingly Charles proxy can't parse the form parts when the charset is set by Safari.

[Layton Duncan]

Interestingly, submitting a basic html form using POST and enctype="multipart/form-data" results is no charset=utf-8 injection.

It's looking like this injection when the Content-Type is multipart/form-data is a bug, and should not be happening?

[Layton Duncan]

OK, got this working. Seems it's sensitive to the position of the charset parameter. Specifically manuall inserting it before the boundary value results in a working request:

[request setValue:"multipart/form-data; charset=UTF-8; boundary=----MISFormBoundaryMTCcH1pthhYPYEpV" forHTTPHeaderField:"Content-Type"];

On 21/06/2010, at 1:29 PM, Ross Boucher wrote:

[Layton Duncan]

For those interested, this seems to have been accepted as a WebKit regression bug: https://bugs.webkit.org/show_bug.cgi?id=40947