ddos-sim.com All simulations Build a test plan

Layer 7 · Application · slow_post

Slow POST (RUDY) test

The slow_post simulation opens TLS connections that announce a large request body and then deliver it one byte at a time — the R-U-Dead-Yet (RUDY) pattern — against a domain you own, so you can see how long your request-reader pool survives a trickle.

Layer L7 Protocol HTTP/TLS Command slow_post Access Quote on request

What a Slow POST (RUDY) attack does

RUDY sends an HTTP POST advertising a large Content-Length, then trickles the body one byte at a time. Each connection ties up a server thread or goroutine waiting for a body that never finishes, so a handful of connections can exhaust the request-reader pool with almost no bandwidth. It is the request-body counterpart to Slowloris, which drips the request headers instead.

How ddos-sim.com simulates it safely

ddos-sim.com completes a real TLS handshake to a single verified domain pinned to a public address, sends a fixed POST preamble, and drips a fixed filler byte within the rate and concurrency limits for that domain. Nothing you supply is sent — the request is not configurable — so it cannot become a request-smuggling or arbitrary-payload primitive.

Authorized targets only

Every run is bound to one verified domain you have proven you own. Ownership is checked over HTTPS before anything is scheduled, and running traffic against systems you do not own or are not clearly authorized to test may be unlawful. See the Acceptable Use Policy.

What the test exercises

  • Request-body read timeouts and idle-connection handling
  • Per-connection request-reader pool limits
  • Whether a reverse proxy buffers the full body before the origin sees it
  • Concurrency caps that specifically target slow clients
  • How quickly capacity recovers once the connections are dropped

How to run a slow POST test

  1. Verify your domain. Prove ownership over HTTPS — it is self-service and takes minutes.
  2. Add the slow_post command to a timeline in the portal and set the rate, duration, and any concurrency limit.
  3. Set health thresholds. Choose the error-rate, latency, or status-code limits at which the test should abort itself.
  4. Run and watch. Bounded workers are provisioned minutes before start and torn down the moment the last task ends, while metrics stream live.
  5. Read the results. Review the recorded latency, status codes, and worker timeline to find where your service starts to bend.

Configure a slow POST test in the portal →

Availability & limits

Slow POST is priced per engagement — request a quote. Verify your domain before it runs.

Frequently asked questions

How is this different from Slowloris?

Slowloris drips the request headers and never finishes them; Slow POST (RUDY) completes the headers and then drips the body, exercising the body-read path and any request buffering instead.

Does it send my data?

No. The body is fixed filler bytes and the request line is not configurable, so nothing you provide is transmitted.

Rehearse a slow POST test against infrastructure you own — bounded, monitored, and stopped the instant you have your answer.

Build a test plan
← All DDoS simulations