I spent some time early this week trying to debug why some test was failing. It was using RESTeasy and I wanted to find out exactly what HTTP packets it was sending. If I was on a windows machine, I’d look towards Fiddler, but I couldn’t find anything easy on mac, so I wrote a little ruby script that I could point the client at and dump out all headers and request body.
It looks like this:
require 'webrick'
include WEBrick
class Simple < WEBrick::HTTPServlet::AbstractServlet
def do_POST(request, response)
puts "Body: " + request.body
puts "Header: " + request.raw_header.to_s
response.status = 200
end
end
server = HTTPServer.new(:Port => 5899)
server.mount "/", Simple
['TERM', 'INT'].each do |signal|
trap(signal){ server.shutdown }
end
server.start
Update
Upon publishing this, I got a couple of alternatives worth looking into for next time.
- Jim suggested using tcptrace; and
- Gaz suggested using the following command
sudo tcpdump -vvv -A -s 0 -i en1 tcp ‘port 5899’
This is just yet another example about why it’s important to have diversity when problem solving. I didn’t even know about these tools. Now I do and you do too.
Hey Pat,
Why not just use tcptrace?
Jim
@Jim because then poor Pat doesn’t get to code at all 😉
That’s because I didn’t know about it. Now I do. I’m guessing that this is the one you’re talking about?
maybe the tcpmon.jar (somewhere at apache) could have helped you here? I’ve used it a lot to reverse engineer undocumented http traffic 🙂
For general browser sniffing have a look at Charles Proxy too. It’s saved me *way* more money than it cost over the years.
Hi Markus,
I didn’t know about this one either. Looks good. I’ll give it a go next time.
Hi Chris,
I had a look at Charles proxy but it was a bit fiddly to set up. I’ll have to bookmark that one now too. Thanks!
Checkout paros and burp proxy, they r cool as well
Thanks. I’ll have to take a look at them too