CODEWITHSUNDEEP
c#httpresponsemultipartform-data
Scott Brickey
Scott Brickey

Reputation: 1227

C# Reading MultiPart response contents as they arrive

I've got a WebApi method that will receive multipart data. Current implementation uses a MultipartMemoryStreamProvider to receive the contents.

I'd like to ensure that certain parts are received before others (aka, file hash before file contents). Unfortunately, from what I can tell of the framework, the HttpContentMultipartExtensions instantiate a MimeMultipartParser to the HttpContent's response stream... the MimeMultipartParser uses the provided StreamProvider to instantiate new streams as the data arrives... but there appears to be no notification / eventing as the parser switches from the previous stream to the next.

By using events, I can queue the file's hash (before the file contents arrive), pump the file contents onto a file, and be confirming the hash while the next file's hash/contents are arriving.

Unfortunately, every example and bit of code I see, suggests that I can only access the content streams after they are complete. (I do see that MimeMultipartBodyPartParser's ParseBuffer yields its returned MimeBodyParts, I just didn't see any way to access it, since it only appeared to be called from the private MultipartReadAsyncComplete)

Am I missing something? Is there a better way?

Upvotes: 3

Views: 951

Answers (1)

Ed Huber
Ed Huber

Reputation: 116

I would not try to solve MITM attacks in the MIME parsing code itself, as the MITM is an attack inserted in part of the architecture.

There are topologies and proven solutions such as multifactor or SSL that will allow your client to determine the validity of the session and sender of the content.

Like Evk states, if your architecture is susceptible to MITM, then you need to look at the security of the connection end to end, not a validation of the MIME data on receipt. If you are concerned about the security of the data, then you need to consider encryption of the data, and using non-opaque encryption techniques (not signing), which would prevent manipulation in transit, and allow the client to decrypt the message on receipt.

If securing the connection between client and server to avoid MITM does not work for you, maybe you could explain the constraints on your architecture so that we can provide better answers.

Upvotes: 3

Related Questions