|
1 | 1 | //! HTTP Server
|
2 | 2 | //!
|
3 |
| -//! # Example |
| 3 | +//! # Server |
| 4 | +//! |
| 5 | +//! A `Server` is created to listen on port, parse HTTP requests, and hand |
| 6 | +//! them off to a `Handler`. By default, the Server will listen across multiple |
| 7 | +//! threads, but that can be configured to a single thread if preferred. |
| 8 | +//! |
| 9 | +//! # Handling requests |
| 10 | +//! |
| 11 | +//! You must pass a `Handler` to the Server that will handle requests. There is |
| 12 | +//! a default implementation for `fn`s and closures, allowing you pass one of |
| 13 | +//! those easily. |
| 14 | +//! |
| 15 | +//! |
| 16 | +//! ```no_run |
| 17 | +//! use hyper::server::{Server, Request, Response}; |
| 18 | +//! |
| 19 | +//! fn hello(req: Request, res: Response) { |
| 20 | +//! // handle things here |
| 21 | +//! } |
| 22 | +//! |
| 23 | +//! Server::http(hello).listen("0.0.0.0:0").unwrap(); |
| 24 | +//! ``` |
| 25 | +//! |
| 26 | +//! As with any trait, you can also define a struct and implement `Handler` |
| 27 | +//! directly on your own type, and pass that to the `Server` instead. |
| 28 | +//! |
| 29 | +//! ```no_run |
| 30 | +//! use std::sync::Mutex; |
| 31 | +//! use std::sync::mpsc::{channel, Sender}; |
| 32 | +//! use hyper::server::{Handler, Server, Request, Response}; |
| 33 | +//! |
| 34 | +//! struct SenderHandler { |
| 35 | +//! sender: Mutex<Sender<&'static str>> |
| 36 | +//! } |
| 37 | +//! |
| 38 | +//! impl Handler for SenderHandler { |
| 39 | +//! fn handle(&self, req: Request, res: Response) { |
| 40 | +//! self.sender.lock().unwrap().send("start").unwrap(); |
| 41 | +//! } |
| 42 | +//! } |
| 43 | +//! |
| 44 | +//! |
| 45 | +//! let (tx, rx) = channel(); |
| 46 | +//! Server::http(SenderHandler { |
| 47 | +//! sender: Mutex::new(tx) |
| 48 | +//! }).listen("0.0.0.0:0").unwrap(); |
| 49 | +//! ``` |
| 50 | +//! |
| 51 | +//! Since the `Server` will be listening on multiple threads, the `Handler` |
| 52 | +//! must implement `Sync`: any mutable state must be synchronized. |
| 53 | +//! |
| 54 | +//! ```no_run |
| 55 | +//! use std::sync::atomic::{AtomicUsize, Ordering}; |
| 56 | +//! use hyper::server::{Server, Request, Response}; |
| 57 | +//! |
| 58 | +//! let counter = AtomicUsize::new(0); |
| 59 | +//! Server::http(move |req: Request, res: Response| { |
| 60 | +//! counter.fetch_add(1, Ordering::Relaxed); |
| 61 | +//! }).listen("0.0.0.0:0").unwrap(); |
| 62 | +//! ``` |
| 63 | +//! |
| 64 | +//! # The `Request` and `Response` pair |
| 65 | +//! |
| 66 | +//! A `Handler` receives a pair of arguments, a `Request` and a `Response`. The |
| 67 | +//! `Request` includes access to the `method`, `uri`, and `headers` of the |
| 68 | +//! incoming HTTP request. It also implements `std::io::Read`, in order to |
| 69 | +//! read any body, such as with `POST` or `PUT` messages. |
| 70 | +//! |
| 71 | +//! Likewise, the `Response` includes ways to set the `status` and `headers`, |
| 72 | +//! and implements `std::io::Write` to allow writing the response body. |
| 73 | +//! |
| 74 | +//! ```no_run |
| 75 | +//! use std::io; |
| 76 | +//! use hyper::server::{Server, Request, Response}; |
| 77 | +//! use hyper::status::StatusCode; |
| 78 | +//! |
| 79 | +//! Server::http(|mut req: Request, mut res: Response| { |
| 80 | +//! match req.method { |
| 81 | +//! hyper::Post => { |
| 82 | +//! io::copy(&mut req, &mut res.start().unwrap()).unwrap(); |
| 83 | +//! }, |
| 84 | +//! _ => *res.status_mut() = StatusCode::MethodNotAllowed |
| 85 | +//! } |
| 86 | +//! }).listen("0.0.0.0:0").unwrap(); |
| 87 | +//! ``` |
| 88 | +//! |
| 89 | +//! ## An aside: Write Status |
| 90 | +//! |
| 91 | +//! The `Response` uses a phantom type parameter to determine its write status. |
| 92 | +//! What does that mean? In short, it ensures you never write a body before |
| 93 | +//! adding all headers, and never add a header after writing some of the body. |
| 94 | +//! |
| 95 | +//! This is often done in most implementations by include a boolean property |
| 96 | +//! on the response, such as `headers_written`, checking that each time the |
| 97 | +//! body has something to write, so as to make sure the headers are sent once, |
| 98 | +//! and only once. But this has 2 downsides: |
| 99 | +//! |
| 100 | +//! 1. You are typically never notified that your late header is doing nothing. |
| 101 | +//! 2. There's a runtime cost to checking on every write. |
| 102 | +//! |
| 103 | +//! Instead, hyper handles this statically, or at compile-time. A |
| 104 | +//! `Response<Fresh>` includes a `headers_mut()` method, allowing you add more |
| 105 | +//! headers. It also does not implement `Write`, so you can't accidentally |
| 106 | +//! write early. Once the "head" of the response is correct, you can "send" it |
| 107 | +//! out by calling `start` on the `Request<Fresh>`. This will return a new |
| 108 | +//! `Request<Streaming>` object, that no longer has `headers_mut()`, but does |
| 109 | +//! implement `Write`. |
4 | 110 | //!
|
5 | 111 | //! ```no_run
|
6 | 112 | //! use hyper::server::{Server, Request, Response};
|
|
0 commit comments