Skip to content

Tieantono/SlowRequestHandler

Repository files navigation

SlowRequestHandler

This repository demonstrates how to simulate and replicate the ASP.NET Core exception:

Reading the request body timed out due to data arriving too slowly. See MinRequestBodyDataRate.

Purpose

The project provides a simple ASP.NET Core server and a Node.js client that sends HTTP requests very slowly, byte by byte. This setup is designed to trigger the MinRequestBodyDataRate middleware in ASP.NET Core, which enforces a minimum data rate for incoming request bodies. If the data arrives too slowly, the server will throw a timeout exception. The default configurations for MinRequestBodyDataRate is 240 bytes/second with a 5 second grace period.

How It Works

  • Server: The ASP.NET Core application listens for POST requests on /slow-request-test.
  • Client: The Node.js script (slow-client.js) sends a JSON payload to the server, writing one chunk on every 5 seconds to simulate a slow client. You can also use slow-client-1.js to simulate sending 1 byte on every 500ms.
  • This slow transmission is intended to trigger the server's minimum request body data rate enforcement, resulting in a timeout exception.

Getting Started

Prerequisites

Setup

  1. Clone the repository:

    git clone https://github.com/Tieantono/SlowRequestHandler
    cd SlowRequestHandler
  2. Restore and build the ASP.NET Core server:

    dotnet restore
    dotnet build
    dotnet run

    The server will start on localhost:5145 (default).

  3. Run the slow client:

    cd client
    node slow-client.js

    This will send a POST request to /slow-request-test very slowly, simulating a problematic client. You can also use slow-client-1.js for simulating the slower one.

Customization

  • You can adjust the delay in client/slow-client.js by changing the interval (default: 5 seconds per chunk).
  • Modify the server's MinRequestBodyDataRate settings in Program.cs or appsettings.json to test different thresholds.
    • You can also try to set MinRequestBodyDataRate to null, but this is not recommended in production.

Conclusion

To actually solve this, the client and network must upheld and retain the consistent data transfer speed to the server, instead of forcing the server apps to actually bypass the configurations. Adjusting the value with respectable values supposedly good enough. However, beware that there might be a relative memory usage cost if we were about to change the value from the default one, especially due to the main concern of Slowloris type of attack: https://www.cloudflare.com/learning/ddos/ddos-attack-tools/slowloris.

References

These are the references links for all related discussions and articles about this issue:

About

A simple test project to simulate the ASP.NET Core Kestrel minimum request body data rate handling.

Resources

Stars

Watchers

Forks