Route Tracking using HTTP Tracing

The HTTP 1.1 protocol has it’s own tracing method implemented called TRACE which provides route tracing on request.  Of course many people simply use traceroute commands which are available on most operating systems – however this only tracks hops on the network router level.  The HTTP trace method actually provides much more detailed tracking and can even pick up any intermediate servers between the various router hops.  This can be very useful in a wide variety of situations:

  • You can exactly determine a proxy route a HTTP request is making.
  • Identify all servers in the chain, including their various versions of software, HTTP and OS.
  • Useful for detecting infinite loops
  • Tracking down any invalid responses on the route.
  • Identify any router, hub or proxy server which is causing a routing issue.

In some senses the TRACE method is very much like that more familiar GET method, but here the target server is simply supplied as a parameter.  You can set the maximum number of hops that are to be followed by using the Max-Forwards header. This setting is essential if you need to detect and track the causes of infinite loops without simply getting stuck in them.  Without this setting your troubleshooting efforts would be stuck in the loop too, especially when you are dealing with proxy chains.  There are other benefits of using this method too, for example imagine trying to troubleshoot issues in an international proxy chain perhaps spread across Europe. Maybe you’ve decided the issue may be between the French or German proxies like in this example – http://thenewproxies.com/german-proxy/.

Well using the TRACE method you can fine tune your troubleshooting even more by using telnet.  The HTTP TRACE request can actually be sent using telnet – just loging manually and issue the at the command line.  You will then receive a response directly from that specific server in the chain and it will carry a HTTP message in the response that will indicate what happened to the packet when it reached the final server.  You can even fine tune even more by using the VIA header which can indicate the exact route taken or to specify a route if you suspect a specific server or router to be the problem.

Source: http://www.youtube.com/watch?v=R-6JjuQGHJw