

Tell HN: A small HTTP/REST dev utility I made. Hope you find it useful. Enjoy. - redsymbol
http://whatheaders.com/

======
rdj
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
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/> for more details.

------
thwarted
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#whatsgoingon...](http://httpd.apache.org/docs/1.3/howto/cgi.html#whatsgoingonbehindthescenes)

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.

------
prodigal_erik
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
Gotcha, thanks!

------
labria
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.

