4 ms·

Tell HN: A small HTTP/REST dev utility I made. Hope you find it useful. Enjoy.

22 points by redsymbol 17y ago

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.
prodigal_erik 17y ago
Handy! But I urge you to keep a list of addresses which have opted in to receive email (just HMAC their address and send a challenge). Spammers will definitely try to abuse this, probably with ASCII art in their HTTP headers.
- redsymbol 17y ago
  Gotcha, thanks!
thwarted 17y ago
This is effectively the the output from the sample CGI application that prints the CGI environment variables, filtered for the ones that start with HTTP_. http://httpd.apache.org/docs/1.3/howto/cgi.html#whatsgoingonbehindthescenes http://httpd.apache.org/docs/1.3/howto/cgi.html#whatsgoingon... I believe the sample that came with the original NSCA was two lines, echo -e "Content-type: text/plain\r\n\r" and /bin/env. Sample code is now a web service.
labria 17y ago
Fails on CONNECT requests, and you should probably override the TRACE response, even if it means braking the protocol. It's for testing, after all =) And what's so REST about it? I would understand if it received requests to any url, then you could change the host in the application you're testing, but still keep the path.

22 points by redsymbol 17y ago

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.

prodigal_erik 17y ago

Handy! But I urge you to keep a list of addresses which have opted in to receive email (just HMAC their address and send a challenge). Spammers will definitely try to abuse this, probably with ASCII art in their HTTP headers.

redsymbol 17y ago
Gotcha, thanks!

thwarted 17y ago

This is effectively the the output from the sample CGI application that prints the CGI environment variables, filtered for the ones that start with HTTP_. http://httpd.apache.org/docs/1.3/howto/cgi.html#whatsgoingonbehindthescenes http://httpd.apache.org/docs/1.3/howto/cgi.html#whatsgoingon... I believe the sample that came with the original NSCA was two lines, echo -e "Content-type: text/plain\r\n\r" and /bin/env. Sample code is now a web service.

labria 17y ago

Fails on CONNECT requests, and you should probably override the TRACE response, even if it means braking the protocol. It's for testing, after all =) And what's so REST about it? I would understand if it received requests to any url, then you could change the host in the application you're testing, but still keep the path.