* Add a dedicated error message for state type inference issues
* Generate valid code even if state type can't be inferred
* Also error on state type inference for debug_handler
* Move RequestExt and RequestPartsExt into axum-core
* Add RequestExt::into_limited_body
… and use it for Bytes extraction.
* Add RequestExt::with_limited_body
… and use it for Multipart extraction.
Co-authored-by: David Pedersen <david.pdrsn@gmail.com>
* add server feature and make tokio and hyper/server and tcp optional
* address review comments
* don't mention any specific runtimes in the example
* sort deps
* add `tokio` feature when adding `ws`
* don't always pull in tower feature that pulls in tokio io stuff
* remove usage of `tokio_cr`
* changelog
* depend on tokio version that supports wasm
* don't make it sound like tokio doesn't support wasm
* call out new default feature
Co-authored-by: Fisher Darling <fdarlingco@gmail.com>
Co-authored-by: David Pedersen <david.pdrsn@gmail.com>
* Rename Fallback::Custom to Fallback::Service
* Allow Routers to inherit state
* Rename Router::{nest => nest_service} and add new nest method for Routers
* Fix lints
* Add basic tests for state inheritance
* Changelog
* Support `State` with `#[derive(FromRequest[Parts])]`
Fixes https://github.com/tokio-rs/axum/issues/1314
This makes it possible to extract things via `State` in
`#[derive(FromRequet)]`:
```rust
struct Foo {
state: State<AppState>,
}
```
The state can also be inferred in a lot of cases so you only need to
write:
```rust
struct Foo {
// since we're using `State<AppState>` we know the state has to be
// `AppState`
state: State<AppState>,
}
```
Same for
```rust
struct Foo {
#[from_request(via(State))]
state: AppState,
}
```
And
```rust
struct AppState {}
```
I think I've covered all the edge cases but there are (unsurprisingly) a
few.
* make sure things can be combined with other extractors
* main functions in ui tests don't need to be async
* Add test for multiple identicaly state types
* Add failing test for multiple states
* Use `400 Bad Request` for `FailedToDeserializeQueryString` rejections
Fixes https://github.com/tokio-rs/axum/issues/1378
From [the spec] about `422 Unprocessable Entity`:
> For example, this error condition may occur if an XML request body
> contains well-formed (i.e., syntactically correct), but semantically
> erroneous, XML instructions.
I understand this to mean that query params shouldn't use 422 because
that is about the request body.
So this changes `FailedToDeserializeQueryString` from `422 Unprocessable
Entity` to `400 Bad Request`.
[the spec]: https://datatracker.ietf.org/doc/html/rfc4918#section-11.2
* changelog
Previously, it was difficult to find out the path in the deep JSON tree at
which a deserialization error occurred. This patch makes an error message
to contain the errored path. In order to find out the path,
I added serde_path_to_error, a new optional dependency.
Co-authored-by: Lee Dogeon <dev.moreal@gmail.com>
Co-authored-by: Lee Dogeon <dev.moreal@gmail.com>
* Refactor proc-macro attribute parsing
* Remove `#[allow(warnings)]` which was accidentally committed
* Change span for "cannot use `rejection` without `via`" error for enums
* fix test
