docs(lib): fix broken intra docs links
This commit is contained in:
@@ -160,7 +160,7 @@ impl Body {
|
||||
|
||||
/// Converts this `Body` into a `Future` of a pending HTTP upgrade.
|
||||
///
|
||||
/// See [the `upgrade` module](::upgrade) for more.
|
||||
/// See [the `upgrade` module](crate::upgrade) for more.
|
||||
pub fn on_upgrade(self) -> OnUpgrade {
|
||||
self.extra
|
||||
.map(|ex| ex.on_upgrade)
|
||||
@@ -496,7 +496,7 @@ impl Sender {
|
||||
///
|
||||
/// This is mostly useful for when trying to send from some other thread
|
||||
/// that doesn't have an async context. If in an async context, prefer
|
||||
/// [`send_data`][] instead.
|
||||
/// `send_data()` instead.
|
||||
pub fn try_send_data(&mut self, chunk: Bytes) -> Result<(), Bytes> {
|
||||
self.tx
|
||||
.try_send(Ok(chunk))
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
//! Streaming bodies for Requests and Responses
|
||||
//!
|
||||
//! For both [Clients](::client) and [Servers](::server), requests and
|
||||
//! For both [Clients](crate::client) and [Servers](crate::server), requests and
|
||||
//! responses use streaming bodies, instead of complete buffering. This
|
||||
//! allows applications to not use memory they don't need, and allows exerting
|
||||
//! back-pressure on connections by only reading when asked.
|
||||
//!
|
||||
//! There are two pieces to this in hyper:
|
||||
//!
|
||||
//! - **The [`HttpBody`](body::HttpBody) trait** describes all possible bodies.
|
||||
//! - **The [`HttpBody`](HttpBody) trait** describes all possible bodies.
|
||||
//! hyper allows any body type that implements `HttpBody`, allowing
|
||||
//! applications to have fine-grained control over their streaming.
|
||||
//! - **The [`Body`](Body) concrete type**, which is an implementation of
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
//!
|
||||
//! This module contains:
|
||||
//!
|
||||
//! - A [`GaiResolver`](dns::GaiResolver) that is the default resolver for the
|
||||
//! - A [`GaiResolver`](GaiResolver) that is the default resolver for the
|
||||
//! `HttpConnector`.
|
||||
//! - The `Name` type used as an argument to custom resolvers.
|
||||
//!
|
||||
|
||||
@@ -67,12 +67,12 @@
|
||||
//! ```
|
||||
//!
|
||||
//!
|
||||
//! [`HttpConnector`]: hyper::client::HttpConnector
|
||||
//! [`Service`]: hyper::service::Service
|
||||
//! [`HttpConnector`]: HttpConnector
|
||||
//! [`Service`]: crate::service::Service
|
||||
//! [`Uri`]: http::Uri
|
||||
//! [`AsyncRead`]: tokio::io::AsyncRead
|
||||
//! [`AsyncWrite`]: tokio::io::AsyncWrite
|
||||
//! [`Connection`]: hyper::client::connect::Connection
|
||||
//! [`Connection`]: Connection
|
||||
use std::fmt;
|
||||
|
||||
use ::http::Response;
|
||||
|
||||
@@ -3,7 +3,7 @@
|
||||
//! There are two levels of APIs provided for construct HTTP clients:
|
||||
//!
|
||||
//! - The higher-level [`Client`](Client) type.
|
||||
//! - The lower-level [`conn`](client::conn) module.
|
||||
//! - The lower-level [`conn`](conn) module.
|
||||
//!
|
||||
//! # Client
|
||||
//!
|
||||
|
||||
@@ -351,7 +351,7 @@ impl<E> Http<E> {
|
||||
}
|
||||
}
|
||||
|
||||
/// Bind a connection together with a [`Service`](::service::Service).
|
||||
/// Bind a connection together with a [`Service`](crate::service::Service).
|
||||
///
|
||||
/// This returns a Future that must be polled in order for HTTP to be
|
||||
/// driven on the connection.
|
||||
@@ -573,7 +573,7 @@ where
|
||||
|
||||
/// Enable this connection to support higher-level HTTP upgrades.
|
||||
///
|
||||
/// See [the `upgrade` module](::upgrade) for more.
|
||||
/// See [the `upgrade` module](crate::upgrade) for more.
|
||||
pub fn with_upgrades(self) -> UpgradeableConnection<I, S, E>
|
||||
where
|
||||
I: Send,
|
||||
|
||||
@@ -6,12 +6,12 @@
|
||||
//! There are two levels of APIs provide for constructing HTTP servers:
|
||||
//!
|
||||
//! - The higher-level [`Server`](Server) type.
|
||||
//! - The lower-level [`conn`](server::conn) module.
|
||||
//! - The lower-level [`conn`](conn) module.
|
||||
//!
|
||||
//! # Server
|
||||
//!
|
||||
//! The [`Server`](Server) is main way to start listening for HTTP requests.
|
||||
//! It wraps a listener with a [`MakeService`](::service), and then should
|
||||
//! It wraps a listener with a [`MakeService`](crate::service), and then should
|
||||
//! be executed to start serving requests.
|
||||
//!
|
||||
//! [`Server`](Server) accepts connections in both HTTP1 and HTTP2 by default.
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
//! Asynchronous Services
|
||||
//!
|
||||
//! A [`Service`](service::Service) is a trait representing an asynchronous
|
||||
//! A [`Service`](Service) is a trait representing an asynchronous
|
||||
//! function of a request to a response. It's similar to
|
||||
//! `async fn(Request) -> Result<Response, Error>`.
|
||||
//!
|
||||
@@ -22,11 +22,11 @@
|
||||
//! connection will receive.
|
||||
//!
|
||||
//! While it's possible to implement `Service` for a type manually, the helper
|
||||
//! [`service_fn`](service::service_fn) should be sufficient for most cases.
|
||||
//! [`service_fn`](service_fn) should be sufficient for most cases.
|
||||
//!
|
||||
//! # MakeService
|
||||
//!
|
||||
//! Since a `Service` is bound to a single connection, a [`Server`](::Server)
|
||||
//! Since a `Service` is bound to a single connection, a [`Server`](crate::Server)
|
||||
//! needs a way to make them as it accepts connections. This is what a
|
||||
//! `MakeService` does.
|
||||
//!
|
||||
|
||||
Reference in New Issue
Block a user