rust-http

//! A very simple HTTP server which responds with the plain text "Hello, World!" to every request. #![crate_id = "hello_world"] extern crate time; extern crate http; use std::io::net::ip::{SocketAddr, Ipv4Addr}; use std::io::Writer; use http::server::{Config, Server, Request, ResponseWriter}; use http::headers::content_type::MediaType; #[deriving(Clone)] struct HelloWorldServer; impl Server for HelloWorldServer { fn get_config(&self) -> Config { Config { bind_address: SocketAddr { ip: Ipv4Addr(127, 0, 0, 1), port: 8001 } } } fn handle_request(&self, _r: Request, w: &mut ResponseWriter) { w.headers.date = Some(time::now_utc()); w.headers.content_length = Some(14); w.headers.content_type = Some(MediaType { type_: String::from_str("text"), subtype: String::from_str("plain"), parameters: vec!((String::from_str("charset"), String::from_str("UTF-8"))) }); w.headers.server = Some(String::from_str("Example")); w.write(b"Hello, World!\n").unwrap(); } } fn main() { HelloWorldServer.serve_forever(); } Go (native) package main import ( "fmt" "net/http" ) func handler(w http.ResponseWriter, r *http.Request) { fmt.Fprintf(w, "Hi there, I love %s!", r.URL.Path[1:]) } func main() { http.HandleFunc("/", handler) http.ListenAndServe(":8080", nil) } Yeah, ok.

ResponseWriter}; use http::headers::content_type::MediaType; #[deriving(Clone)] struct HelloWorldServer; impl Server for HelloWorldServer { fn get_config(&self) -> Config { Config { bind_address: SocketAddr { ip: Ipv4Addr(127, 0, 0, 1), port: 8001 } } } fn handle_request(&self, _r: Request, w: &mut ResponseWriter) { w.headers.date = Some(time::now_utc()); w.headers.content_length = Some(14); w.headers.content_type = Some(MediaType { type_: String::from_str("text"), subtype: String::from_str("plain"), parameters: vec!((String::from_str("charset"), String::from_str("UTF-8"))) }); w.headers.server = Some(String::from_str("Example")); w.write(b"Hello, World!\n").unwrap(); } } fn main() { HelloWorldServer.serve_forever(); } ----- Go (native) package main import ( "fmt" "net/http" ) func handler(w http.ResponseWriter, r *http.Request) { fmt.Fprintf(w, "Hi there, I love %s!", r.URL.Path[1:]) } func main() { http.HandleFunc("/", handler) http.ListenAndServe(":8080", nil) } ----- Yeah, ok.

le slow lately since it became a group project for a class of mine, and that meant that I needed to manage several people working on it rather than actually contributing code. Over the summer I hope to get it in a good state and then make a post about it and fill out documentation, make tests, submit it to techempower benchmarks, and other necessities. Having said that, I'm not confident yet that you want to be coding a web site in rust. In the name of safety, rust's compiler can be very difficult to please and in the name of speed it doesn't compile blazingly fast as well. Some people may have a different opinion from me, but besides writing a web app to learn the rust language, what advantages for the web does rust give you that go or haskell doesn't? When you are writing a web app, developer productivity is priority number one (in my opinion), and having to fight the borrow/lifetime checker and trying to find out why your struct doesn't fulfil `Send` are not things I would like to have to do when I'm making a web site. The tradeoff will be that hopefully a web site written in rust will be both fast and concurrently safe, but you will be sacrificing developer productivity for the reasons mentioned above. Irregardless of those issues, I'm still very determined to make a rust web framework that is both fast and easy to develop for (probably by providing examples of common web idioms in oxidize so people can see how to do it), just, I want people that use my framework to be aware of the tradeoffs that they will make. In short, I consider oxidize an experiment in trying to make a powerful, expressive, and extensible web framework in rust, and along the way I've started to question whether this will have any practical applications, but in spite of that, I still am trying to achieve the previous listed goals.

position against this strong typing; I take a similarly strong position for such strong typing. Yes, HTTP headers are defined as simple key/value pairs. But headers are not text; they are data. XML is defined as text. Should we use regular expressions to work with it? (True, it also has the DOM defined. But HTTP headers also have a grammar defined—it just happens to include the admissibility of extension headers.) HTTP is a serialisation format for messages; messages made up of computer-readable data, not text. I wrote a handful of paragraphs about this subject at https://github.com/chris-morgan/rust-http/issues/1 where using a map instead of typed headers was suggested. As I also note there, I would not attempt such a scheme in a language like Python (my primary language for some years) because its type system is not well adjusted to something like this; I am certain it would cause many problems and feel it likely it would cause more than it solved. But in a language with a solid type system capable of expressing these things, taking advantage of it should lead to a faster, more correct program. In the end, I believe strongly typed headers are a good thing to have (it will actually make most code distinctly nicer—e.g. ``response.headers.date = Some(now())`` instead of ``response.headers.set("Date", now().to_http_header())``). The implementation of the scheme in rust-http is certainly not perfect yet; I'm not happy with it at present; I'm expecting to turn the extension headers into a trait object, and I've even considered crazy ideas like allowing users of the library to make their own header collection (request.headers and response.headers) types—that would allow custom headers to be made first-class citizens but could lead to compatibility problems. Still, I don't want to make something that I believe should be the best HTTP library around and find that people hate to use it. What do you think about this header matter?

ll in progress: https://github.com/chris-morgan/rust-http. When that's far enough along, then I'll get on to the framework I have in mind.

Head, "OPTIONS" => Options, "PATCH" => Patch, "POST" => Post, "PUT" => Put, "TRACE" => Trace ), 1, "self.stream.read_byte()", "SP", "MAX_METHOD_LEN", "is_token_item(b)", "ExtensionMethod(%s)"); This is pleasantly easy to read and meaningful. This generates the high performance artwork shown at http://sprunge.us/HdTH, which supports extension methods correctly. (Rust's algebraic data types are marvellous for many things in implementing such a spec.)