Verifying Traffic Server with AddressSanitizer is fairly straight-forward. On Linux, you need recent gcc or clang and the libasan library. On OS X, libasan wasn’t present, so I just switched to Linux ;) You should give --enable-asan to configure when you build. The build system will enable ASAN on all the parts that should have it. Then, whenever you run you will get ASAN checking memory state. LeakSanitizer reports leaks from an atexit(3) handler, so you need to ensure that the program exits rather than calls _exit(2) or dumps core.

When you write a new Traffic Server plugin, you have to choose whether to write a remap plugin, a global plugin or both. There are different plugin entry points for global and remap plugins and you will find yourself having to parse command-line argument from two different entry points: tsapi void TSPluginInit(int argc, const char* argv[]); tsapi TSReturnCode TSRemapNewInstance(int argc, char* argv[], void** ih, char* errbuf, int errbuf_size); Since we are parsing command-line options, it makes sense to use getopt or getopt_long to do the parsing.

Traffic Server request processing can be a little complex, with multiple state machines working at the same time and a lot of objects interacting in complex ways, so I thought it would be fun to reverse engineer the code flow from a log trace. I guess that it wasn’t as much fun as I had hoped, but it was educational. This is a GET request with a Range header. The requested document is not currently cached, so Traffic Server just proxies the request.