Andrei Nesterov

I've just got a thought that we may not need a CORS config. Attributes look like a better option. The code is cleaner, we don't need to implement OPTIONS handler,...

A middleware config is setting up CORS on an application level and attributes – on resource / method level probably the best option.

We've hit the same problem. > attempted to run an executor while another executor is already running

Hi @carllerche, I have a token-based authentication implemented as Extractor. I'd like to return a meaningful error status code – "401 Unauthorized" if there is [a broken token](https://github.com/netology-group/storage/blob/master/src/app/authn.rs#L48). In order...

Ok, I'll come back with it soon.

I've introduced `error::Error::status_code` function in order to simplify default catch handler and use error descriptions from **http** crate. With this change it looks as there is no need in `error:Error::is{bad_request,not_found,internal}`...

I've started working on handling errors in my resource handler. For the following example, I've expected to see an **403 - Forbidden**, but got **500 - Internal Error**. ```rust use...

We definitely can do something like that, but it doesn't look idiomatic: we can't return the errors using `?` operator, and we duplicate logic of `error::Error`. ```rust #[derive(Response)] #[web(status =...

@carllerche Could you please take a look? We probably could merge the current PR that aims handling errors in extractors If you are good with the changes. Then, I may...

@carllerche I've updated the PR, tests have already completed. As for your example, it fails to compile. ```rust fn read(&self) -> Result, tower_web::Error>: tower_web::response::Response` is not satisfied --> src/app/mod.rs:59:1 |...