Finally! We pushed the Traffic Server code to Apache SVN today! This is definitely a momentous occasion, this has been in the works for ages, and it took a lot of work and patience to happen. You wonder, why did we bother? Well, you are right, there's plenty of proxy server alternatives out there, Squid, Varnish, NginX and so on. But, we think we have a platform we can build something on that will be better than anything out there (that is free at least). Why? Well, we have

• A scalable threaded + asynchronous state machine model. On a typical setup, 2 or 3 threads per core is enough to drive a large amount of traffic.
• Feature-rich HTTP/1.0 and HTTP/1.1 support. We fair well in various tests like CoAdvisor.
• Plugin architecture, making it easy (well, easier) to extend and customize your server.
• Well documented.

I'm not saying it's perfect (far from it), but the hope is that Open Sourcing this will attract an active developer and user community around the software. So, you want more information? Well, besides visiting us on #traffic-server on irc.freenode.net, here's a bunch of links with some useful information:

http://incubator.apache.org/projects/trafficserver.html

http://cwiki.apache.org/confluence/display/TS/Index

http://svn.apache.org/repos/asf/incubator/trafficserver/

http://incubator.apache.org/trafficserver/docs/admin/

http://incubator.apache.org/trafficserver/docs/sdk/

Please join the mailing lists (see the Incubator page), talk to us on IRC, or just take a look at the code.

Update: Mark Nottingham (on our team now!) has a blog post with some interesting history and thoughts on TS.

I spent a long night debugging a problem in my current project (Image/content spam prevention), and had problems retrieving URLs that resolved into the Akamai distributed proxy mesh. And yes, I did file this as a SourceForge bug

I don't know who's at fault here, but httplib.py will interpret the HTTP response from an Akamai server (erroneously) as if the socket is closed when the request is finished. This does not happen, because Akamai implements a Connection: keep-alive feature. The following diff to httplib.py (Python 2.3.2) does solve the problem, although I'm not sure if it's the right solution:

--- /usr/lib/python2.3/httplib.py    2003-10-06 09:11:52.000000000 -0700
+++ httplib.py    2004-01-11 03:10:18.000000000 -0800
@@ -355,6 +355,12 @@
         # An HTTP/1.0 response with a Connection header is probably
         # the result of a confused proxy.  Ignore it.
 
+        # Akamai returns HTTP 1.0 headers, with connection: keep-alive, so
+        # the socket will not close.
+        conn = self.msg.getheader('connection')
+        if conn and conn.lower().find("keep-alive") >= 0:
+            return False
+
         # For older HTTP, Keep-Alive indiciates persistent connection.
         if self.msg.getheader('keep-alive'):
             return False

As an alternative, you can subclass the HTTPResponse class, to override the _check_close() method:

class HTTPResponse(httplib.HTTPResponse):
    def _check_close(self):
        if self.version == 11:
            # An HTTP/1.1 proxy is assumed to stay open unless
            # explicitly closed.
            conn = self.msg.getheader('connection')
            if conn and conn.lower().find("close") >= 0:
                return True
            return False

        # Akamai returns HTTP 1.0 headers, with connection: keep-alive, so
        # the socket will not close.
        conn = self.msg.getheader('connection')
        if conn and conn.lower().find("keep-alive") >= 0:
            return False

        # For older HTTP, Keep-Alive indiciates persistent connection.
        if self.msg.getheader('keep-alive'):
            return False

        # Proxy-Connection is a netscape hack.
        pconn = self.msg.getheader('proxy-connection')
        if pconn and pconn.lower().find("keep-alive") >= 0:
            return False

        # otherwise, assume it will close
        return True

httplib.HTTPConnection.response_class = HTTPResponse