How to set my own boundary on multipart/form-data

I have been trying to find out a way to set my own boundary on an XMLHttpRequest object when using the FormData object to append files to a request. I've seen multiple posts on this and everyone says "just don't set the boundary and it will automatically generate for you." This is NOT what I want. Let me explain what I need so I don't get these kinds of responses.

I have a web service endpoint to which I send a multipart/form-data request with two images and some json data. Since WCF doesn't have any way to parse through a multipart request, I built my own parser using some open source code. The way it works is, I define a boundary which is used for separating each section of the request and from there everything works hunky dory. As such, I have to be able to set the boundary to exactly what the server code expects in order for my parsing classes to be able to find anything in the input stream.

I know this can be done because I've done so using Fiddler and a coworker is able to do so in the app we are building which calls my method, but I'm trying to get it working using a Chrome browser app called Postman which sends multipart requests using the FormData object. It is working other than the fact that the requests generate their own boundary which usually is something like:

----WebKitFormBoundaryQUWQnB6c7TzNzdcz

And the appended string on the end is randomly generated so its never the same, hence I can not use this tool to test my endpoint because the server has no way of knowing what boundary to look for.

I've tried setting the Content-Type header with my boundary in it and while the request shows the header being added to the request, the body still uses the random boundary.

So the question is how can I tell the FormData object and/or the XMLHttpRequest object to use my boundary instead of the random one that is being generated?

I can't imagine this is an uncommon thing to want to do, I mean up until now all my experience calling services that use multipart/form-data tell me what to set the boundary to in the api and nobody has said "just don't set it and we'll use the random junk that is generated..."

Also as a visual, here is what I'm seeing in the headers:

Request Headers
POST /DHICachet.svc/json/DepositCheck HTTP/1.1
Host: dhiibews.securexfr.com
Connection: keep-alive
Content-Length: 514696
Origin: chrome-extension://fdmmgilgnpjigdojojpjoooidkmcomcm
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.64 Safari/537.11
Content-Type: multipart/form-data; boundary=myboundary
Cache-Control: no-cache
Accept: */*
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Cookie: ASP.NET_SessionId=zdepe2nhkz0vbhxiulzc2qq1

Request Payload
------WebKitFormBoundaryQUWQnB6c7TzNzdcz
Content-Disposition: form-data; name="item"; filename="Screen shot 2012-09-03 at 4.00.10 AM.png"
Content-Type: image/png


------WebKitFormBoundaryQUWQnB6c7TzNzdcz--

Notice that even though my boundary is set to myboundary in the request header, the body just puts whatever boundary is generated behind the scenes in. Also note that if I don't set that header it just puts it in with the random boundary in it.

回答1:

This doesn't really answer my question, but I did find a work around. It dawned on me that I could actually detect the boundary that was coming through by doing some string math on the content-type header. I just added the following to my code:

string contenttype = _ctx.IncomingRequest.Headers["Content-Type"].ToString();
string boundary = contenttype.Substring(contenttype.IndexOf('=') + 1);

This allows me to accept any boundary for debugging. I will still require our specific boundary for production however.

回答2:

I had a similar issue and for me setting content type header to undefined when doing the post fixed the issue... 'Content-Type': undefined

I belive browser automatically handles POST of FormData correctly and sets the Content-type header for you expected, including the boundary if unset. So this means no need of special parsing logic of request headers on server.