Dump Request

This page echoes the HTTP request the server just received from you. Nothing is stored or logged by this page; reload it and you get a fresh dump.

Request line

GET /dumprequest HTTP/1.1

Headers your client sent

Accept*/*
Accept-Encodinggzip, br
Hostdjce.org.uk
Refererhttps://djce.org.uk/dumprequest.html
User-AgentMozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; [email protected])

Connection

Your IP address216.73.216.6
Schemehttps
MethodGET

Headers added on the way

These were not sent by your browser. The CDN in front of this server adds them before passing the request on, which is also why the real client address arrives in a header.

cdn-loopcloudflare; loops=1
cf-connecting-ip216.73.216.6
cf-ipcountryUS
cf-raya40687fa5ab11cc4-CMH
cf-visitor{"scheme":"https"}
X-Forwarded-For216.73.216.6
x-forwarded-protohttps

Try it

Send a GET or a POST and see how the dump changes.

From a script: curl -s "https://djce.org.uk/dumprequest?format=text" returns the same dump as plain text. Add -H "X-Test: 1", -A "my-agent" or -d "a=b" and watch it appear.

What you are looking at

An HTTP request is a request line (method, path, protocol version), a block of headers, and sometimes a body. Host names the site you asked for, User-Agent identifies your client, the Accept family says which formats, languages and encodings you can take, Referer is the page that linked you here, and Cookie carries whatever this site set earlier. A GET puts its parameters in the URL; a POST puts them in the body, with Content-Type and Content-Length describing it.

When a request passes through a proxy, load balancer or CDN, the server sees the proxy's address, not yours. The original address travels in a header such as X-Forwarded-For. Those headers are easy to forge when no trusted proxy sets them, so code that reads a client IP from a header should only do so for requests that really came from its own proxy.