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
Fix the header title-casing to work with consecutive
dashes. Previously with two dashes in a row the first dash would
uppercase the second dash which would then not count, so
`weird--header` would be cased as `Weird--header` instead of
`Weird--Header`.
These options are currently available on the high-level builder only.
Along the way, rename the setters to follow the public API conventions
and add docs.
Closes#2461
When a `CONNECT` over HTTP2 has been established, and the user tries to write data right when the peer closes the stream, it will no longer return as a "user error". The reset code is checked, and converted into an appropriate `io::ErrorKind`.
We don't really care what bytes are in chunked extensions. We ignore
them until we find a CRLF. However, some other HTTP implementations may
only look for a LF, and forget that chunked requires the CR as well. To
save them from themselves, this makes hyper reject any chunked
extensions that include an LF byte.
This isn't a *bug*. No one ever cares what's in the extensions. This is
meant as a way to help implementations that don't decoded chunked
encoding correctly. This shouldn't affect really anyone in the real
world.
When http2_only is true, we never try to open a new connection if there
is one open already, which means that if the existing connection that
gets checked out of the pool is closed, then the request won't happen.
That Proxy-Authenticate and Proxy-Authorization are forbidden over h2
is not actually specified anywhere, plus h2 also supports CONNECT
requests, which are specifically made to do requests over a proxy,
and those proxies may require authentication, sometimes through
Proxy-Authorization.
Note that there is an openwebdocs project that just started to clear
up any MDN-induced confusion in implementations:
https://github.com/openwebdocs/project/issues/43
This defines an extension type used in requests for the client that is
used to setup a callback for receipt of informational (1xx) responses.
The type isn't currently public, and is only usable in the C API.
The HTTP/1 content-length parser would accept lengths that were prefixed
with a plus sign (for example, `+1234`). The specification restricts the
content-length header to only allow DIGITs, making such a content-length
illegal. Since some HTTP implementations protect against that, and
others mis-interpret the length when the plus sign is present, this
fixes hyper to always reject such content lengths.
See GHSA-f3pg-qwvg-p99c
The HTTP/1 chunked decoder, when decoding the size of a chunk, could
overflow the size if the hex digits were too large. This fixes it by
adding an overflow check in the decoder.
See GHSA-5h46-h7hh-c6x9
