According to rfc2616#section-14.20 the header value is case-insensitive. Certain clients send the expectation as `100-Continue` and this should be handled by the server.
Closes#2708
Adds `Server::http1_header_read_timeout(Duration)`. Setting a duration will determine how long a client has to finish sending all the request headers before trigger a timeout test. This can help reduce resource usage when bad actors open connections without sending full requests.
Closes#2457
The doctest uses `hyper::Client`, but that is not available unless these features are enabled.
This commit adds an attribute to check for those and allows `cargo test` with no arguments to pass again.
fixes#2687.
The default Body type is used in the client in a Pool, so it has to be
Send. On the server, we can use a !Send type if the executor is single
threaded.
Expand the existing example to show that.
Initially this creates a top-level "dev" directory to hold documents
pertaining to the development, as opposed to the usage, of hyper. For a
first doc, it splits out the commit guidelines to its own file.
cc #2586
A client connection that read a full response while the request body was
still flushing would see incorrect behavior, since the pool would let it
be checked out again for a new request. In debug builds, it would then
panic, but in release builds it would intermix the 2nd request bytes
with the body of the previous request.
In practice, this only ever happens if a server replies with a full
response before reading the full request, while also choosing to not
close that connection. Most servers either wait for the full request, or
close the connection after the new response is written, so as to stop
reading.
* server::Server
* server::conn::{AddrIncoming, AddrStream}
This allows higher-level libraries to use or re-export more parts of the
API without deciding for the end user which HTTP versions the hyper
server will support.
This changes all the extern C functions in `hyper::ffi` to check passed
pointer arguments for being `NULL` before trying to use them. Before, we
would just assume the programmer had passed a good pointer, which could
result in segmentation faults. Now:
- In debug builds, it will assert they aren't null, and so if they are,
a message identifying the argument name will be printed and then the
process will crash.
- In release builds, it will still check for null, but if found, it will
return early, with a return value indicating failure if the return type
allows (such as returning NULL, or `HYPERE_INVALID_ARG`).
Closes#2620
