Multipart post adding 2 bytes at the end of every byte array sent.

[Emanuel]

I am using FileParameter to send a byte array. so I send it using
empty file name (otherwise it doesn't work)

request.AddFile("stream", byteArray, false, string.Empty);

When I receive the byte array on server side I treat it like this:

Encoding.UTF8.GetBytes((string)Request.Form.stream)

The array I get in result is perfect except for 2 bytes, the last
ones, there is a carriage return and a new line.


It seams that for multipart forms RestSharp adds a footer.
I found this In Http.cs (Line 208)

private static string GetMultipartFooter ()
{
return string.Format ("--{0}--{1}", FormBoundary, _lineBreak);
}

So every time I send a byte array RestSharp addes a carriage return
and a new line (bytes: 13,10).

Why add a those 2 bytes to the footer for multipart-forms, is there
something I do not understand / am I using it wrong / is this a bug?

[Andrew Young]

The trailing CLRF is part of the multipart content-type spec. The encapsulation boundary should not be considered part of the content.

[Emanuel]

Thank you, I reviewed it and it's true, it is a problem between RestSharp and Nancy but it looks like it's more Nancy now that you mention it.

[Emanuel]

When looking deeper and comparing a post file from Nancy test framework vs the RestSharp client post file there is a difference:

RestSharp post (the way nancy receives it)

multipart/form-data; boundary=-----------------------------28947758029299

DATA

-------------------------------28947758029299--

Nancy post (the way nancy receives it)

multipart/form-data; boundary=--NancyMultiPartBoundary123124

DATA 

----NancyMultiPartBoundary123124--

[Emanuel]

Im just trying to figure out what needs to be fixed on RestSharp and/or Nancy so they are compatible for file transfer.

[Andrew Young]

Technically there is no difference in what you posted. The boundary value is specific only within the context of each individual request. In other words, the boundary value is irrelevant. Is there any other difference that you're seeing?

[Emanuel]

Yes RestSharp is adding a CR LF after the closing boundary.

I am not sure if this is part of the spec or not but I know Nancy is not expecting a CR LF after the closing boundary.

Here is the RFC spec http://www.ietf.org/rfc/rfc2046.txt section 5.1

It is not clear to me if the CR LF is mandatory or not.

[Andrew Young]

Looks like there was an effort to fix this but it was turned down. https://github.com/restsharp/RestSharp/pull/82

The spec you referenced as well as this one (http://www.w3.org/Protocols/rfc1341/7_2_Multipart.html) says the same thing. It says:

"There appears to be room for additional information prior to the first encapsulation boundary and following the final boundary. These areas should generally be left blank, and implementations should ignore anything that appears before the first boundary or after the last one."

The specification leaves room for data before and after the boundaries and that extraneous bits should be ignored. It might be better to leave it blank but not necessarily wrong. It sounds more like a problem with Nancy in that it isn't ignoring bits after the closing boundary.

[Emanuel Petre]

I think it is the most reasonable thing to assume too.

Thank you!

2012/3/9 Andrew Young <andrew...@gmail.com>

--
Emanuel Petre