vladmunteanu / th2c

Tornado HTTP/2 Client

Async HTTP/2 Client

A simple asynchronous HTTP/2 client for Tornado applications, based on the awesome h2 library.

Intended for Python 2 (>= 2.7.9).

This package is in a very early development stage, so expect bugs or changes in the API. If you spot anything wrong, or would like to suggest improvements, please open an issue or a pull request.

Example

Usage in a coroutine may be:

from th2c import AsyncHTTP2Client
from tornado.httpclient import HTTPRequest

client = AsyncHTTP2Client(
    host='nghttp2.org', port=443, secure=True,
)

request = HTTPRequest(
    url='https://nghttp2.org/httpbin/get',
    method='GET',
)

res = yield client.fetch(request)

TODO

• moar tests :)
• SERVER_PUSH
• follow_redirects
• priority control

Development setup

If you wish to create a development environment to work on th2c, you can use a Vagrant setup or a virtual environment. The Vagrant setup is located under vm, an Ubuntu 16.04 64bit box with Go and Python 2 installed, that maps the project directory under /opt/dev/th2c.

For a minimal set of "integration tests", a Go web server is included in test_server that simply echoes back what it receives.

You can run it in debug mode, from the project directory, by executing:

GODEBUG=http2debug=1 go run test_server/main.go.

After the server has started, you should run the client by executing:

python -m th2c.

Log files should be produced under /opt/dev/th2c/logs.

You can also run unit tests with: nosetests tests

th2c's Issues

Tornado write buffer blocked durig when sendindg requests for a long period of time (60 seg)

Seems the client which is using the write buffer to flush de data obtained from h2 is not able to send data after a certain amount of time sending reqs (PUTs) writing it in the buffer but not realising them towards the server. Is this an expected behaviour or am i missing something?

Improve client usability

The client should be usable without defining a new instance for each new host:port. The logic from the client for connection reusability should be moved inside HTTP2ClientConnection.

Stream cleanup from connection fails with KeyError.

in Stream.finish, the line self.connection.end_stream(self) can raise:
Exception in callback <functools.partial object at 0x7fef7c1355d0>#012 Traceback (most recent call last):#012 File "/usr/local/lib/python2.7/dist-packages/tornado/ioloop.py", line 605, in _run_callback#012 ret = callback()#012 File "/usr/local/lib/python2.7/dist-packages/tornado/stack_context.py", line 277, in null_wrapper#012 return fn(*args, **kwargs)#012 File "/usr/local/lib/python2.7/dist-packages/th2c/stream.py", line 78, in on_timeout#012 None#012 File "/usr/local/lib/python2.7/dist-packages/th2c/stream.py", line 86, in handle_exception#012 self.finish(val)#012 File "/usr/local/lib/python2.7/dist-packages/th2c/stream.py", line 259, in finish#012 self.connection.end_stream(self)#012 File "/usr/local/lib/python2.7/dist-packages/th2c/connection.py", line 417, in end_stream#012 del self._ongoing_streams[stream.stream_id]#012KeyError: 3

Noticed this after a RequestTimeout exception

Handle write futures

Streams should handle write futures and exit if anything goes bad.
Can be done easily because streams use connection.flush() in a coroutine so we can yield the future and retry I guess.

Connection should handle its write futures exceptions as failures, gracefully closing the http2 connection.

This is temporary, until we find a better solution for handling these edge cases.

Add follow_redirects feature

Follow redirects if configured so, by identifying the next host and spawning a new client to handle the new request.

The new client should not auto_reconnect ( see #5 ).

Expose connection timeout

At the moment, connection timeout is passed as a globally defined constant.
Should be configurable through the client's constructor.

HTTPError is automatically raised if response code < 200 or >= 300

HTTPError is automatically raised in client.py

We should accept a parameter in fetch and return the response object if necessary.

Add auto_reconnect feature

Given the HTTP/2 context, we'd like this to be stable for a long period of time, so on a specific set of exceptions, we should try reconnecting. Connection cleanup must be properly implemented before we go through with this, or we should create a new connection object.

Provide port to Python 3

According to PEP 373, the End Of Life date for Python 2 is 2020 (less than two years from the time of this issue). According to PEP 404 it is further cemented that Python 2 will no longer be actively developed due to their not being a Python 2.8 planned.

For the sake of the project's longevity it is in its best interest to, at the very least, provide a port to Python 3.

The project looks great and I would hate to see it fall to the wayside solely due to it being made for Python 2.x.