async-h1
async-h1 copied to clipboard
http-rs
Asynchronous HTTP/1.1 in Rust
Found via fuzzing. Steps to reproduce: 1. run the server example (`cargo run --example=server`) 2. feed it the bad input (`cat crash | nc localhost 8080`) `crash` is ``` GET...
The way the `async-h1` encoder streams the HTTP response head and body to the given `io: Write` causes the head and body to be written to the underlying socket as...
Hello, `server::decode` panics on valid UTF-8 but none ASCII headers and return `500 Internal Server Error` on none valid UTF-8 headers. I believe a `400 Bad Request` should be returned...
Related PR: https://github.com/http-rs/tide/pull/836 This PR adds cancellation feature to Server with [stopper](https://crates.io/crates/stopper). But I'm not sure it would shutdown the server 'gracefully'...
We should have some sort of logic when the chunked stream ends prematurely. Right now we just end the stream and leave it to later steps to (maybe?) catch this...
https://github.com/http-rs/async-h1/blob/dffae5fb497dbead73c3d2c87f4d5f9e6e75b2b3/src/client/decode.rs#L74 I'm seeing date header values like ``` Header date -> [ "date: Wed, 01 Sep 2021 17:42:04 GMT\r\n", ] ``` Where `date: ` and `\r\n` are both included in...
It seems like this line is the issue: https://github.com/http-rs/async-h1/blob/a1448c379b0cce920e44c62b566bb20db1ce2157/src/client/decode.rs#L65 It is my understanding there shouldn't be a meaningful difference parsing a HTTP/1.0 with a 1.1 parser since the only differences...
https://github.com/http-rs/async-h1/blob/a1448c379b0cce920e44c62b566bb20db1ce2157/src/client/decode.rs#L28 One point of HTTP/1.1 is persistent connection, but in this line of code, we're stuck with one request/response per connection.
I'm running into an `assert!(...)` here, which should probably just return an error, instead: https://docs.rs/async-h1/2.1.2/src/async_h1/client/decode.rs.html#32 (I think that's what the `TODO` there is suggesting.) In this case, I know that...
The `Clone` bound is both problematic for users, and leads to bugs internally as well (#175, #176). This PR keeps existing public interfaces (mostly) unchanged, but adds two new functions...
