TRACE
Performs a message loop-back test along the path to the target resource, echoing the received request.
What it does
TRACE asks the final server (or an intermediate proxy) to echo back the exact request it received, verbatim, as the body of the response. It's a diagnostic tool — the idea is to let a client see how the request looked by the time it arrived, after passing through however many proxies sit in between, so you can spot where headers got mangled, added, or stripped along the way.
In practice, TRACE has fallen almost entirely out of use — and for security reasons, it's disabled on most production servers today.
Semantics
| Property | Value | Why it matters |
|---|---|---|
| Safe | Yes | Diagnostic only, no state change intended |
| Idempotent | Yes | Repeating gets the same echo behavior |
| Cacheable | No | The response is specific to the exact request sent, never reusable |
| Request body | Must not have one | Per spec, a TRACE request must not include a body |
| Response body | Yes | The echoed request, verbatim, as message/http content |
Syntax & example request
TRACE /diagnostics HTTP/1.1
Host: example.com
X-Custom-Header: test-value
HTTP/1.1 200 OK
Content-Type: message/http
TRACE /diagnostics HTTP/1.1
Host: example.com
X-Custom-Header: test-value
The response body is literally the request the server received — useful for spotting proxy interference, but only if TRACE is even enabled.
curl example
curl -X TRACE https://example.com/diagnostics -i
(On most modern servers, expect a 405 Method Not Allowed here — see below.)
Common status codes returned
- 200 OK — request echoed back successfully → see 200
- In practice, far more commonly a 405 Method Not Allowed or connection refusal, because most servers disable TRACE entirely
TRACE vs OPTIONS
| TRACE | OPTIONS | |
|---|---|---|
| Purpose | "Show me exactly what you received" | "Tell me what you support" |
| Response content | Echo of the raw request | List of allowed methods/headers |
| Modern usage | Rare, mostly disabled | Common (CORS preflight) |
Both are safe, diagnostic-flavored methods — but only one of them survived into mainstream use.
Real-world usage
Almost none, deliberately. TRACE is the textbook example of a method that's technically still part of the spec but that security guidance universally recommends disabling. Vulnerability scanners (Nessus, OWASP ZAP) flag TRACE as enabled specifically because of the attack described below.
Security considerations
TRACE is the poster child for Cross-Site Tracing (XST) — if a server has TRACE enabled, and an attacker can get a victim's browser to issue a TRACE request (via a script, in browsers old enough to allow it), the echoed response can leak cookies and authentication headers that JavaScript would otherwise be blocked from reading directly (like HttpOnly cookies), because the server just echoes back whatever the browser attached to the request.
Because of this, TRACE is disabled by default or explicitly turned off on virtually every production web server (Apache, Nginx, IIS) and blocked at the WAF level in most security hardening guides. If a security scan flags TRACE as enabled on your server, disable it — there's essentially no legitimate production use case that outweighs the risk.
FAQ
Should I ever enable TRACE in production?
No. It's a diagnostic method with a well-known attack vector (Cross-Site Tracing) and virtually no legitimate use case that a well-configured proxy log or diagnostic endpoint can't replace more safely.
Why does TRACE return a body when GET-family methods emphasize safety over data return?
TRACE's entire purpose is the returned data — it's not "read a resource," it's "show me the request as you saw it." The safety property just means the act of asking doesn't change server state, not that the response is trivial.
Is TRACE the same as network-level traceroute?
No — despite the similar name, traceroute (or tracert) is a network-layer (IP/ICMP) tool for mapping the hops a packet takes to a destination. HTTP TRACE operates entirely at the application layer and only tells you what one specific server received, not the network path.
Fun fact
TRACE's near-universal disablement means it holds an unusual title: it's likely the most widely implemented but deliberately turned off method in the entire HTTP spec — supported by virtually every major web server's codebase, yet switched off by default or via hardening guides almost everywhere it matters.