Sean McArthur aa23a9735d SETTINGS_MAX_HEADER_LIST_SIZE (#206)
This, uh, grew into something far bigger than expected, but it turns out, all of it was needed to eventually support this correctly.

- Adds configuration to client and server to set [SETTINGS_MAX_HEADER_LIST_SIZE](http://httpwg.org/specs/rfc7540.html#SETTINGS_MAX_HEADER_LIST_SIZE)
- If not set, a "sane default" of 16 MB is used (taken from golang's http2)
- Decoding header blocks now happens as they are received, instead of buffering up possibly forever until the last continuation frame is parsed.
- As each field is decoded, it's undecoded size is added to the total. Whenever a header block goes over the maximum size, the `frame` will be marked as such.
- Whenever a header block is deemed over max limit, decoding will still continue, but new fields will not be appended to `HeaderMap`. This is also can save wasted hashing.
- To protect against enormous string literals, such that they span multiple continuation frames, a check is made that the combined encoded bytes is less than the max allowed size. While technically not exactly what the spec suggests (counting decoded size instead), this should hopefully only happen when someone is indeed malicious. If found, a `GOAWAY` of `COMPRESSION_ERROR` is sent, and the connection shut down.
- After an oversize header block frame is finished decoding, the streams state machine will notice it is oversize, and handle that.
  - If the local peer is a server, a 431 response is sent, as suggested by the spec.
  - A `REFUSED_STREAM` reset is sent, since we cannot actually give the stream to the user.
- In order to be able to send both the 431 headers frame, and a reset frame afterwards, the scheduled `Canceled` machinery was made more general to a `Scheduled(Reason)` state instead.

Closes #18 
Closes #191
2018-01-05 09:23:48 -08:00
2018-01-02 17:02:17 -08:00
2017-05-31 14:44:58 -07:00
2018-01-05 09:23:48 -08:00
2018-01-02 11:01:55 -08:00
2017-12-18 22:22:40 -08:00
2017-12-16 14:52:08 -06:00
2018-01-02 17:02:17 -08:00

H2

A Tokio aware, HTTP/2.0 client & server implementation for Rust.

Build Status Codecov

This library is not production ready. Do not try to use it in a production environment or you will regret it! This crate is still under active development and there has not yet been any focus on documentation (because you shouldn't be using it yet!).

More information about this crate can be found in the crate documentation

Features

  • Client and server HTTP/2.0 implementation.
  • Implements the full HTTP/2.0 specification.
  • Passes h2spec.
  • Focus on performance and correctness.
  • Built on Tokio.

Non goals

This crate is intended to only be an implementation of the HTTP/2.0 specification. It does not handle:

  • Managing TCP connections
  • HTTP 1.0 upgrade
  • TLS
  • Any feature not described by the HTTP/2.0 specification.

The intent is that this crate will eventually be used by hyper, which will provide all of these features.

Usage

To use h2, first add this to your Cargo.toml:

[dependencies]
h2 = { git = 'https://github.com/carllerche/h2' } # soon to be on crates.io!

Next, add this to your crate:

extern crate h2;

use h2::server::Connection;

fn main() {
    // ...
}

FAQ

Is this an embedded Java SQL database engine?

No.

Description
No description provided
Readme 4.5 MiB
Languages
Rust 99.2%
Python 0.7%