HTTP Error 599 using Tornado as a Proxy for SSL Connections

[bish...@gmail.com]

Hey guys!

I'm using Tornado as a proxy for HTTP(S) requests to other servers - essentially I've got one handler in my app:

class ProxyHandler(RequestHandler):

  def get(self):

    # Proxy request remote server using AsyncHTTPClient.

    # ...

    

  def on_response(self):

    # Write response from remote server.

    

This works great for HTTP requests, but over SSL requests made after the keep alive has expired result in an error:

HTTP 599: error:1408F06B:SSL routines:SSL3_GET_RECORD:bad decompression

I'm stumped! Why would the client to Tornado connection have any effect on how AsyncHTTPClient sets up its next request?

Restarting the server fixes the issue and I can catch the error ... so another solution may be to just bounce everything and ask the user to refresh (which is fine for my usage!) 

How would you bounce a running server so it will drop all connections and start fresh?

I've tried an assorted combinations of stop / start with the server without much luck - it would seem calling stop / start would result in an assertion from the presence of socket on the server.

Thanks!

jb

[Ben Darnell]

On Fri, Jan 21, 2011 at 12:44 PM, <bish...@gmail.com> wrote:

Hey guys!

I'm using Tornado as a proxy for HTTP(S) requests to other servers - essentially I've got one handler in my app:

class ProxyHandler(RequestHandler):

  def get(self):

    # Proxy request remote server using AsyncHTTPClient.

    # ...

    

  def on_response(self):

    # Write response from remote server.

    

This works great for HTTP requests, but over SSL requests made after the keep alive has expired result in an error:

HTTP 599: error:1408F06B:SSL routines:SSL3_GET_RECORD:bad decompression 

I'm stumped! Why would the client to Tornado connection have any effect on how AsyncHTTPClient sets up its next request?

This is a curl error.  What version of libcurl are you using?  The client-to-tornado connection shouldn't matter, but the most likely explanation is that during the time it takes for the client keepalive to expire, something else expired too (either a cache in libcurl or something on the remote server).  

If you pull the latest version of tornado from get you could try SimpleAsyncHTTPClient instead, but be warned that its SSL support is not yet complete (it's complete enough to test for the presence of this bug, but it doesn't check certificates so it's not actually secure against man-in-the-middle attacks yet).

 

Restarting the server fixes the issue and I can catch the error ... so another solution may be to just bounce everything and ask the user to refresh (which is fine for my usage!) 

How would you bounce a running server so it will drop all connections and start fresh?

I've tried an assorted combinations of stop / start with the server without much luck - it would seem calling stop / start would result in an assertion from the presence of socket on the server.

You could try creating a new HTTPServer object after stopping the old one, but that's not going to reset libcurl's internal state (and I'm not sure if there's a reliable way to do that).  The simplest way to restart the server (assuming you're running under something like supervisord or even a simple looping shell script) is to simply exit and let the external process restart it.  (a more complicated way can be seen in the autoreload module)

-Ben

 

Thanks!

jb

[bish...@gmail.com]

It's an internal app so SimpleAsyncHTTPClient is exactly what I needed - it doesn't suffer from whatever is haunting curl.

Thanks for your help Ben!!!

jb

[Bill Janssen]

John, could you say a bit more about how you send the proxy request to
the remote server? I've been meaning to do the same thing, but
haven't gotten around to the code for it yet.

Bill