Ethernet context.Request.InputStream (TinyCLR 2.2.1.2000) returns unwanted bytes

TinyCLR OS
1

Recently I tested my code with the latest TinyCLR release (2.2.1.2000) and I found a bug in the ethernet function.

When the device receives a “POST” command, I check the “context.Request.RawUrl.ToUpper()” content, if it contains a file upload request, I check the “Content-length” value, I create a buffer of this length and I read the chunks to fill the buffer:

…
int len = int.Parse(context.Request.Headers[“Content-Length”]);
byte buffer = new byte[len];

int index = 0;
while (index < len)
{
int leng = (int)context.Request.InputStream.Length;

context.Request.InputStream.Read(buffer, index, leng);

index += leng;

}
…
This method works perfectly with the older version of the TinyCLR (2.2.0.5100).

With the new TinyCLR, the InputStream.Read(…) instruction returns more than the “Content-Length” bytes (and that causes an error as I’m trying to write to the “buffer” outside of its boundaries.
In order to find out why, I “expanded” the buffer size to read all the data and found that in the buffer there is sometimes an unwanted sequence of bytes, in my case this: “------WebKitFormBoundaryLeVuml8JE0325V6D Content-Disposition: form-data; name="uploadFi” string
that repeats several times and so the sent file is dirty and longer than it should be.

For the moment, I must stay with the old version of TinyCLR.

Please let me know when a solution to this problem will be available.

Thank you in advance for any help.

Vittorio

2

We will take a look. Could you check if you are having same problem with this: HttpWebRequest return only partial of data - TinyCLR OS - GHI Electronics’ Forums

3

Hi Dat,
I don’t use the HttpWebRequest in my implementation. I use the HttpListener. Upon a request (listener != null) I get the context and I start a thread that manages the request (where I set/check the cookies, I test the method and I handle the “POST” and “GET” requests checking the “context.Request.RawUrl” content. With TinyCLR 2.2.0.5100 it works like a charme. With 2.2.1.2000 I find extra characters in the input stream. In fact, I receive more bytes than the quantity given in the “Content-Length” attribute. The position of the extra bytes is not always the same.

Thank you,
Vittorio

4

Hello, we have checked this issue and sorry to say: “Could not reproduce”.

Could you please provide a simple code that we can reproduce? Base on your information, we made a simple test and it looks good to us

SITCore:

static void DoTestHttpListener()
{
    //Create a listener.
    HttpListener listener = new HttpListener("http", 80);
    listener.Start();

    Debug.WriteLine("Start listening...");

    while (true)
    {
        try
        {
            var context = listener.GetContext();

            var inputStream = context.Request.InputStream;
            var bytes = new byte[inputStream.Length];
            var read = inputStream.Read(bytes, 0, (int)inputStream.Length);

            Debug.WriteLine(string.Format("read {0}", read));

        }
        catch (Exception)
        {

        }

        Thread.Sleep(10);
    }
}

PC:

static async void DoTestHttpClient()
{
    var client = new HttpClient();
    client.BaseAddress = new Uri("http://192.168.86.100");

    await using var stream = System.IO.File.OpenRead("./ola.bin");
    using var request = new HttpRequestMessage(HttpMethod.Post, "file");

    using var content = new MultipartFormDataContent
    {
        { new StreamContent(stream), "file", "ola.bin" }
    };

    var result = Task.Run(() => {

        request.Content = content;
        client.SendAsync(request);
        
        Console.WriteLine("Done");

    });

    Thread.Sleep(-1);    
}

And result is 441 as we tested:

Send:

image
image2106×773 106 KB

Received and read:
image

We need you to provide simple code to see the issue.