Embedio: Critical issue in WebApi after upgrading to v2.2.1

[bufferUnderrun]

Describe the bug
After upgrading to v2.2.1 (v2.2.2 is also buggy), each request to the WebApi module throw an exception but the result is correctly return to browser.

Last working version : 2.2.0

To Reproduce
A simple snippet

```C#
using System;
using System.Threading;
using System.Threading.Tasks;
using Unosquare.Labs.EmbedIO;
using Unosquare.Labs.EmbedIO.Constants;
using Unosquare.Labs.EmbedIO.Modules;

namespace ConsoleApp1 {
class Program {
static void Main(string[] args) {

        var server = new WebServer("http://localhost:2393/", RoutingStrategy.Regex);

        server.RegisterModule(new WebApiModule());
        server.Module<WebApiModule>().RegisterController<TestController>();

        var cts = new CancellationTokenSource();
        var task = server.RunAsync(cts.Token);

        Console.ReadKey(true);
    }
} // end class

public class TestController : WebApiController {
    public TestController(IHttpContext context)
    : base(context) {
    }

    [WebApiHandler(HttpVerbs.Get, "/api/home/test")]
    public Task<bool> Test() {
        try {
            return this.JsonResponseAsync(new { test = "test" });
        }
        catch (Exception ex) {
            // an exception is thrown
            return this.JsonExceptionResponseAsync(ex);
        }
    }

} // end class

}
`` An exception will be thrown bythis.JsonResponseAsync` but a response will also be return to browser

Screenshots

https://pasteboard.co/HXVZh8y.png

Thanks

[geoperez]

What target framework did you use?

[geoperez]

I found the issue, let me run some tests.

[geoperez]

Please try to use new nuget version 2.2.3

[bufferUnderrun]

i'm waiting for the nuget indexing... end of work day, i will test this tomorrow.

[bufferUnderrun]

Your fix is working and you can close the issue.
Thanks !!

[bufferUnderrun]

Your fix lead to another critical issue... Please can you reopen the issue.

I have to downgrade to v2.2.0 and deploy in prod. I will explain in few minute.
From now, embedio does not return all data in some pages...

[geoperez]

Can you elaborate the issue?

[bufferUnderrun]

i use embedio as a restapi to return mostly json data.
At some point, the json data return by embedio is not correct in a sense all data have not been send but partially (approx 296Ko instead of a little more). The request take more than 15 sec (instead of 600ms) and the browser seems to stop the request...

No exception thrown by Embedio. I'm trying to take a wireshark capture to see what's really happen.

[geoperez]

How do you write the json to the response output?

On Fri, Jan 25, 2019, 8:26 AM bufferUnderrun <[email protected]
wrote:

i use embedio as a restapi to return mostly json data.
At some point, the json data return by embedio is not correct in a sense
all data have not been send but partially. The request take more than 15
sec (instead of 600ms) and the browser seems to stop the request...

No exception thrown by Embedio. I'm trying to take a wireshark capture to
see what's really happen.

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/unosquare/embedio/issues/237#issuecomment-457588936,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABsYsJYPL4V4OTx2PkwgkoFdpwKALJW8ks5vGxQzgaJpZM4aQ5_D
.

[bufferUnderrun]

data is serialized by newtonsoft.jsonnet then this string is passed tojsonsresponsasync() (via context.extension) which call stringresponseasync() (context.extension).

i can't reproduce the issue in each request... so difficult to send you details. And wireshark listen to loopback is a nightware. Trying other thing... The issue seems to appear when there is a certain amont of data (min 200Ko).

[geoperez]

We added a Gzip capability to the string response, maybe that's why. Try to check the last optional parameter and set false.

[geoperez]

Did you check the flag?

[geoperez]

I release a new version 2.2.4. I tried to reproduce the issue but it did not fail.

[geoperez]

Related to #239

[bufferUnderrun]

@geoperez yep, same as #239. So i've closed this issue and we will continue to 239.