Cory Benfield
Cory Benfield
RFC 8441 defines "extended CONNECT", which is primarily useful for implementing websockets-over-HTTP/2. We right now do not support this, but we'd like to. This shouldn't be too much work.
When the `HPACKEncoder` was first written it was written to provide incremental header compression. This was enhanced later on in the development of v1 to provide one-shot header compression, which...
Right now both the server and the client ignore the result of the ALPN negotiation. The client does log the outcome, but otherwise does nothing: the server largely ignores it...
When either the server or the client sends a HTTP message with a body that is *short* (that is, the body does not contain enough bytes to meet the `Content-Length`...
Right now there is no support for HTTP/2 using `sendfile` to send DATA frames. This is potentially inefficient for implementations that are able to send really sizeable DATA frames. Given...
Inspired by @njsmith in njsmith/h11#4. Right now there is a wart in the h2 API when working on a busy connection. The problem exists when working with `receive_data`. For example,...
Good artists copy, great artists steal. One of @njsmith's great decisions with [h11](https://github.com/njsmith/h11) was to write his [buffer](https://github.com/njsmith/h11/blob/master/h11/_receivebuffer.py) in terms of bytearray. This has some major efficiency gains on Python...
Follows on from #464 and #465. We've added some specific tests for the `Settings` object's equality behaviour, and have reached some minimum code coverage, but this is really something that...
@rbtcollins and I have had a really interesting discussion on IRC about #194, and in particular about the API decision that was made in that issue. For those who don't...
HTTP/2 is extendable: it's one of its great strengths. It would be really nice if H2 was relatively easily extensible. We should aim to start supporting pluggable HTTP/2 extensions. What...