3 ms·

Not sure I get it. It seems to me that the headers are always going to be the same when I use your page (maybe an exception would be the referer.) For technica

by rdj 17y ago

Not sure I get it. It seems to me that the headers are always going to be the same when I use your page (maybe an exception would be the referer.) For technical feedback: you have a bug. The request isn't displaying properly. It showed mine as: GET HTTP/1.1 accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 accept-charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 accept-encoding: gzip,deflate accept-language: en-us,en;q=0.5 connection: keep-alive host: whatheaders.com keep-alive: 115 referer: http://news.ycombinator.com/ user-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 (.NET CLR 3.5.30729) Notice the "GET HTTP/1.1". It should probably read "GET / HTTP/1.1"

redsymbol 17y ago
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.
aditya 17y ago
Unless you have a lying browser. ;) Actually, this is super helpful especially on a mobile device that you're trying to debug with.

by rdj 17y ago

redsymbol 17y ago

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.

aditya 17y ago

Unless you have a lying browser. ;) Actually, this is super helpful especially on a mobile device that you're trying to debug with.