mirror of
https://github.com/tokio-rs/axum.git
synced 2024-11-21 14:46:32 +01:00
Grammar: Fix "it's" vs "its" in several places (#2518)
This commit is contained in:
parent
94901e0fe7
commit
934b1aac06
12 changed files with 16 additions and 16 deletions
|
@ -47,7 +47,7 @@ use std::{
|
|||
/// MyError::SomethingElseWentWrong => "something else went wrong",
|
||||
/// };
|
||||
///
|
||||
/// // its often easiest to implement `IntoResponse` by calling other implementations
|
||||
/// // it's often easiest to implement `IntoResponse` by calling other implementations
|
||||
/// (StatusCode::INTERNAL_SERVER_ERROR, body).into_response()
|
||||
/// }
|
||||
/// }
|
||||
|
|
|
@ -44,7 +44,7 @@ use std::{convert::Infallible, fmt};
|
|||
/// }
|
||||
/// }
|
||||
///
|
||||
/// // Its also recommended to implement `IntoResponse` so `SetHeader` can be used on its own as
|
||||
/// // It's also recommended to implement `IntoResponse` so `SetHeader` can be used on its own as
|
||||
/// // the response
|
||||
/// impl<'a> IntoResponse for SetHeader<'a> {
|
||||
/// fn into_response(self) -> Response {
|
||||
|
|
|
@ -55,7 +55,7 @@ pin_project! {
|
|||
/// JsonLines::new(stream_of_values()).into_response()
|
||||
/// }
|
||||
/// ```
|
||||
// we use `AsExtractor` as the default because you're more likely to name this type if its used
|
||||
// we use `AsExtractor` as the default because you're more likely to name this type if it's used
|
||||
// as an extractor
|
||||
#[must_use]
|
||||
pub struct JsonLines<S, T = AsExtractor> {
|
||||
|
|
|
@ -321,7 +321,7 @@ where
|
|||
/// Utility trait used with [`RouterExt`] to ensure the second element of a tuple type is a
|
||||
/// given type.
|
||||
///
|
||||
/// If you see it in type errors its most likely because the second argument to your handler doesn't
|
||||
/// If you see it in type errors it's most likely because the second argument to your handler doesn't
|
||||
/// implement [`TypedPath`].
|
||||
///
|
||||
/// You normally shouldn't have to use this trait directly.
|
||||
|
|
|
@ -1003,7 +1003,7 @@ fn infer_state_type_from_field_attributes(fields: &Fields) -> impl Iterator<Item
|
|||
match fields {
|
||||
Fields::Named(fields_named) => {
|
||||
Box::new(fields_named.named.iter().filter_map(|field| {
|
||||
// TODO(david): its a little wasteful to parse the attributes again here
|
||||
// TODO(david): it's a little wasteful to parse the attributes again here
|
||||
// ideally we should parse things once and pass the data down
|
||||
let FromRequestFieldAttrs { via } =
|
||||
parse_attrs("from_request", &field.attrs).ok()?;
|
||||
|
@ -1013,7 +1013,7 @@ fn infer_state_type_from_field_attributes(fields: &Fields) -> impl Iterator<Item
|
|||
}
|
||||
Fields::Unnamed(fields_unnamed) => {
|
||||
Box::new(fields_unnamed.unnamed.iter().filter_map(|field| {
|
||||
// TODO(david): its a little wasteful to parse the attributes again here
|
||||
// TODO(david): it's a little wasteful to parse the attributes again here
|
||||
// ideally we should parse things once and pass the data down
|
||||
let FromRequestFieldAttrs { via } =
|
||||
parse_attrs("from_request", &field.attrs).ok()?;
|
||||
|
|
|
@ -198,7 +198,7 @@ impl BenchmarkBuilder {
|
|||
|
||||
eprintln!("Running {:?} benchmark", self.name);
|
||||
|
||||
// indent output from `rewrk` so its easier to read when running multiple benchmarks
|
||||
// indent output from `rewrk` so it's easier to read when running multiple benchmarks
|
||||
let mut child = cmd.spawn().unwrap();
|
||||
let stdout = child.stdout.take().unwrap();
|
||||
let stdout = std::io::BufReader::new(stdout);
|
||||
|
|
|
@ -16,7 +16,7 @@ axum is unique in that it doesn't have its own bespoke middleware system and
|
|||
instead integrates with [`tower`]. This means the ecosystem of [`tower`] and
|
||||
[`tower-http`] middleware all work with axum.
|
||||
|
||||
While its not necessary to fully understand tower to write or use middleware
|
||||
While it's not necessary to fully understand tower to write or use middleware
|
||||
with axum, having at least a basic understanding of tower's concepts is
|
||||
recommended. See [tower's guides][tower-guides] for a general introduction.
|
||||
Reading the documentation for [`tower::ServiceBuilder`] is also recommended.
|
||||
|
@ -31,7 +31,7 @@ axum allows you to add middleware just about anywhere
|
|||
|
||||
## Applying multiple middleware
|
||||
|
||||
Its recommended to use [`tower::ServiceBuilder`] to apply multiple middleware at
|
||||
It's recommended to use [`tower::ServiceBuilder`] to apply multiple middleware at
|
||||
once, instead of calling `layer` (or `route_layer`) repeatedly:
|
||||
|
||||
```rust
|
||||
|
@ -128,9 +128,9 @@ That is:
|
|||
|
||||
It's a little more complicated in practice because any middleware is free to
|
||||
return early and not call the next layer, for example if a request cannot be
|
||||
authorized, but its a useful mental model to have.
|
||||
authorized, but it's a useful mental model to have.
|
||||
|
||||
As previously mentioned its recommended to add multiple middleware using
|
||||
As previously mentioned it's recommended to add multiple middleware using
|
||||
`tower::ServiceBuilder`, however this impacts ordering:
|
||||
|
||||
```rust
|
||||
|
|
|
@ -499,7 +499,7 @@ async fn route_layer() {
|
|||
|
||||
// it would be nice if this would return `405 Method Not Allowed`
|
||||
// but that requires knowing more about which method route we're calling, which we
|
||||
// don't know currently since its just a generic `Service`
|
||||
// don't know currently since it's just a generic `Service`
|
||||
let res = client.post("/foo").await;
|
||||
assert_eq!(res.status(), StatusCode::UNAUTHORIZED);
|
||||
}
|
||||
|
|
|
@ -4,4 +4,4 @@ This folder contains numerous examples showing how to use axum. Each example is
|
|||
setup as its own crate so its dependencies are clear.
|
||||
|
||||
For a list of what the community built with axum, please see the list
|
||||
[here](../ECOSYSTEM.md).
|
||||
[here](../ECOSYSTEM.md).
|
||||
|
|
|
@ -73,7 +73,7 @@ async fn main() {
|
|||
// `TokioIo` converts between them.
|
||||
let stream = TokioIo::new(tls_stream);
|
||||
|
||||
// Hyper has also its own `Service` trait and doesn't use tower. We can use
|
||||
// Hyper also has its own `Service` trait and doesn't use tower. We can use
|
||||
// `hyper::service::service_fn` to create a hyper `Service` that calls our app through
|
||||
// `tower::Service::call`.
|
||||
let hyper_service = hyper::service::service_fn(move |request: Request<Incoming>| {
|
||||
|
|
|
@ -68,7 +68,7 @@ async fn main() {
|
|||
// `TokioIo` converts between them.
|
||||
let stream = TokioIo::new(stream);
|
||||
|
||||
// Hyper has also its own `Service` trait and doesn't use tower. We can use
|
||||
// Hyper also has its own `Service` trait and doesn't use tower. We can use
|
||||
// `hyper::service::service_fn` to create a hyper `Service` that calls our app through
|
||||
// `tower::Service::call`.
|
||||
let hyper_service = hyper::service::service_fn(move |request: Request<Incoming>| {
|
||||
|
|
|
@ -6,7 +6,7 @@
|
|||
//!
|
||||
//! This example shows how to run axum using hyper's low level API.
|
||||
//!
|
||||
//! The [hyper-util] crate exists to provide high level utilities but its still in early stages of
|
||||
//! The [hyper-util] crate exists to provide high level utilities but it's still in early stages of
|
||||
//! development.
|
||||
//!
|
||||
//! [hyper-util]: https://crates.io/crates/hyper-util
|
||||
|
|
Loading…
Reference in a new issue