It would also come in handy for set_pre_routing_handler. I only know the req.path and would have to write something myself to find out which route matched while the internals of the library (probably) just know which route matched.

I assume you mean post-routing handler?

I second the request to store the route pattern in the matcher – a prerequisite to making this work. But please don't add another std::string to the Request object. const char * works and saves ~24 bytes (depending on the std::string implementation).

Alright, it's easy enough to implement, and I know I'll need it for removable endpoints in the WebSockets code.

So here it is: #2104

Thanks! This will solve me some headaches.
Btw, is Websocket support in the roadmap?

Alright, it's easy enough to implement, and I know I'll need it for removable endpoints in the WebSockets code.

So here it is: #2104

Thanks!

And no, I meant pre-routing, since I want to check required permissions for routes, it'd be too late for that in the post-routing handler

And no, I meant pre-routing, since I want to check required permissions for routes, it'd be too late for that in the post-routing handler

You can still reject requests in post-routing; handlers are invoked after. In pre-routing, we don't know which handler we're going to invoke … because that's decided during routing.

Thanks! This will solve me some headaches. Btw, is Websocket support in the roadmap?

@zon7 Not officially. I have a (nearly) fully working and compliant implementation of the client and server (the SSL client is the last to-do item, and it's very minor).

There are a few PRs that need to be merged first; after that, I hope to convince @yhirose to host (but not maintain) the WebSocket implementation in this repo. I'll ping you when it's time, and you can add your support if you're interested. :-)

And no, I meant pre-routing, since I want to check required permissions for routes, it'd be too late for that in the post-routing handler

You can still reject requests in post-routing; handlers are invoked after. In pre-routing, we don't know which handler we're going to invoke … because that's decided during routing.

Ah, ok then. It's post-routing and not post-request after all so it makes sense. The example in README.md returns from the pre-routing handler but doesn't return anything from the post-routing handler so I assumed that's called after the routing AND request are done

And no, I meant pre-routing, since I want to check required permissions for routes, it'd be too late for that in the post-routing handler

You can still reject requests in post-routing; handlers are invoked after. In pre-routing, we don't know which handler we're going to invoke … because that's decided during routing.

Ah, ok then. It's post-routing and not post-request after all so it makes sense. The example in README.md returns from the pre-routing handler but doesn't return anything from the post-routing handler so I assumed that's called after the routing AND request are done

Nope, sorry, I made a mistake. This needs some more thought to fully address your scenario. @yhirose What use case did you have in mind for the post-routing handler? Why is that not invoked before the handlers?

Edit: Would this make sense? (in Server::dispatch_request())

    if (matcher->match(req)) {
      req.matched_route = matcher->pattern().c_str();
      if(pre_handler_ && pre_handler_(req, res) == HandlerResponse::Handled)
        return true;
      handler(req, res);
      return true;
    }

Edit: Would this make sense? (in Server::dispatch_request())

if (matcher->match(req)) {
  req.matched_route = matcher->pattern().c_str();
  if(pre_handler_ && pre_handler_(req, res) == HandlerResponse::Handled)
    return true;
  handler(req, res);
  return true;
}

I hope this questions wasn't addressed to me because I don't know :)

While having the matched_route in the pre-routing handler (or as you suggested in the post-routing handler) would be the ideal solution for me (and probably others) I could also live with it being only available in the handlers. I'm calling a function at the start of every handler anyway, so I could check for permissions in there

Edit: Would this make sense? (in Server::dispatch_request())

if (matcher->match(req)) {
  req.matched_route = matcher->pattern().c_str();
  if(pre_handler_ && pre_handler_(req, res) == HandlerResponse::Handled)
    return true;
  handler(req, res);
  return true;
}

I hope this questions wasn't addressed to me because I don't know :)

I was partly thinking out loud and partly asking @yhirose. :-)

While having the matched_route in the pre-routing handler (or as you suggested in the post-routing handler) would be the ideal solution for me (and probably others) I could also live with it being only available in the handlers. I'm calling a function at the start of every handler anyway, so I could check for permissions in there

I'm thinking about adding set_pre_request_handler(). The pre-request handler would run immediately before the main handler and can return a HandlerResponse to control whether we call the main handler at all. I'm open to alternative names, but pre-request handler makes sense to me. (Grok guessed correctly that the post-routing handler runs after the main handler, so I'm clearly out of my element concerning HTTP library APIs. ;-))

@betsch85 sorry that I wasn't able to reply sooner... Could you please explain a bit more about req.matched_route and why req.path in the pre routing handler isn't sufficient? Thanks!

@betsch85 sorry that I wasn't able to reply sooner... Could you please explain a bit more about req.matched_route and why req.path in the pre routing handler isn't sufficient? Thanks!

Becuase I want to know which route matched, not what the user typed in the browser

If I have a route, lets say "/whatever/:action/with/:id", I want to be able to specify somewhere that for this specific route (not path) , a user needs the "whatever_with"-permission, and for that I would need req.matched_route (which would be "/whatever/:action/with/:id"). req.path would just contain what the user actually sent to the server, e.g. /whatever/list/with/5.

I'd have to split the path and check the route myself which makes everything unnecessarily more complicated, especially if a static route and a route with a parameter overlap, e.g. /whatever/:action/with/:id and /whatever/try/with/0

In the pre-routing handler I'd like to do:

if (user_permissions.contains(needed_permissions[req.matched_route]) {
    return httplib::Server::HandlerResponse::Unhandled;
} else {
    res.status = 401;
    return httplib::Server::HandlerResponse::Handled;
}

instead of:

auto matched_route = find_out_what_the_route_probably_was(req.path);
if (user_permissions.contains(needed_permissions[matched_route]) {
    return httplib::Server::HandlerResponse::Unhandled;
} else {
    res.status = 401;
    return httplib::Server::HandlerResponse::Handled;
}

I hope that makes sense