New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Middleware process_resource isn't called for sinks #1013
Comments
Hi @mcm, I can see how a sink might be considered a resource in the abstract, but in terms of implementation, the former is universal responder method, while the latter is a collection of responders wrapped in a class. Therefore, a given I can think of a couple of ways we might handle this, but before we get into that, could you elaborate on your particular use case? Do you need a reference to the sink callable, or do you have some logic that you only want to run when a resource or a sink matches the requested URL path? |
We now have three types of routes supported by the framework:
It may make sense after all to provide a way for middleware components to hook requests that end up matching any of the above, rather than only providing a way to intercept requests to resources. |
I was a bit suprised to see that process_resource is not called for sinks! |
Hi @Sylphe88! As a workaround for authentication middleware you might be able to leverage |
I changed how the route URI is formed so I can use resources instead of sinks, the result is cleaner. process_request() would have been the other way to go but then again existing middlewares (e.g. falcon-auth) mostly rely on process_resource() for better performance, so they won't be called for sinks |
This may be intentional, but I couldn't find anything in docs to confirm that other than some discussion on #691... even there, though, it wasn't necessarily clear that this behavior's intentional.
If we have a process_resource method on middleware, it's not called when a sink is matched, since
resource
isNone
inside ofapi.__call__
. Personally I would consider a sink to be a resource, but really I'm just looking for clarification about whether they should be (and in that case, is this behavior a bug) or should not be (and then maybe just a note added to the docs).The text was updated successfully, but these errors were encountered: