Hi, I’m Mark Nottingham. I currently co-chair the IETF HTTP and QUIC Working Groups, and am a member of the Internet Architecture Board . I usually write here about the Web, protocol design, HTTP, and caching. Find out more .

The Pitfalls of Debugging HTTP

Some folks at work were having problems debugging HTTP with LWP ’s command-line GET utility; it turned out that it was inserting Link headers — HTTP headers, mind you — for each HTML <link> element present.

Blurgh.

This brought to mind some other peculiarities that can make debugging HTTP more complex and REALLY ANNOYING…

Curl automagically adds a Pragma: no-cache to requests, so that you don’t have to worry about scaling the Web or getting decent performance.

LiveHTTPHeaders shows you headers, but through the lens of Mozilla’s header parsing and processing, not what’s on the wire.

Even Wireshark can’t be completely trusted; it will remove the \r

from the Content-Length header (because it’s parsing the message for its own purposes), making you think that the sender has header delimitation bugs.

Anybody have another?

All of this is why I tend to use telnet when debugging HTTP. Sometimes tcpflow helps too.