Thanks for the feedback. Re the request path, that was intentional: since the path will always be "/", I didn't see a good reason to explicitly print it; and i

Thanks for the feedback. Re the request path, that was intentional: since the path will always be "/", I didn't see a good reason to explicitly print it; and instead just show the request method and protocol version. That said, I get your point: it's a bit surprising, so will consider modifying it. As for how it's useful: Whatheaders.com is interesting and useful when you are working with some "black box" HTTP client, and which you cannot conveniently know what request headers it is sending. In particular, mobile-device web browsers, which are wildly divergent, capricious, and undocumented in their behavior; sometimes the only way to know what they are doing is to measure it directly. That's why I made it originally, in fact. I imagine it would be similarly useful with any other kind of proprietary HTTP or REST tool or library if you don't have access to the source, and need to know exactly what headers it's sending in order to troubleshoot, etc. For something like Firefox with (e.g.) livehttpheaders installed, or standard vanilla web browsers like IE or Safari, IMO whatheaders.com isn't terribly interesting. Be sure to read http://whatheaders.com/about/ http://whatheaders.com/about/ for more details.