Looking for guidance parsing one part of a multipart as raw data even though mime-type is tsv

We are currently running into an issue where we have a multipart-form request in which one part is standard json mime-type and the remaining parts are text/tab-separate-values but are encoded in a unique windows encoding. If we send these through the multipart parser, it looks like they will be read as ‘utf-8’ which loses certain characters our customers need in their data. Is there any sort of handling for a case like this? Appreciate any help!

[trevtrich]

thanks for the input! i was admittedly only at the research stage trying to verify if this would work for our problem, so haven’t integrated into our system quite yet.

as i dig more i’m a little disappointed in the browser support for even setting single form “part” header properties for input type=file, so that is still going to be an issue for us even once we do hash through this decision from the parsing/server side. either way, i wanted to make sure i wasn’t crazy in thinking the specs for this are relatively grey as of right now. if i come across any good information on the topic i’ll be sure to post back here. thanks again for the input! you’re free to close for now if you’d prefer until we learn of a “blessed” way to handle this.

if anyone comes across this in the future, right now our solution is to modify the input form on submission and override the mime-type of these files as octet-stream so it won’t be parsed as utf-8 server-side. best we’ve come up with thus far.

[tunnckoCore]

I found a very recent question in SO, https://stackoverflow.com/questions/7285372/is-content-transfer-encoding-an-http-header

From there, for such things should be used Transfer-Encoding and Content-Encoding? Soo… probably we don’t support it currently.