Skipping request filters does not seem like the better option in this case.
Well we agree that pre matching request filters should not be skipped.
But, after reading the ContainerRequestFilter doc, I think that skipping post matching request filters could make sense.
This doc says that this type of filter should be invoked only after the request has been matched to a particular resource. So we could consider that since there is no OPTION java method in the resource class, there is no matching...
(c) If there is none of them, I would expect null.
Yep and in this case I also expect a 404 to be returned and no invocation of any
post matching request filters.
(b) If there is a @GET method, it is this one (just like the case with HEAD)
Yep, why not. Stricty speaking, it is not the method that will be invoked but it is the resource method that is the target of the request.
So, it would introduce a special case of matching for OPTION requests in case there is no explicit java method to handle it. It would be based on request path, request method and request headers (
"Access-Control-Request-Method"):
- for an OPTION request with header "Access-Control-Request-Method" set to "GET", the matching resource method is the java method annotated with @GET if any
- for an OPTION request with header
"Access-Control-Request-Method" set to "POST", the matching resource method is the java method annotated with @POST if any
- and so on
Globaly the ResourcerInfo doc says that this class allows to access the resource class and resource method matched by the current request. So I think the key here is to clarify/detail the "matching" process when dealing with OPTION resource without java method. This point is not really detailled in the spec for now.
