Eliza Weisman 4b81e528d5 Log more information when rejecting malformed pseudo-headers (#342)
Currently, when a `h2` server receives a HEADERS frame with malformed
pseudo-headers, it logs which pseudo-heade was malformed at the debug
level before sending a reset. This behaviour is correct. However, it can
be difficult to debug misbehaving clients, as the server's log message
doesn't include the *value* of the invalid pseudo-header, or indicate
*why* it was incorrect. 

This branch changes the log message to include both the value of the
malformed header and the error that caused it to be rejected. 

For example, here is the output from the test
`server::recv_invalid_authority`, before and after making this change.

Before:
```
...
DEBUG 2019-01-23T19:16:28Z: h2::server: malformed headers: malformed authority
...
```

After:
```
...
DEBUG 2019-01-23T19:15:37Z: h2::server: malformed headers: malformed authority ("not:a/good authority"): invalid uri character
...
```

Note that it was necessary to clone the value of each pseudo-header
before passing it to the `uri::{Scheme, Authority, Path}::from_shared`
constructors, so that the value could be logged if those functions
return errors. However, since the pseudo-headers are internally
represented using `Bytes`, this should just increase the reference count
rather than copy the string, so I thought this was acceptable. 

If even a ref-count bump has an undesirable performance overhead, we
could consider using
```rust
if log_enabled!(Level::Debug) {
    // ...
}
```
to only clone if the message will be logged, but this makes the code
somewhat significantly more complicated. Therefore, I decided to punt on
that unless requested by a reviewer.

See also linkerd/linkerd2#2133

Signed-off-by: Eliza Weisman <eliza@buoyant.io>
2019-01-23 11:44:32 -08:00
2017-05-31 14:44:58 -07:00
2019-01-11 22:41:35 -08:00
2018-05-10 14:48:02 -07:00
2018-10-16 12:03:29 -07:00
2019-01-13 09:53:19 -08:00
2019-01-13 09:53:19 -08:00
2017-12-18 22:22:40 -08:00
2017-12-16 14:52:08 -06:00
2019-01-13 09:53:19 -08:00

H2

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

Build Status License: MIT Crates.io Documentation

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 = "0.1.15"

Next, add this to your crate:

extern crate h2;

use h2::server::Connection;

fn main() {
    // ...
}

FAQ

How does h2 compare to solicit or rust-http2?

The h2 library has implemented more of the details of the HTTP/2.0 specification than any other Rust library. It also passes the h2spec set of tests. The h2 library is rapidly approaching "production ready" quality.

Besides the above, Solicit is built on blocking I/O and does not appear to be actively maintained.

Is this an embedded Java SQL database engine?

No.

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