Presentation from PHPNW13 on tools and best practice for debugging HTTP whether on web, mobile, APIs, or really anywhere else. Includes Wireshark, Charles and cURL
6 Stages of Debugging • DENIAL. That can’t happen. • FRUSTRATION. That doesn’t happen on my machine. • DISBELIEF. That shouldn’t happen. • TESTING. Why does that happen? • GOTCHA. Oh, I see. • RELIEF. How did that ever work? (see also: http://bash.org/?950581)
First Line of Defence: Browser Tools They have the answers to: • what is the source for this page? • which other assets were loaded? • did any requested assets fail? • what headers arrived with this response? • were any more calls made after the page loaded? • did any JavaScript errors occur?
Wireshark Takes a copy of the traffic passing through your network card(s), so you can easily inspect traffic. • quick way to observe without adding debug to your application • can use tcpdump to capture on a server, wireshark to inspect
Curl is Your Friend -X [verb] The verb to use for this request -H "[Header: value]" A header to send. Use as many times as needed -d [value] Either the whole body data as a string, a filename, or a key/value pair -s The "silent" switch, to hide curl's progress meter when piping the output to something else -c [filename] Where to store any incoming cookies for future use -b [filename] Cookies to send with the request -v to both body and headers, in the request and response
Debugging an API Problem Seeing the problem is usually harder than fixing • Can you reproduce the problem? • Start wireshark, inspect traffic • Use Curl to try simplest case, then step up
Charles Multi-platform Web Debugging Proxy http://www.charlesproxy.com/ • Observe requests • Firefox plugin • Change requests • Use Charles as a network proxy (detailed article: http://lrnja.net/ZuiDYJ)