Giters

jbittel / httpry

HTTP logging and information retrieval tool

Home Page:dumpsterventures.com/jason/httpry

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Doesn't work on OS X

joshgoebel opened this issue · comments

commented

Should this work on OS X? tcpdump gives me tons of output but httpry never shows anything at all... but does give a package count when quitting such as:

95 packets received, 0 packets dropped, 0 http packets parsed
commented

Yes, it certainly should work on OSX and has been tested there as well. Is there any kind of proxy or VLAN in use that might require changes to the default capture filter? The fact that it does show packets received means it is seeing some traffic, but nothing it recognizes as HTTP.

If you have a capture file from tcpdump that has known HTTP traffic in it, that might help narrow down faster why httpry isn't picking anything up.

Thanks!

commented

Using httpry as built by homebrew, and seeing the same issue. I created a test file:

echo "<html><body>Hello World</body></html>" > test.html

Started up a python web server:

python -m SimpleHTTPServer 8000

.. and httpry doesn't see the conversation (httpry -i lo0 'port 8000'). There's a packet dump here: https://www.dropbox.com/s/c6fccfflwm6viel/packets.pcap.

Thanks!

commented

Interesting...thanks for the additional information, that was very helpful in replicating this issue. It appears the problem is caused by buffering outside of httpry which causes it to not see the packets at all. In fact, if you make numerous requests to the loopback server to the point where that buffer fills, all of the packets will be parsed and output as expected.

I'll have to look into this further to see where the buffering occurs, as I haven't been able to replicate it on other platforms. Thanks!

commented

Jason -- No worries, thanks for looking into this. FWIW, I'm not seeing the same issues with Wireshark or CocoaPacketAnalyzer.. I'm happy to help debug this, let me know if I can be of help.

commented

I think I found the culprit on this issue, and I've pushed 1cf877d which resolves it in my testing. It appears the problem was that the read timeout was disabled, which caused some platforms to wait until a sufficient number of packets have arrived before being processed.

If you could verify that it's working as expected on your end as well, I would appreciate it. Thanks!