Rejecting with warp::reply::not_found results in a 405 Method Not Allowed error

[Geal]

Hello,
with the following code, I would get a 405 error while I expect a 404:

fn main() {
  let routes = warp::post2().map(warp::reply).or(warp::get2().and(warp::path("test").and_then(send_test)));
  warp::serve(routes).run(([127, 0, 0, 1], 3000));
}

fn send_test() -> Result<String, warp::Rejection> {
  Err(warp::reject::not_found())
}

Is there something I am doing wrong?

[seanmonstar]

No, you aren't wrong in thinking that. Currently, the rejections in warp collect and the highest priority one is chosen to render as a response. It's assumed that Not Found is the lowest priority, so the method rejection from the post plus the not found rejection you create means the 405 is shown.

The priority of these could maybe need adjustment.

[Geal]

maybe there could be a way to cut backtracking? ie, if we know we got to a specific prefix or argument, we're in the right route, and should return the error from this route

[blm768]

In principle, if you want a particular error to override all others, you can return an Ok(http::Response) with that error code. Maybe not the most ergonomic way to do it, but it's accepting the mapping of route to resource and then rejecting the request, so it kind of makes sense in an abstract way.
Alternatively, in this case, you could probably move the get2() farther down the chain.

[algermissen]

Can you explain how I could return such a response from a header filter? I think that is not possible right now if I am not mistaken?

[seanmonstar]

Can you explain how I could return such a response from a header filter?

You could make use of Filter::recover to alter the rejection, or Filter::or_else can be useful to provide a "default" value overriding any rejection.

[mexus]

My vote is for some way to cut the backtracking. Currently I'm using the approach proposed by @blm768 , but as he mentioned it's not quite ergonomic.
IMHO any reject provided by a user's code should by default stop the processing and just return the rejection, and probably it's not a too bad idea to have a special reject like reject::try_something_different() (bad naming, but I hope you'll get the point) that should be returned by the combinators to go for furthers ors.

There's an example to customize errors as described by @blm768 for anyone interested: examples/errors.rs

[algermissen]

What do other's think about the need for context-specific rejection payload? I still see no way to do that with the rejection design as-is. Or I am missing something.

My use case is 401 Unauthorized, where it is usually only known in that specific route, what exactly to return as Challenge parameters. Another use case would be HTTP Problems (https://tools.ietf.org/html/rfc7807).

Thoughts?

[boustrophedon]

+1 for this behavior being unexpected.

As an example, in the todos example when you build the filters which all contain paths under /todos:

warp/examples/todos.rs

Line 93 in f334f51

let api = list.or(create).or(update).or(delete);

if you add the lines

let req = warp::test::request().path("/");
assert_eq!(req.reply(&api).status(), 404);

the assertion fails with 405 even though you'd expect to get a 404 since we have no routes on /

The workaround is as you mentioned above, you can add an .or_else(|_| Err(warp::reject::not_found())); to the end of the filter and the assertion will pass. However, now you don't get proper 405 errors when doing get requests on post-only paths.

I don't know what the best way to solve this in general is though.

[Timmmm]

Presumably there should be:

• warp::reject::unmatched() - this filter didn't match but it could be valid for a different filter.
• warp::reject::not_found() - the request was definitely intended for this filter but the requested resource was not found.