In general, only the first register resource for any given path will be accepted, even if the resources would match differently.
The intent in this specific case is to have the second handler as a fallback that deals with anything not otherwise handled (e.g. return a 401 if not logged in or 404 otherwise). At the same time, there is still a need to handle the root URL which incidentally uses the same resource string.
I know it's possible to handle this outside the libhttpserver, but then what's the point in having register_resource at all?
Steps to Reproduce
Build a server with the above code.
Expected behavior: [What you expect to happen]
Family and non-family resources with the same path should not conflict.
Actual behavior: [What actually happens]
Regardless of family/non-family, resources with the same path conflict.
Reproduces how often: [What percentage of the time does it reproduce?]
Prerequisites
Description
The following code will fail
In general, only the first register resource for any given path will be accepted, even if the resources would match differently.
The intent in this specific case is to have the second handler as a fallback that deals with anything not otherwise handled (e.g. return a 401 if not logged in or 404 otherwise). At the same time, there is still a need to handle the root URL which incidentally uses the same resource string.
I know it's possible to handle this outside the libhttpserver, but then what's the point in having
register_resource
at all?Steps to Reproduce
Build a server with the above code.
Expected behavior: [What you expect to happen]
Family and non-family resources with the same path should not conflict.
Actual behavior: [What actually happens]
Regardless of family/non-family, resources with the same path conflict.
Reproduces how often: [What percentage of the time does it reproduce?]
100%
Versions