The client Request now uses the same system as a server Response to track
the write status of headers, and the API has been updated accordingly.
Additionally, the Request constructors have been moved onto the Request object
instead of being top-level hyper functions, as this better namespaces the
client and Server.
Trying to default the type parameters leads to an ICE and strange type errors.
I think this is just due to the experimental state of default type params and
this change can be rolled back when they are fixed.
Expose Server::many for creating a Server that will listen on many (ip, port)
pairs.
Handler still receives a simple Iterator of (Request, Response) pairs.
This is a breaking change since it changes the representation of Listener,
but Handler and Server::http are unchanged in their API.
Fixes#7
The client benchmarks did not have to be changed at all for this whole
refactor, and the server benchmark only had to specify a single type parameter,
and only because it writes out the type of Listener, which is not normal
usage.
Server and client benchmarks show that this makes very little difference
in performance and using dynamic dispatch here is significantly more ergonomic.
This also bounds NetworkStream with Send to prevent incorrect implementations.
Allows the implementation of mock streams for testing and flexibility.
Fixes#5
This introduces a new Trait, NetworkStream, which abstracts over
the functionality provided by TcpStream so that it can be easily
mocked and extended in testing and hyper can be used for
other connection sources.
Adds a benchmark for testing the speed of hyper's server.
Due to limitations of rust-http, `cargo bench` now needs to be
killed after running because there is no way to kill a rust-http
server after you start it.
Introduces two Phantom Types, Fresh and Streaming, which indicate the status
of a Response.
Response::start translates an Response<Fresh> into a
Response<Streaming> by writing the StatusCode and Headers.
Response<Fresh> allows modification of Headers and StatusCode, but does
not allow writing to the body. Response<Streaming> has the opposite privileges.
This fixes an unsafe transmute that could cause use-after-frees
on collision resolution in the headers hash and avoids allocating
for cases where it is not necessary.
Fixes#12
This introduces a bit of complexity to the example,
mainly the use of the try_continue! macro for dealing
with errors, but I think this is an appropriate trade-off
as users of this library are likely to be framework authors
instead of end users.
This allows downstream users to have total control of their concurrency
strategy, while also exposing a very nice, streaming interface for frameworks
to build on.
This also resolves issues surrounding the use of IoResult as the return type
of Handler::handle, because handlers now have complete control over how to
handle internal failure.
Fixes#3Fixes#4
