This may be because the crate is new and there aren't docs there yet. It may be because that's broken or I misunderstood somehow. Investigation needed.

was trying to implement a workaround for #88 :

pub fn serve(directory: &Path) -> Result<()> {
    let host = "127.0.0.1";
    let port = "7878";

    let server = Server::new(|request, mut response| {
        println!("got {}", request.uri().path());
        response.status(301);
        response.header(http::header::LOCATION, "/index.html".as_bytes());
        Ok(response.body("".as_bytes())?)
    });

    env::set_current_dir(directory)?;

    println!("serving at http://{}:{}", host, port);

    server.listen(host, port);

    Ok(())
}

the 301 comes through, but not the location header. I don't know why...

the Server::listen call currently takes an &str for both host and port. This gets fed into a format! call, using the a str impl of ToSocketAddr.

IMHO, there is no opinion to stringly-type these parameters. Taking a std::net::IpAddr and a u16 does exactly the same, with stronger typing. The combination (IpAddr, u16) even has a ToSocketAddrs-impl, so it can be directly passed into the TcpListener.

As discussed on users.rust-lang, this would add some boilerplate on the user-side to create the IpAddr:

IpAddr::V4(Ipv4Addr::new(127, 0, 0, 1)); // verbose, guaranteed to work...
"127.0.0.1".parse().expect("couldn't parse IP address") // not much better...

We only have the log crate because we want to print out that the server is starting; we only print out the server is starting because there's no way to customize this kind of thing. The Node api we're emulating does, however.

It might look something like this:

#[macro_use]
extern crate log;
extern crate env_logger;

extern crate simple_server;

use simple_server::Server;

fn main() {
    env_logger::init().unwrap();

    let host = "127.0.0.1";
    let port = "7878";

    let server = Server::new(|request, mut response| {
        info!("Request received. {} {}", request.method(), request.uri());
        Ok(response.body("Hello Rust!".as_bytes())?)
    });

    server.listen(host, port, || {
        info!("Server started on {}:{}", host, port);
    });
}

Thoughts?

i think this is a good use of it https://github.com/rust-lang-nursery/error-chain

The presence of a message body in a request is signaled by a Content-Length or Transfer-Encoding header field.

https://tools.ietf.org/html/rfc7230#section-3.3

Without this some tools don't work well, for example wrk.

let data = String::from_utf8_lossy(request.body()).into_owned();
let body = format!(r#"{{"data": {}, "url": "{}"}}"#, request.uri().path(), data);
Ok(response
    .header("content-length", body.len().to_string().as_str())   //  ~:o
    .body(body.into_bytes())?)

Is valid code, although has some issues, the first one is the header is not set (or any other header).

< HTTP/1.1 200 OK
* no chunk, no close, no size. Assume close to signal end

Compared with the minimal out of the box set by the http module of node:

< HTTP/1.1 200 OK
< Date: Sun, 29 Oct 2017 08:19:45 GMT
< Connection: keep-alive
< Content-Length: 21

Can these values be set automatically?

it should have the current version.

Right now, we only support 16 headers:

A real server should support more.

For static file serving, it'd be nice to be able to point this directory somewhere.

So that people can choose to redirect the output however they want.

The Server::listen docs say that it blocks forever I believe that implies that it's a diverging function so it's return type should indicate that, right?

Ie:

pub fn listen(&self, host: &str, port: &str) -> ! {...}

Instead of the current:

pub fn listen(&self, host: &str, port: &str) {...}

This would allow the compiler to more correctly reason about code paths around calls to listen.

In the handler I have eprintln!("{:?}", request.body()). The client sending the request is Chrome using AJAX. I have a button on the page which sends JSON when one clicks it. If I try to click it few times in a row, one of the requests prints out zeroed slice of different length, the rest are correct. I've checked with Wireshark and the request seems correct, so the issue is in simple-server.

We originally used fn because there was no need, but building more complex stuff needs Fn; for example, a framework writing their own listen method will want to use stuff from self inside of the server, but you can't create that stuff inside the fn passed to new.

For example, the routes example exhibits incorrect behavior:

curl -X POST localhost:7878/hello

returns

<h1>Hi!</h1><p>Hello Rust!</p>

but it should return 404.

I haven't done any investigating, but didn't see this on the issues list.

I get this error regularly on an application hosted on clever cloud: it's behind haproxy with a tcp check, and it's also pinged by zabbix (with a tcp check as well).

thread '<unnamed>' panicked at 'Tried to unwrap Status::Partial', /home/bas/.cargo/registry/src/github.com-1ecc6299db9ec823/httparse-1.2.3/src/lib.rs:254:31
2017-10-17T13:43:41.361Z: thread 'main' panicked at 'Thread pool worker panicked', /home/bas/.cargo/registry/src/github.com-1ecc6299db9ec823/scoped_threadpool-0.1.8/src/lib.rs:236:12

I haven't been able to reproduce this exact error locally (with only haproxy), but I got this one instead:

thread '<unnamed>' panicked at 'Error handling connection.: Io(Error { repr: Os { code: 54, message: "Connection reset by peer" } })', src/libcore/result.rs:860:4

from #1

*response.body_mut() = "Hello Rust!".as_bytes();

It seems like you can't use owned data (e.g., String or Vec<u8>) for the response body in the Server handler.

Unless I am missing something, this seems like a huge limitation: it prevents you from doing anything with the request data (at least easily).

It seems like you could use Cow<'static, [u8]> for the response body, or Bytes.

Am I missing something?

I wanted to do a quick benchmark of this with the server example and wrk.

When running wrk (wrk --latency -t2 -c100 -d10s "http://localhost:7878"), the example immediately panics with:

thread '<unnamed>' panicked at 'Error handling connection.: HttpParse(Token)', /checkout/src/libcore/result.rs:860:4
note: Run with `RUST_BACKTRACE=1` for a backtrace.
thread 'main' panicked at 'Thread pool worker panicked', ...

I tried changing a few flags in wrk and running the example in both debug and release mode, but didn't want to spend much time digging in.

Not sure if wrk does anything weird to HTTP connections, but I've never seen this in any Hyper-based web servers.

This is with Rust 1.20, the master branch of this project, and wrk 4.0.2 (on Linux).

Works fine in FireFox (including Nightly) and Chrome.

Versions:

• OS: MacOS High Sierra
• Safari: Version 11.0 (12604.1.38.1.7)
• Kernel: Darwin hodor.local 16.7.0 Darwin Kernel Version 16.7.0: Thu Jun 15 17:36:27 PDT 2017; root:xnu-3789.70.16~2/RELEASE_X86_64 x86_64
• rustc 1.21.0 (3b72af97e 2017-10-09)
• cargo 0.22.0 (3423351a5 2017-10-06)
• rustup 1.6.0 (a11c01e8c 2017-08-30)

 $ RUST_BACKTRACE=1 cargo run --example server
   Compiling simple-server v0.1.0 (file:///Users/booyaa/Dev/rust/clowns/simple-server)
    Finished dev [unoptimized + debuginfo] target(s) in 3.57 secs
     Running `target/debug/examples/server`
thread '<unnamed>' panicked at 'Tried to unwrap Status::Partial', /Users/booyaa/.cargo/registry/src/github.com-1ecc6299db9ec823/httparse-1.2.3/src/lib.rs:254:31
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
   1: std::panicking::default_hook::{{closure}}
   2: std::panicking::default_hook
   3: std::panicking::rust_panic_with_hook
   4: std::panicking::begin_panic
   5: <httparse::Status<T>>::unwrap
   6: simple_server::parse_request
   7: simple_server::Server::handle_connection
   8: simple_server::Server::listen::{{closure}}::{{closure}}
   9: <F as scoped_threadpool::FnBox>::call_box
  10: scoped_threadpool::Pool::new::{{closure}}
thread 'main' panicked at 'Thread pool worker panicked', /Users/booyaa/.cargo/registry/src/github.com-1ecc6299db9ec823/scoped_threadpool-0.1.8/src/lib.rs:236:12
stack backtrace:
   0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
   1: std::panicking::default_hook::{{closure}}
   2: std::panicking::default_hook
   3: std::panicking::rust_panic_with_hook
   4: std::panicking::begin_panic
   5: scoped_threadpool::Scope::join_all
   6: <scoped_threadpool::Scope<'pool, 'scope> as core::ops::drop::Drop>::drop
   7: core::ptr::drop_in_place
   8: scoped_threadpool::Pool::scoped
   9: simple_server::Server::listen
  10: server::main
  11: __rust_maybe_catch_panic
  12: std::rt::lang_start
  13: main

These were good for prototyping, but we should get rid of them.

once we move the repo

let's get these good changes out!

In this small example (https://gist.github.com/divarvel/4c59b15d6921f79884b7638905faa4e9) we can see that headers are not written in the answer (the Location header is missing).

Indeed, write_response does not seem to include them
https://github.com/steveklabnik/simple-server/blob/master/src/lib.rs#L189

In the crates.io page, there's a link to a "server" example which is going to a github URL which is 404ing: https://github.com/steveklabnik/simple-server/blob/c5499dc64def427d30d613c2087bec46072c4110/examples/server.rs

We could leverage async in this crate in various ways.

We didn't build this on top of tokio because we wanted to keep the code simple. However, we could optionally add it in one of two ways:

First, the bit that's the same in both of them: add an async Cargo feature that lets you turn async on. That way, without the flag, you get only sync io and little deps, but if you wanted it to be async, you could do so.

Option 1: new method

This option would add an alternate Server, AsyncServer. It would look something like this:

extern crate simple_server;

use simple_server::{AsyncServer, ok};


fn main() {
    let host = "127.0.0.1";
    let port = "7878";

    let server = AsycncServer::new(|request, mut response| {
        ok(response.body("Hello Rust!".as_bytes())?)
    });

    server.listen(host, port);
}

Option 2: add futures

Option two is, change the interface of Server to be futures-enabled generally. The futures crate has no dependencies, and so is still pretty small. Then, the switch would only be in the backend, not in the interface.

The tradeoff is basically, with one, we split the "ecosystem", as it were. Option 2 adds a small amount of complexity for the simple case, but unifies everything into one API.

from #1

    fn handler(request: Request<&[u8]>, response: &mut Response<&[u8]>) {
      println!("Request received. {} {}", request.method(), request.uri());
      *response.body_mut() = "Hello Rust!".as_bytes();
    };

I need to get the port from a TcpListener between when it is bound, and when the server starts listening, because the port isn't known until it is bound (ephemeral ports). But right now, Server::listen creates the TcpListener, so this can't be done. A method, maybe Server::listen_on_socket or something, that accepted a TcpListener would make this possible, and is very easy to add. I can open a PR if you're too busy, as long as I don't have to decide the method's name.

Right now, we only support a request of 512 bytes:

A real server should be able to handle larger requests.

Hi! Sorry I'm extremely new to Rust so I apologize in advance if this issue is not very useful, I'll try to provide as much information as I can!

I receive the following error very intermittently, maybe only 2-3 times over several dozen requests. I can't seem to trigger it with any pattern.

This repro occurred while requesting a 404-ing route from the routes example, but the first time I saw it I was requesting 127.0.0.1/hello which routes successfully, I just didn't have RUST_BACKTRACE=1 enabled so it didnt have a backtrace, it was the same HttpParse(Token) issue though.

• MacOS 10.12.6 (High Sierra)
• rustc 1.21.0 (3b72af97e 2017-10-09)
• cargo 0.22.0 (3423351a5 2017-10-06)
• Chrome Version 61.0.3163.100 (Official Build) (64-bit)

BHulcher-MBP:simple-server bhulcher$ RUST_LOG="simple_server=info,routes=info" RUST_BACKTRACE=1 cargo run --example routes
    Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
     Running `target/debug/examples/routes`
INFO:simple_server: Server started at http://127.0.0.1:7878
INFO:routes: Request received. GET /fdafdhsajfdlksfhdkjsadlhjafdlkshfkjhfkl
INFO:routes: Request received. GET /fdafdhsajfdlksfhdkjsadlhjafdlkshfkjhfkl
INFO:routes: Request received. GET /fdafdhsajfdlksfhdkjsadlhjafdlkshfkjhfkl
INFO:routes: Request received. GET /fdafdhsajfdlksfhdkjsadlhjafdlkshfkjhfkl
INFO:routes: Request received. GET /fdafdhsajfdlksfhdkjsadlhjafdlkshfkjhfkl
thread '<unnamed>' panicked at 'Error handling connection.: HttpParse(Token)', src/libcore/result.rs:906:4
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
   1: std::panicking::default_hook::{{closure}}
   2: std::panicking::default_hook
   3: std::panicking::rust_panic_with_hook
   4: std::panicking::begin_panic
   5: std::panicking::begin_panic_fmt
   6: rust_begin_unwind
   7: core::panicking::panic_fmt
   8: core::result::unwrap_failed
   9: <core::result::Result<T, E>>::expect
  10: simple_server::Server::listen::{{closure}}::{{closure}}
  11: <F as scoped_threadpool::FnBox>::call_box
  12: scoped_threadpool::Pool::new::{{closure}}
thread 'main' panicked at 'Thread pool worker panicked', /Users/bhulcher/.cargo/registry/src/github.com-1ecc6299db9ec823/scoped_threadpool-0.1.8/src/lib.rs:236:12
stack backtrace:
   0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
   1: std::panicking::default_hook::{{closure}}
   2: std::panicking::default_hook
   3: std::panicking::rust_panic_with_hook
   4: std::panicking::begin_panic
   5: scoped_threadpool::Scope::join_all
   6: <scoped_threadpool::Scope<'pool, 'scope> as core::ops::drop::Drop>::drop
   7: core::ptr::drop_in_place
   8: scoped_threadpool::Pool::scoped
   9: simple_server::Server::listen
  10: routes::main
  11: __rust_maybe_catch_panic
  12: std::rt::lang_start
  13: main

currently hardcoded at 4.

not urgent but nice to have

There's some small complexity here, but if / is requested, and we have a static file index.html, it should be served.

Server::new currently accepts only fn pointer, so if one wants to access a variable, it must be static.

Accepting closures would resolve this problem.

ya dingus

The listen method has multiple expects in it; that can trigger on invalid input.

As matklad points out, this should be documented in a "Panics" section of the docs.

• in case the host or port are wrong
• for TCP connection errors
• for handling a connection request
• there's also an 'unwrap' in there that I assume to be safe.

We serve static files, and check for . and .. in the path. This is probably not enough, but needs to be researched more.

from #1

*response.body_mut() = "Hello Rust!".as_bytes();