{
- if DB.contains_key(&id) {
- DB.insert(id, &message.contents);
- Json(json!{ "status": "ok" })
- } else {
- Json(json!{ "status": "error" })
- }
- }
-'''
-text = '''
- Rocket has first-class support for JSON, right out of the box. Simply derive
- `Deserialize` or `Serialize` to receive or return JSON, respectively.
-
- Like other important features, JSON works through Rocket’s `FromData` trait,
- Rocket’s approach to deriving types from body data. It works like this:
- specify a `data` route parameter of any type that implements `FromData`. A
- value of that type will then be created automatically from the incoming
- request body. Best of all, you can implement `FromData` for your types!
-'''
-
-###############################################################################
-# Buttom features: displayed above the footer.
-###############################################################################
-
-[[bottom_features]]
-title = 'Templating'
-text = "Rocket makes rendering templates a breeze with built-in templating support."
-image = 'templating-icon'
-url = '/guide/responses/#templates'
-button = 'Learn More'
-color = 'blue'
-
-[[bottom_features]]
-title = 'Cookies'
-text = "View, add, or remove cookies, with or without encryption, without hassle."
-image = 'cookies-icon'
-url = '/guide/requests/#cookies'
-button = 'Learn More'
-color = 'purple'
-margin = -6
-
-[[bottom_features]]
-title = 'Streams'
-text = "Rocket streams all incoming and outgoing data, so size isn't a concern."
-image = 'streams-icon'
-url = '/guide/requests/#streaming'
-button = 'Learn More'
-color = 'red'
-margin = -29
-
-[[bottom_features]]
-title = 'Config Environments'
-text = "Configure your application your way for development, staging, and production."
-image = 'config-icon'
-url = '/guide/configuration/#environment'
-button = 'Learn More'
-color = 'yellow'
-margin = -3
-
-[[bottom_features]]
-title = 'Query Strings'
-text = "Handling query strings and parameters is type-safe and easy in Rocket."
-image = 'query-icon'
-url = '/guide/requests/#query-strings'
-button = 'Learn More'
-color = 'orange'
-margin = -3
-
-[[bottom_features]]
-title = 'Testing Library'
-text = "Unit test your applications with ease using the built-in testing library."
-image = 'testing-icon'
-url = '/guide/testing#testing'
-button = 'Learn More'
-color = 'green'
-
-# Blocked on Hyper/OpenSSL.
-# [[bottom_features]]
-# title = 'Signed Sessions'
-# text = "Safe, secure, signed sessions are built-in to Rocket so your users can stay safe."
-# image = 'sessions-icon'
-# url = '/overview'
-# button = 'Learn More'
-# color = 'green'
diff --git a/site/news.toml b/site/news.toml
deleted file mode 100644
index 2af65223..00000000
--- a/site/news.toml
+++ /dev/null
@@ -1,33 +0,0 @@
-[[articles]]
-title = "Rocket v0.3: Fairings, TLS, Private Cookies"
-slug = "2017-07-14-version-0.3"
-author = "Sergio Benitez"
-author_url = "https://sergio.bz"
-date = "July 14, 2017"
-snippet = """
-I'm excited to announce that the next major release of Rocket is available
-today! Rocket 0.3 is packed with new features and improvements that increase
-developer productivity, improve application security, and provide new
-opportunities for extensibility. Rocket 0.3 is the culmination of almost 6
-months of work. During this time, more than 225 changes were committed, over 100
-issues (primarily questions and feature requests) were closed, and over 40 pull
-requests were submitted. The Rocket community has proven steadfast in their
-support: a sincere thank you to everyone involved!
-"""
-
-[[articles]]
-title = "Rocket v0.2: Managed State & More"
-slug = "2017-02-06-version-0.2"
-author = "Sergio Benitez"
-author_url = "https://sergio.bz"
-date = "February 06, 2017"
-snippet = """
-Today marks the first major release since Rocket's debut a little over a month
-ago. Rocket v0.2 packs a ton of new features, fixes, and general improvements.
-Much of the development in v0.2 was led by the community, either through reports
-via the [GitHub issue tracker](https://github.com/SergioBenitez/Rocket/issues)
-or via direct contributions. In fact, there have been **20 unique contributors**
-to Rocket's codebase since Rocket's initial introduction! Community feedback has
-been incredible. As a special thank you, we include the names of these
-contributors at the end of this article.
-"""
diff --git a/site/news/2017-02-06-version-0.2.md b/site/news/2017-02-06-version-0.2.md
deleted file mode 100644
index 0e2ebb93..00000000
--- a/site/news/2017-02-06-version-0.2.md
+++ /dev/null
@@ -1,396 +0,0 @@
-# Rocket v0.2: Managed State & More
-
-
- Posted by Sergio Benitez on February 06, 2017
-
-
-
-
-Today marks the first major release since Rocket's debut a little over a month
-ago. Rocket v0.2 packs a ton of new features, fixes, and general improvements.
-Much of the development in v0.2 was led by the community, either through reports
-via the [GitHub issue tracker](https://github.com/SergioBenitez/Rocket/issues)
-or via direct contributions. In fact, there have been **20 unique contributors**
-to Rocket's codebase since Rocket's initial introduction! Community feedback has
-been incredible. As a special thank you, we include the names of these
-contributors at the end of this article.
-
-## About Rocket
-
-Rocket is a web framework for Rust with a focus on ease of use, expressibility,
-and speed. Rocket makes it simple to write fast web applications without
-sacrificing flexibility or type safety. All with minimal code.
-
-> Rocket's so simple, you feel like you're doing something wrong. It's like if
-> you're making fire with rocks and suddenly someone gives you a lighter. Even
-> though you know the lighter makes fire, and does it even faster and better and
-> with a simple flick, the rock's still in your brain.
->
-> -- Artem "impowski" Biryukov, January 17, 2017, on **#rocket**
-
-## New Features
-
-Rocket v0.2 includes several new features that make developing Rocket
-applications simpler, faster, and safer than ever before.
-
-### Managed State
-
-Undoubtedly, the star feature of this release is **managed state**. Managed
-state allows you to pass state to Rocket prior to launching your application and
-later retrieve that state from any request handler by simply including the
-state's type in the function signature. It works in two easy steps:
-
- 1. Call `manage` on the `Rocket` instance corresponding to your application
- with the initial value of the state.
- 2. Add a `State` type to any request handler, where `T` is the type of the
- value passed into `manage`.
-
-Rocket takes care of the rest! `State` works through Rocket's [request
-guards](/guide/requests/#request-guards). You can call `manage` any number of
-times, as long as each call corresponds to a value of a different type.
-
-As a simple example, consider the following "hit counter" example application:
-
-```rust
-struct HitCount(AtomicUsize);
-
-#[get("/")]
-fn index(hit_count: State) -> &'static str {
- hit_count.0.fetch_add(1, Ordering::Relaxed);
- "Your visit has been recorded!"
-}
-
-#[get("/count")]
-fn count(hit_count: State) -> String {
- hit_count.0.load(Ordering::Relaxed).to_string()
-}
-
-fn main() {
- rocket::ignite()
- .mount("/", routes![index, count])
- .manage(HitCount(AtomicUsize::new(0)))
- .launch()
-}
-```
-
-Visiting `/` will record a visit by incrementing the hit count by 1. Visiting
-the `/count` path will display the current hit count.
-
-One concern when using _managed state_ is that you might forget to call `manage`
-with some state's value before launching your application. Not to worry: Rocket
-has your back! Let's imagine for a second that we forgot to add the call to
-`manage` on line 17 in the example above. Here's what the compiler would emit
-when we compile our buggy application:
-
-```rust
-warning: HitCount is not currently being managed by Rocket
- --> src/main.rs:4:21
- |
-4 | fn index(hit_count: State) -> &'static str {
- | ^^^^^^^^^^^^^^^
- |
- = note: this State request guard will always fail
-help: maybe add a call to 'manage' here?
- --> src/main.rs:15:5
- |
-15| rocket::ignite()
- | ^^^^^^^^^^^^^^^^
-
-warning: HitCount is not currently being managed by Rocket
- --> src/main.rs:10:21
- |
-10 | fn count(hit_count: State) -> String {
- | ^^^^^^^^^^^^^^^
- |
- = note: this State request guard will always fail
-help: maybe add a call to 'manage' here?
- --> src/main.rs:15:5
- |
-15 | rocket::ignite()
- | ^^^^^^^^^^^^^^^^
-```
-
-You can read more about managed state in the [guide](/guide/state/), the API
-docs for
-[manage](https://api.rocket.rs/rocket/struct.Rocket.html#method.manage), and the
-API docs for [State](https://api.rocket.rs/rocket/struct.State.html).
-
-### Unmounted Routes Lint
-
-A common mistake that new Rocketeers make is forgetting to
-[mount](/guide/overview/#mounting) declared routes. In Rocket v0.2, Rocket adds
-a _lint_ that results in a compile-time warning for unmounted routes. As a
-simple illustration, consider the canonical "Hello, world!" Rocket application
-below, and note that we've forgotten to mount the `hello` route:
-
-```rust
-#[get("/")]
-fn hello() -> &'static str {
- "Hello, world!"
-}
-
-fn main() {
- rocket::ignite().launch();
-}
-```
-
-When this program is compiled, the compiler emits the following warning:
-
-```rust
-warning: the 'hello' route is not mounted
- --> src/main.rs:2:1
- |
-2 | fn hello() -> &'static str {
- | _^ starting here...
-3 | | "Hello, world!"
-4 | | }
- | |_^ ...ending here
- |
- = note: Rocket will not dispatch requests to unmounted routes.
-help: maybe add a call to 'mount' here?
- --> src/main.rs:7:5
- |
-7 | rocket::ignite().launch();
- | ^^^^^^^^^^^^^^^^
-```
-
-The lint can be disabled selectively per route by adding an
-`#[allow(unmounted_route)]` annotation to a given route declaration. It can also
-be disabled globally by adding `#![allow(unmounted_route)]`. You can read more
-about this lint in the [codegen
-documentation](https://api.rocket.rs/rocket_codegen/index.html).
-
-### Configuration via Environment Variables
-
-A new feature that makes deploying Rocket apps to the cloud a little easier is
-configuration via environment variables. Simply put, any configuration parameter
-can be set via an environment variable of the form `ROCKET_{PARAM}`, where
-`{PARAM}` is the name of the configuration parameter. For example, to set the
-`port` Rocket listens on, simply set the `ROCKET_PORT` environment variable:
-
-```sh
-ROCKET_PORT=3000 cargo run --release
-```
-
-Configuration parameters set via environment variables take precedence over
-parameters set via the `Rocket.toml` configuration file. Note that _any_
-parameter can be set via an environment variable, include _extras_. For more
-about configuration in Rocket, see the [configuration section of the
-guide](/guide/overview/#configuration).
-
-### And Plenty More!
-
-Rocket v0.2 is full of many new features! In addition to the three features
-described above, v0.2 also includes the following:
-
- * `Config` structures can be built via `ConfigBuilder`, which follows the
- builder pattern.
- * Logging can be enabled or disabled on custom configuration via a second
- parameter to the `Rocket::custom` method.
- * `name` and `value` methods were added to `Header` to retrieve the name and
- value of a header.
- * A new configuration parameter, `workers`, can be used to set the number of
- threads Rocket uses.
- * The address of the remote connection is available via `Request.remote()`.
- Request preprocessing overrides remote IP with value from the `X-Real-IP`
- header, if present.
- * During testing, the remote address can be set via `MockRequest.remote()`.
- * The `SocketAddr` request guard retrieves the remote address.
- * A `UUID` type has been added to `contrib`.
- * `rocket` and `rocket_codegen` will refuse to build with an incompatible
- nightly version and emit nice error messages.
- * Major performance and usability improvements were upstreamed to the `cookie`
- crate, including the addition of a `CookieBuilder`.
- * When a checkbox isn't present in a form, `bool` types in a `FromForm`
- structure will parse as `false`.
- * The `FormItems` iterator can be queried for a complete parse via `completed`
- and `exhausted`.
- * Routes for `OPTIONS` requests can be declared via the `options` decorator.
- * Strings can be percent-encoded via `URI::percent_encode()`.
-
-## Breaking Changes
-
-This release includes several breaking changes. These changes are listed below
-along with a short note about how to handle the breaking change in existing
-applications.
-
- * **`Rocket::custom` takes two parameters, the first being `Config` by
- value.**
-
- A call in v0.1 of the form `Rocket::custom(&config)` is now
- `Rocket::custom(config, false)`.
-
- * **Tera templates are named without their extension.**
-
- A templated named `name.html.tera` is now simply `name`.
-
- * **`JSON` `unwrap` method has been renamed to `into_inner`.**
-
- A call to `.unwrap()` should be changed to `.into_inner()`.
-
- * **The `map!` macro was removed in favor of the `json!` macro.**
-
- A call of the form `map!{ "a" => b }` can be written as: `json!({ "a": b
- })`.
-
- * **The `hyper::SetCookie` header is no longer exported.**
-
- Use the `Cookie` type as an `Into` type directly.
-
- * **The `Content-Type` for `String` is now `text/plain`.**
-
- Use `content::HTML` for HTML-based `String` responses.
-
- * **`Request.content_type()` returns an `Option`.**
-
- Use `.unwrap_or(ContentType::Any)` to get the old behavior.
-
- * **The `ContentType` request guard forwards when the request has no
- `Content-Type` header.**
-
- Use an `Option` and `.unwrap_or(ContentType::Any)` for the old
- behavior.
-
- * **A `Rocket` instance must be declared _before_ a `MockRequest`.**
-
- Change the order of the `rocket::ignite()` and `MockRequest::new()` calls.
-
- * **A route with `format` specified only matches requests with the same
- format.**
-
- Previously, a route with a `format` would match requests without a format
- specified. There is no workaround to this change; simply specify formats
- when required.
-
- * **`FormItems` can no longer be constructed directly.**
-
- Instead of constructing as `FormItems(string)`, construct as
- `FormItems::from(string)`.
-
- * **`from_from_string(&str)` in `FromForm` removed in favor of
- `from_form_items(&mut FormItems)`.**
-
- Most implementation should be using `FormItems` internally; simply use the
- passed in `FormItems`. In other cases, the form string can be retrieved via
- the `inner_str` method of `FormItems`.
-
- * **`Config::{set, default_for}` are deprecated.**
-
- Use the `set_{param}` methods instead of `set`, and `new` or `build` in
- place of `default_for`.
-
- * **Route paths must be absolute.**
-
- Prepend a `/` to convert a relative path into an absolute one.
-
- * **Route paths cannot contain empty segments.**
-
- Remove any empty segments, including trailing ones, from a route path.
-
-## Bug Fixes
-
-Three bugs were fixed in this release:
-
- * Handlebars partials were not properly registered
- ([#122](https://github.com/SergioBenitez/Rocket/issues/122)).
- * `Rocket::custom` did not set the custom configuration as the `active`
- configuration.
- * Route path segments with more than one dynamic parameter were erroneously
- allowed.
-
-## General Improvements
-
-In addition to new features, Rocket saw the following smaller improvements:
-
- * Rocket no longer overwrites a catcher's response status.
- * The `port` `Config` type is now a proper `u16`.
- * Clippy issues injected by codegen are resolved.
- * Handlebars was updated to `0.25`.
- * The `PartialEq` implementation of `Config` doesn't consider the path or
- session key.
- * Hyper dependency updated to `0.10`.
- * The `Error` type for `JSON as FromData` has been exposed as `SerdeError`.
- * SVG was added as a known Content-Type.
- * Serde was updated to `0.9`.
- * Form parse failure now results in a **422** error code.
- * Tera has been updated to `0.7`.
- * `pub(crate)` is used throughout to enforce visibility rules.
- * Query parameters in routes (`/path?`) are now logged.
- * Routes with and without query parameters no longer _collide_.
-
-Rocket v0.2 also includes all of the new features, bug fixes, and improvements
-from versions 0.1.1 through 0.1.6. You can read more about these changes in the
-[v0.1
-CHANGELOG](https://github.com/SergioBenitez/Rocket/blob/v0.1/CHANGELOG.md).
-
-## What's next?
-
-Work now begins on Rocket v0.3! The focus of the next major release will be on
-security. In particular, three major security features are planned:
-
- 1. **Automatic CSRF protection across all payload-based requests
- ([#14](https://github.com/SergioBenitez/Rocket/issues/14)).**
-
- Rocket will automatically check the origin of requests made for HTTP `PUT`,
- `POST`, `DELETE`, and `PATCH` requests, allowing only authorized requests to
- be dispatched. This includes checking `POST`s from form submissions and any
- requests made via JavaScript.
-
- 2. **Encryption and signing of session-based cookies
- ([#20](https://github.com/SergioBenitez/Rocket/issues/20)).**
-
- Built-in session support will encrypt and sign cookies using a user supplied
- `session_key`. Encryption and signing will occur automatically for
- session-based cookies.
-
- 3. **Explicit typing of raw HTTP data strings
- ([#43](https://github.com/SergioBenitez/Rocket/issues/43)).**
-
- A present, the standard `&str` type is used to represent raw HTTP data
- strings. In the next release, a new type, `&RawStr`, will be used for this
- purpose. This will make it clear when raw data is being handled. The type
- will expose convenient methods such as `.url_decode()` and `.html_escape()`.
-
-Work on Rocket v0.3 will also involve exploring built-in support for user
-authentication and authorization as well as automatic parsing of multipart
-forms.
-
-## Contributors to v0.2
-
-The following wonderful people helped make Rocket v0.2 happen:
-
-
- - Cliff H
- - Dru Sellers
- - Eijebong
- - Eric D. Reichert
- - Ernestas Poskus
- - FliegendeWurst
- - Garrett Squire
- - Giovanni Capuano
- - Greg Edwards
- - Joel Roller
- - Josh Holmer
- - Liigo Zhuang
- - Lori Holden
- - Marcus Ball
- - Matt McCoy
- - Reilly Tucker Siemens
- - Robert Balicki
- - Sean Griffin
- - Seth Lopez
- - tborsa
-
-
-Thank you all! Your contributions are greatly appreciated!
-
-Looking to help with Rocket's development? Head over to [Rocket's
-GitHub](https://github.com/SergioBenitez/Rocket#contributing) and start
-contributing!
-
-## Start using Rocket today!
-
-Not already using Rocket? Rocket is extensively documented, making it easy for
-you to start writing your web applications in Rocket! See the
-[overview](/overview) or start writing code immediately by reading through [the
-guide](/guide).
diff --git a/site/news/2017-07-14-version-0.3.md b/site/news/2017-07-14-version-0.3.md
deleted file mode 100644
index ff6b36cc..00000000
--- a/site/news/2017-07-14-version-0.3.md
+++ /dev/null
@@ -1,331 +0,0 @@
-# Rocket v0.3: Fairings, TLS, Private Cookies
-
-
- Posted by Sergio Benitez on July 14, 2017
-
-
-I'm excited to announce that the next major release of Rocket is available
-today! Rocket 0.3 is packed with new features and improvements that increase
-developer productivity, improve application security, and provide new
-opportunities for extensibility. Rocket 0.3 is the culmination of almost 6
-months of work. During this time, more than 225 changes were committed, over 100
-issues (primarily questions and feature requests) were closed, and over 40 pull
-requests were submitted. The Rocket community has proven steadfast in their
-support: a sincere thank you to everyone involved!
-
-## About Rocket
-
-Rocket is a web framework for Rust with a focus on ease of use, expressibility,
-and speed. Rocket makes it simple to write fast web applications without
-sacrificing flexibility or type safety. All with minimal code.
-
-Not already using Rocket? Join the thousands of users and dozens of companies
-happily using Rocket today! Rocket's extensive documentation makes it easy. Get
-started now by [reading through the guide](/guide) or learning more from [the
-overview](/overview).
-
-## What's New?
-
-Rocket 0.3 is a _big_ release, packed with over 100 changes. We highlight the
-biggest new features here. For a complete description of everything new and
-different in 0.3, please see the [CHANGELOG].
-
-[CHANGELOG]: https://github.com/SergioBenitez/Rocket/blob/v0.3.0/CHANGELOG.md#version-030-jul-14-2017
-
-### Fairings
-
-Fairings bring structured middleware to Rocket. With fairings, Rocket
-applications can hook into the application lifecycle to record or rewrite
-information about incoming requests, outgoing responses, and the Rocket
-application itself.
-
-Rocket's fairings are a lot like middleware from other frameworks, but they bear
-a few key distinctions:
-
- * Fairings cannot directly terminate or respond to an incoming request.
- * Fairings cannot inject arbitrary, non-request data into a request.
- * Fairings _can_ prevent an application from launching.
- * Fairings _can_ inspect and modify the application's configuration.
-
-Fairings are implemented through Rocket's [`Fairing`] trait. The trait consists
-of callback methods that Rocket invokes as needed. A fairing can subscribe to
-receive callbacks for the following four events:
-
- * **Attach**: called when a fairing is first registered.
- * **Launch**: called immediately before the Rocket application launches.
- * **Request**: called just after a request is received.
- * **Response**: called when a response is ready to be returned.
-
-The new [fairings guide] describes fairings in detail, expands on their
-limitations and abilities, and includes implementation examples. I encourage you
-to experiment with fairings and report your experiences. As always, feedback is
-instrumental in solidifying a robust design.
-
-[`Fairing`]: https://api.rocket.rs/rocket/fairing/trait.Fairing.html
-[fairings guide]: /guide/fairings
-
-### Native TLS Support
-
-Rocket 0.3 includes built-in, experimental support for TLS, powered by
-[`rustls`]. To enable TLS support, compile Rocket with the `tls` feature
-enabled. Then, configure file paths to an RSA certificate chain and
-corresponding private key in the `Rocket.toml` file or via environment
-variables:
-
-```toml
-[global.tls]
-certs = "/path/to/certs.pem"
-key = "/path/to/key.pem"
-```
-
-TLS support in Rocket is experimental and not yet recommended for general use
-over the internet. Instead, prefer to place Rocket behind a mature reverse-proxy
-such as NGINX. That being said, use of Rocket's TLS support is encouraged for
-local networking (such as local-only IoT devices) or as required during
-development.
-
-For more details on Rocket's TLS support, see the [configuring TLS] section of
-the guide.
-
-[`rustls`]: https://github.com/ctz/rustls
-[configuring TLS]: /guide/configuration/#configuring-tls
-
-### Private Cookies
-
-In Rocket 0.3, cookies can be _private_. Private cookies are encrypted using
-authenticated encryption, a form of encryption which simultaneously provides
-confidentiality, integrity, and authenticity. This means that private cookies
-cannot be inspected, tampered with, or manufactured by clients.
-
-Retrieving, adding, and removing private cookies is done via the new
-[`get_private`], [`add_private`], and [`remove_private`] methods on the
-[`Cookies`] type. As an example, consider the code below which sets and
-retrieves a `user_id` private cookie in two routes:
-
-```rust
-/// Retrieve the user's ID, if any.
-#[get("/user_id")]
-fn user_id(cookies: Cookies) -> Option {
- request.cookies()
- .get_private("user_id")
- .map(|cookie| format!("User ID: {}", cookie.value()))
-}
-
-/// Remove the `user_id` cookie.
-#[post("/logout")]
-fn logout(mut cookies: Cookies) -> Flash {
- cookies.remove_private(Cookie::named("user_id"));
- Flash::success(Redirect::to("/"), "Successfully logged out.")
-}
-```
-
-To encrypt private cookies, Rocket uses the 256-bit key specified in the
-`secret_key` configuration parameter. If one is not specified, Rocket
-automatically generates a fresh key at launch.
-
-For more details on private cookies, see the [private cookies] section of the
-guide.
-
-[`Cookies`]: https://api.rocket.rs/rocket/http/enum.Cookies.html
-[`get_private`]: https://api.rocket.rs/rocket/http/enum.Cookies.html#method.get_private
-[`add_private`]: https://api.rocket.rs/rocket/http/enum.Cookies.html#method.add_private
-[`remove_private`]: https://api.rocket.rs/rocket/http/enum.Cookies.html#method.remove_private
-[private cookies]: /guide/requests/#private-cookies
-
-### Form Field Naming
-
-In 0.2 and below, Rocket always matches form field names to structure field
-names exactly when deriving [`FromForm`]. This presented an issue when an
-invalid Rust identifier was used as a form field's name. For example, it was not
-possible to represent a form with a field name of "type" since `type` is a
-keyword and thus an illegal identifier. The following resulted in a compile-time
-error:
-
-```rust
-#[derive(FromForm)]
-struct External {
- type: String
-}
-```
-
-In Rocket 0.3, you can ask Rocket to match against a different form field for a
-given structure field by using the `#[form(field = "name")]` field annotation.
-As a result, the "type" form field can now be captured using something like the
-following:
-
-```rust
-#[derive(FromForm)]
-struct External {
- #[form(field = "type")]
- api_type: String
-}
-```
-
-Rocket will automatically match the form field named "type" to the structure
-field named `api_type`. For more details on form field naming, see the [field
-renaming](/guide/requests/#field-renaming) section of the guide.
-
-[`FromForm`]: https://api.rocket.rs/rocket/request/trait.FromForm.html
-
-### And Plenty More!
-
-In addition to the four highlighted above, Rocket 0.3 also ships with the
-following new features:
-
- * A [`MsgPack`] type has been added for simple consumption and returning of
- MessagePack data.
- * [`Rocket::launch()`] returns launch failures ([`LaunchError`]) for
- inspection without panicking.
- * Routes without query parameters now match requests with or without query
- parameters.
- * [Default rankings] prefer static paths and routes with query string matches.
- * A native [`Accept`] header structure was added.
- * The [`Accept`] request header can be retrieved via [`Request::accept()`].
- * All active routes can be retrieved via [`Rocket::routes()`].
- * [`Response::body_string()`] was added to retrieve the response body as a
- `String`.
- * [`Response::body_bytes()`] was added to retrieve the response body as a
- `Vec`.
- * [`Response::content_type()`] was added to retrieve the Content-Type header
- of a response.
- * Data limits on incoming data are [now
- configurable](/guide/configuration/#data-limits).
- * [`Request::limits()`] was added to retrieve incoming data limits.
- * Responders may dynamically adjust their response based on the incoming
- request.
- * [`Request::guard()`] was added for simple retrieval of request guards.
- * [`Request::route()`] was added to retrieve the active route, if any.
- * [`&Route`] is now a request guard.
- * The base mount path of a [`Route`] can be retrieved via `Route::base` or
- `Route::base()`.
- * `Config::{development, staging, production}` constructors were added for
- [`Config`].
- * [`Config::get_datetime()`] was added to retrieve an extra as a `Datetime`.
- * Forms can be now parsed _leniently_ via the new [`LenientForm`] data guard.
- * The `?` operator can now be used with `Outcome`.
- * Quoted string, array, and table [configuration parameters] can be set via
- environment variables.
- * Log coloring is disabled when `stdout` is not a TTY.
- * [`FromForm`] is implemented for `Option`, `Result`.
- * The [`NotFound`] responder was added for simple **404** response
- construction.
-
-[`MsgPack`]: https://api.rocket.rs/rocket_contrib/struct.MsgPack.html
-[`Rocket::launch()`]: https://api.rocket.rs/rocket/struct.Rocket.html#method.launch
-[`LaunchError`]: https://api.rocket.rs/rocket/error/struct.LaunchError.html
-[Default rankings]: https://api.rocket.rs/rocket/struct.Route.html
-[`&Route`]: https://api.rocket.rs/rocket/struct.Route.html
-[`Route`]: https://api.rocket.rs/rocket/struct.Route.html
-[`Accept`]: https://api.rocket.rs/rocket/http/struct.Accept.html
-[`Request::accept()`]: https://api.rocket.rs/rocket/struct.Request.html#method.accept
-[`contrib`]: https://api.rocket.rs/rocket_contrib/
-[`Rocket::routes()`]: https://api.rocket.rs/rocket/struct.Rocket.html#method.routes
-[`Response::body_string()`]: https://api.rocket.rs/rocket/struct.Response.html#method.body_string
-[`Response::body_bytes()`]: https://api.rocket.rs/rocket/struct.Response.html#method.body_bytes
-[`Response::content_type()`]: https://api.rocket.rs/rocket/struct.Response.html#method.content_type
-[`Request::guard()`]: https://api.rocket.rs/rocket/struct.Request.html#method.guard
-[`Request::limits()`]: https://api.rocket.rs/rocket/struct.Request.html#method.limits
-[`Request::route()`]: https://api.rocket.rs/rocket/struct.Request.html#method.route
-[`Config`]: https://api.rocket.rs/rocket/struct.Config.html
-[`Cookies`]: https://api.rocket.rs/rocket/http/enum.Cookies.html
-[`Config::get_datetime()`]: https://api.rocket.rs/rocket/struct.Config.html#method.get_datetime
-[`LenientForm`]: https://api.rocket.rs/rocket/request/struct.LenientForm.html
-[configuration parameters]: https://api.rocket.rs/rocket/config/index.html#environment-variables
-[`NotFound`]: https://api.rocket.rs/rocket/response/status/struct.NotFound.html
-
-## Breaking Changes
-
-This release includes many breaking changes such as support for `serde` 1.0. To
-keep this release note short, please see the
-[CHANGELOG](https://github.com/SergioBenitez/Rocket/blob/v0.3.0/CHANGELOG.md#breaking-changes)
-for the full list of breaking changes along with a short note about how to
-handle the breaking change in existing applications.
-
-## General Improvements
-
-In addition to new features, Rocket saw the following improvements:
-
- * "Rocket" is now capitalized in the `Server` HTTP header.
- * The generic parameter of `rocket_contrib::Json` defaults to `json::Value`.
- * The trailing '...' in the launch message was removed.
- * The launch message prints regardless of the config environment.
- * For debugging, `FromData` is implemented for `Vec` and `String`.
- * The port displayed on launch is the port resolved, not the one configured.
- * The `uuid` dependency was updated to `0.5`.
- * The `base64` dependency was updated to `0.6`.
- * The `toml` dependency was updated to `0.4`.
- * The `handlebars` dependency was updated to `0.27`.
- * The `tera` dependency was updated to `0.10`.
- * [`yansi`] is now used for all terminal coloring.
- * The `dev` `rustc` release channel is supported during builds.
- * [`Config`] is now exported from the root.
- * [`Request`] implements `Clone` and `Debug`.
- * The `workers` config parameter now defaults to `num_cpus * 2`.
- * Console logging for table-based config values is improved.
- * `PartialOrd`, `Ord`, and `Hash` are now implemented for [`State`].
- * The format of a request is always logged when available.
-
-[`yansi`]: https://crates.io/crates/yansi
-[`Request`]: https://api.rocket.rs/rocket/struct.Request.html
-[`State`]: https://api.rocket.rs/rocket/struct.State.html
-[`Config`]: https://api.rocket.rs/rocket/struct.Config.html
-
-## What's Next?
-
-Rocket 0.4, of course! The focus of the next major release is two-fold: security
-and usability. The following major features are planned:
-
- 1. **Automatic CSRF protection across all payload-based requests
- ([#14](https://github.com/SergioBenitez/Rocket/issues/14)).**
-
- This is a carry-over from the 0.3 wishlist. Rocket will automatically check
- the origin of requests made for HTTP `PUT`, `POST`, `DELETE`, and `PATCH`
- requests, allowing only valid requests to be dispatched. This includes
- checking form submissions and requests made via JavaScript.
-
- 2. **First-class database support
- ([#167](https://github.com/SergioBenitez/Rocket/issues/167)).**
-
- Connecting a database to Rocket is presently [much wordier than necessary].
- The plan for 0.4 is to minimize the amount of effort. At most, a couple of
- lines of configuration and a single line of initialization code should be
- required.
-
- 3. **Typed URL generation from routes
- ([#263](https://github.com/SergioBenitez/Rocket/issues/263)).**
-
- Explicitly writing URLs is error-prone. Because routes are fully-typed in
- Rocket, it's possible to check that a URL corresponding to a route
- type-checks. In the next release, a `url!` macro will be available to
- automatically generate URLs for routes in a type-safe manner.
-
-[much wordier than necessary]: /guide/state/#databases
-
-## Contributors to v0.3
-
-The following wonderful people helped make Rocket v0.3 happen:
-
-
- - Alan Stoate
- - Alexey Zabelin
- - Anton Pirker
- - Fabrice Desré
- - Ivar Abrahamsen
- - Josh Holmer
- - Joshua Rombauer
- - Lance Carlson
- - Lori Holden
- - Roman Frołow
- - Ryan Leckey
- - Stephan Buys
- - Tomek Wałkuski
- - Vesa Kaihlavirta
- - Yong Wen Chua
-
-
-Thank you all! Your contributions are greatly appreciated!
-
-Looking to help with Rocket's development? Head over to [Rocket's
-GitHub](https://github.com/SergioBenitez/Rocket#contributing) and start
-contributing!
diff --git a/site/overview.toml b/site/overview.toml
deleted file mode 100644
index e4d7ba0a..00000000
--- a/site/overview.toml
+++ /dev/null
@@ -1,232 +0,0 @@
-###############################################################################
-# Panels: displayed in a tabbed arrangement.
-###############################################################################
-
-[[panels]]
-name = "Routing"
-checked = true
-content = '''
-Rocket's main task is to route incoming requests to the appropriate request
-handler using your application's declared routes. Routes are declared using
-Rocket's _route_ attributes. The attribute describes the requests that match the
-route. The attribute is placed on top of a function that is the request handler
-for that route.
-
-As an example, consider the simple route below:
-
-```rust
-#[get("/")]
-fn index() -> &'static str {
- "Hello, world!"
-}
-```
-
-This route, named `index`, will match against incoming HTTP `GET` requests to
-the `/` path, the index. The request handler returns a string. Rocket will use
-the string as the body of a fully formed HTTP response.
-'''
-
-[[panels]]
-name = "Dynamic Params"
-content = '''
-Rocket allows you to interpret segments of a request path dynamically. To
-illustrate, let's use the following route:
-
-```rust
-#[get("/hello//")]
-fn hello(name: &str, age: u8) -> String {
- format!("Hello, {} year old named {}!", age, name)
-}
-```
-
-The `hello` route above matches two dynamic path segments declared inside
-brackets in the path: `` and ``. _Dynamic_ means that the segment can
-be _any_ value the end-user desires.
-
-Each dynamic parameter (`name` and `age`) must have a type, here `&str` and
-`u8`, respectively. Rocket will attempt to parse the string in the parameter's
-position in the path into that type. The route will only be called if parsing
-succeeds. To parse the string, Rocket uses the
-[FromParam](https://api.rocket.rs/rocket/request/trait.FromParam.html) trait,
-which you can implement for your own types!
-'''
-
-[[panels]]
-name = "Handling Data"
-content = '''
-Request body data is handled in a special way in Rocket: via the
-[FromData](https://api.rocket.rs/rocket/data/trait.FromData.html) trait. Any
-type that implements `FromData` can be derived from incoming body data. To tell
-Rocket that you're expecting request body data, the `data` route argument is
-used with the name of the parameter in the request handler:
-
-```rust
-#[post("/login", data = "")]
-fn login(user_form: Form) -> String {
- // Use `user_form`, return a String.
-}
-```
-
-The `login` route above says that it expects `data` of type `Form` in
-the `user_form` parameter. The
-[Form](https://api.rocket.rs/rocket/request/struct.Form.html) type is a built-in
-Rocket type that knows how to parse web forms into structures. Rocket will
-automatically attempt to parse the request body into the `Form` and call the
-`login` handler if parsing succeeds. Other built-in `FromData` types include
-[`Data`](https://api.rocket.rs/rocket/struct.Data.html),
-[`Json`](https://api.rocket.rs/rocket_contrib/struct.Json.html), and
-[`Flash`](https://api.rocket.rs/rocket/response/struct.Flash.html)
-'''
-
-[[panels]]
-name = "Request Guards"
-content = '''
-In addition to dynamic path and data parameters, request handlers can also
-contain a third type of parameter: _request guards_. Request guards aren't
-declared in the route attribute, and any number of them can appear in the
-request handler signature.
-
-Request guards _protect_ the handler from running unless some set of conditions
-are met by the incoming request metadata. For instance, if you are writing an
-API that requires sensitive calls to be accompanied by an API key in the request
-header, Rocket can protect those calls via a custom `ApiKey` request guard:
-
-```rust
-#[get("/sensitive")]
-fn sensitive(key: ApiKey) -> &'static str { ... }
-```
-
-`ApiKey` protects the `sensitive` handler from running incorrectly. In order for
-Rocket to call the `sensitive` handler, the `ApiKey` type needs to be derived
-through a
-[FromRequest](https://api.rocket.rs/rocket/request/trait.FromRequest.html)
-implementation, which in this case, validates the API key header. Request guards
-are a powerful and unique Rocket concept; they centralize application policy and
-invariants through types.
-'''
-
-[[panels]]
-name = "Responders"
-content = '''
-The return type of a request handler can be any type that implements
-[Responder](https://api.rocket.rs/rocket/response/trait.Responder.html):
-
-```rust
-#[get("/")]
-fn route() -> T { ... }
-```
-
-Above, T must implement `Responder`. Rocket implements `Responder` for many of
-the standard library types including `&str`, `String`, `File`, `Option`, and
-`Result`. Rocket also implements custom responders such as
-[Redirect](https://api.rocket.rs/rocket/response/struct.Redirect.html),
-[Flash](https://api.rocket.rs/rocket/response/struct.Flash.html), and
-[Template](https://api.rocket.rs/rocket_contrib/struct.Template.html).
-
-The task of a `Responder` is to generate a
-[`Response`](https://api.rocket.rs/rocket/response/struct.Response.html), if
-possible. `Responder`s can fail with a status code. When they do, Rocket calls
-the corresponding error catcher, a `catch` route, which can be declared as
-follows:
-
-```rust
-#[catch(404)]
-fn not_found() -> T { ... }
-```
-'''
-
-[[panels]]
-name = "Launching"
-content = '''
-Launching a Rocket application is the funnest part! For Rocket to begin
-dispatching requests to routes, the routes need to be _mounted_. After mounting,
-the application needs to be _launched_. These two steps, usually done in `main`,
-look like:
-
-```rust
-rocket::ignite()
- .mount("/base", routes![index, another])
- .launch()
-```
-
-The `mount` call takes a base path and a set of routes via the `routes!` macro.
-The base path (`/base` above) is prepended to the path of every route in the
-list. This effectively namespaces the routes, allowing for easier composition.
-
-The `launch` call starts the server. In development, Rocket prints useful
-information to the console to let you know everything is okay.
-
-```sh
-🚀 Rocket has launched from http://localhost:8000...
-```
-'''
-
-###############################################################################
-# Steps to "How Rocket Works"
-###############################################################################
-
-[[steps]]
-name = "Validation"
-color = "blue"
-content = '''
-First, Rocket validates a matching request by ensuring that all of the types in
-a given handler can be derived from the incoming request. If the types cannot be
-derived, the request is forwarded to the next matching route until a route’s
-types validate or there are no more routes to try. If all routes fail, a
-customizable **404** error is returned.
-
-```rust
-#[post("/user", data = "")]
-fn new_user(admin: AdminUser, new_user: Form) -> T {
- ...
-}
-```
-
-For the `new_user` handler above to be called, the following conditions must
-hold:
-
-* The request method must be `POST`.
-* The request path must be `/user`.
-* The request must contain `data` in its body.
-* The request metadata must authenticate an `AdminUser`.
-* The request body must be a form that parses into a `User` struct.
-'''
-
-[[steps]]
-name = "Processing"
-color = "purple"
-content = '''
-Next, the request is processed by an arbitrary handler. This is where most of
-the business logic in an application resides, and the part of your applications
-you’ll likely spend the most time writing. In Rocket, handlers are simply
-functions - that’s it! The only caveat is that the function’s return type must
-implement the `Responder` trait. The `new_user` function above is an example of
-a handler.
-'''
-
-[[steps]]
-name = "Response"
-color = "red"
-content = '''
-Finally, Rocket responds to the client by transforming the return value of the
-handler into an HTTP response. The HTTP response generated from the returned
-value depends on the type’s specific `Responder` trait implementation.
-
-```rust
-fn route() -> T { ... }
-```
-
-If the function above is used as a handler, for instance, then the type `T` must
-implement `Responder`. Rocket provides many useful responder types out of the
-box. They include:
-
- * `Json`: Serializes the structure T into JSON and returns it to
- the client.
- * `Template`: Renders a template file and returns it to the client.
- * `Redirect`: Returns a properly formatted HTTP redirect.
- * `NamedFile`: Streams a given file to the client with the
- Content-Type taken from the file’s extension.
- * `Stream`: Streams data to the client from an arbitrary `Read` value.
- * Many Primitive Types: `String`, `&str`, `File`, `Option`, `Result`, and
- others all implement the `Responder` trait.
-'''