4 ms·

> This one is annoying, but easily solvable by making your own return type that implements IntoResponse You can just call `.into_response()` like documented he

> This one is annoying, but easily solvable by making your own return type that implements IntoResponse You can just call `.into_response()` like documented here https://docs.rs/axum/latest/axum/response/index.html#returning-different-response-types https://docs.rs/axum/latest/axum/response/index.html#returni... > I'm not sure what you're talking about? You just add `Cookies` extractor to your handler and use that. You don't need to add it to the return, middleware takes care of it. I think you're thinking of tower-cookies which works the same way poem's CookieJarManager does. axum-extra's cookies work differently in that you have to return the updated jar from handlers. We chose this design because it composes better when you have multiple libraries that all wanna set cookies. tower-cookies doesn't work if you accidentally add multiple cookie middleware, whereas axum-extra's approach does. So its a trade-off.

0x457 4y ago
> I think you're thinking of tower-cookies which works the same way poem's CookieJarManager does. Yes, that's what I'm using. > You can just call `.into_response()` like documented here https://docs.rs/axum/latest/axum/response/index.html#returni https://docs.rs/axum/latest/axum/response/index.html#returni... Oh yeah, totally forgot about that one.
rendaw 4y ago
I was trying to return `Response` directly, which reading the above one would assume is the end-all be-all of `IntoResponse`. But `Response` is generic and you need to harmonize Body types across branches, etc... Anyways implementing a custom `IntoResponse` shouldn't be necessary in the first 30m of using a framework (not saying I didn't just miss something, but I've read the docs multiple times).
- davidpdrsn 4y ago
  Use https://docs.rs/axum/latest/axum/response/type.Response.html https://docs.rs/axum/latest/axum/response/type.Response.html This is also whats shown in the "Implementing IntoResponse" examples https://docs.rs/axum/latest/axum/response/trait.IntoResponse.html#implementing-intoresponse https://docs.rs/axum/latest/axum/response/trait.IntoResponse...
  - rendaw 4y ago
    Ah thanks! So `axum::response::Response` which is `http::Response<UnsyncBoxBody<Bytes, Error>>` is the fallback/catch-all response type, basically. I actually read that, but I didn't realize that it was a specific type and my IDE auto-probably imported the wrong one. There's a lot of types named `Response` and with how common re-exports are I probably wouldn't have noticed unless I was expecting it. And since they're all part of the same type tree you aren't going to get clear error messages from the compiler either. Naming it something like `DefaultResponse` or `AxumResponse` or calling it out explicitly by changing > Use Response for more low level control: to > The above all eventually gets turned into axum::response::Response (a specialization of `http::Response`), which you can instantiate directly for more low level control: would help immensely. Edit: No, reading more closely `Response` has a default body of `UnsyncBoxBody<Bytes, Error>` but other than that it's still generic and identical to `http::Response`? That's not going to help if you're having generic issues unless you explicitly convert things to `Bytes` AFAICT, and a default parameter is hardly obvious documentation.
    - 0x457 4y ago
      axum's Response is an alias for `http::Response<UnsyncBoxBody<Bytes, Error>>`. It's not a fallback or catch-all, it's the type that axum expects to be returned by handler directly or indirectly via `IntoResponse` trait. All of that is very clear if you open : https://docs.rs/axum/latest/axum/index.html https://docs.rs/axum/latest/axum/index.html Look at `IntoResponse` trait, you will see that it's the type you need to return. The difference between `impl IntoResponse`, Some type that implements `IntoResponse` and `http::Response<UnsyncBoxBody<Bytes, Error>>` is where conversion happens: explicitly by your handler or by axum implicitly. You don't have to "explicitly convert to Bytes", you call `into_response` on whatever implements it.

0x457 4y ago

> I think you're thinking of tower-cookies which works the same way poem's CookieJarManager does. Yes, that's what I'm using. > You can just call `.into_response()` like documented here https://docs.rs/axum/latest/axum/response/index.html#returni https://docs.rs/axum/latest/axum/response/index.html#returni... Oh yeah, totally forgot about that one.

rendaw 4y ago

I was trying to return `Response` directly, which reading the above one would assume is the end-all be-all of `IntoResponse`. But `Response` is generic and you need to harmonize Body types across branches, etc... Anyways implementing a custom `IntoResponse` shouldn't be necessary in the first 30m of using a framework (not saying I didn't just miss something, but I've read the docs multiple times).

davidpdrsn 4y ago
Use https://docs.rs/axum/latest/axum/response/type.Response.html https://docs.rs/axum/latest/axum/response/type.Response.html This is also whats shown in the "Implementing IntoResponse" examples https://docs.rs/axum/latest/axum/response/trait.IntoResponse.html#implementing-intoresponse https://docs.rs/axum/latest/axum/response/trait.IntoResponse...
- rendaw 4y ago
  Ah thanks! So `axum::response::Response` which is `http::Response<UnsyncBoxBody<Bytes, Error>>` is the fallback/catch-all response type, basically. I actually read that, but I didn't realize that it was a specific type and my IDE auto-probably imported the wrong one. There's a lot of types named `Response` and with how common re-exports are I probably wouldn't have noticed unless I was expecting it. And since they're all part of the same type tree you aren't going to get clear error messages from the compiler either. Naming it something like `DefaultResponse` or `AxumResponse` or calling it out explicitly by changing > Use Response for more low level control: to > The above all eventually gets turned into axum::response::Response (a specialization of `http::Response`), which you can instantiate directly for more low level control: would help immensely. Edit: No, reading more closely `Response` has a default body of `UnsyncBoxBody<Bytes, Error>` but other than that it's still generic and identical to `http::Response`? That's not going to help if you're having generic issues unless you explicitly convert things to `Bytes` AFAICT, and a default parameter is hardly obvious documentation.
  - 0x457 4y ago
    axum's Response is an alias for `http::Response<UnsyncBoxBody<Bytes, Error>>`. It's not a fallback or catch-all, it's the type that axum expects to be returned by handler directly or indirectly via `IntoResponse` trait. All of that is very clear if you open : https://docs.rs/axum/latest/axum/index.html https://docs.rs/axum/latest/axum/index.html Look at `IntoResponse` trait, you will see that it's the type you need to return. The difference between `impl IntoResponse`, Some type that implements `IntoResponse` and `http::Response<UnsyncBoxBody<Bytes, Error>>` is where conversion happens: explicitly by your handler or by axum implicitly. You don't have to "explicitly convert to Bytes", you call `into_response` on whatever implements it.