HTTP POST Test

Use the forms below to send a test message or upload a file to dlptest.com using the HTTP POST method over plain, unencrypted HTTP — no TLS. Load this page and submit the form over http:// and the request stays cleartext on the wire, which is what you want when testing a network tap, passive Network Monitor, or any control that inspects traffic without decrypting it. The server accepts the request and discards the body. No data is logged, stored, or forwarded.

Need to test a control that decrypts TLS instead (an SSL-inspecting proxy, ICAP integration, or SSE/SASE agent)? Use the HTTPS POST test.

Test with curl or scripts

The accept-and-discard endpoint is /api/http-post/. You can POST any body (form data, JSON, raw bytes, multipart). Responses are JSON with an ok field (true when the body was accepted). GET on the same URL returns a short JSON hint. Cross-origin use from automation or in-browser fetch from another origin is allowed via permissive CORS on this route only.

Examples (use your own hostname for staging or production):

# Probe the endpoint
curl -sS "http://dlptest.com/api/http-post/"

# Small form-style body
curl -sS -X POST "http://dlptest.com/api/http-post/" \
  -d "message=DLP+POST+test"

# JSON body
curl -sS -X POST "http://dlptest.com/api/http-post/" \
  -H "Content-Type: application/json" \
  -d '{"note":"sample payload"}'

# Raw file (single part; good for scripted throughput checks)
curl -sS -X POST "http://dlptest.com/api/http-post/" \
  --data-binary @./your-local-file.bin

Keeping your browser on http://

This site does not enforce HSTS, so it never instructs a browser to upgrade to HTTPS. However, some browsers upgrade http:// on their own — even when you type the scheme explicitly — because the site also answers on HTTPS. What to expect:

Chrome / Edge: an explicitly typed http:// URL loads in cleartext by default (the address bar shows "Not Secure" — that's your confirmation). Bare domains typed without a scheme may be auto-tried over HTTPS first, so include the http:// prefix.
Brave: upgrades even explicit http:// URLs by default (Shields' "Use secure connections"), including in private windows. To test cleartext, click the Brave Shields lion icon on this page and turn off Use secure connections for this site, or change the global default at brave://settings/shields.
Firefox: private windows use HTTPS-First by default, and it only falls back to HTTP when the HTTPS attempt fails — which it won't here. Use a normal window, or add an exception if HTTPS-Only Mode is enabled at about:preferences#privacy.
Safari: upgrades automatically when it knows a site supports HTTPS and offers no per-site override — use another browser, curl, or a script for cleartext testing.

If your browser cached an HSTS policy for this domain from before mid-2026 (when this site sent one), one HTTPS visit now clears it automatically (we send max-age=0), or delete it manually at chrome://net-internals/#hsts under "Delete domain security policies". Whichever browser you use, confirm the request was really cleartext on the wire with a packet capture or your inspection tool's own logs — an address bar reading http:// plus "Not Secure" is a good sign, but the wire is the truth.

What is an HTTP POST?

HTTP POST is a request method in the HTTP protocol. A POST asks a server to accept an entity in the request body. Forms in browsers, REST APIs, and file uploads typically use POST when they send data that is not idempotent or that does not fit cleanly in the URL.

Why test over plain HTTP

Most modern traffic is encrypted, and it's tempting to treat a TLS-decrypting control as equivalent to one that inspects cleartext. In practice they're different controls with different failure modes, and auditors and regulators often expect continuous testing to exercise both — especially for controls (network taps, passive Network Monitors, some legacy proxies) that were never designed to decrypt TLS at all. This page gives you a stable, safe target for that specific test.

How dlptest.com uses POST

This site does not store or process your test payloads. The Worker reads the request body so the bytes traverse the network fully (so inspection appliances can see them), then discards them. That makes POST here a safe pattern for validating Data Loss Prevention rules, ICAP integrations, and network-based inspection, without sending real customer data to a third party that would retain it.