Re: [jaxrs-dev] OPTIONS and ResourceInfo

[Santiago Pericas-Geertsen <santiago.pericasgeertsen@xxxxxxxxxx>]

On Apr 22, 2020, at 3:17 PM, NESMON Nicolas <nicolas.nesmon@xxxxxxxxx> wrote:

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...

 Hmmm, that would not be consistent with the outcome. There’s indeed a matching and a method, it is just not a user-provided one (more precisely, the matching algorithm in Section 3.7.2 is not exiting via a 404 clause; OPTIONS is covered in 3a). 

 In fact, an implementation could actually generate byte code for such a method as a way to support this. Moreover, it would be inconsistent with `ResourceInfo#getResoureClass` returning something —in your earlier response. 

 Not running filters could lead to all sorts of problems (authn/authz, etc). Clearly we need to expand on the default support for OPTIONS given that it is unlikely that two implementations are doing the same thing here.

— Santiago

(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.

Le mer. 22 avr. 2020 à 13:45, Markus KARG <markus@xxxxxxxxxxxxxxx> a écrit :

>> 1. The same as if the method would have been GET instead of OPTIONS.
> These are different as there is not necessarily an instance of Method to return for OPTIONS.

(a) If there is an @OPTIONS method, the answer is clear. ;-)
(b) If there is a @GET method, it is this one (just like the case with HEAD)
(c) If there is none of them, I would expect null.

-Markus

_______________________________________________
jaxrs-dev mailing list
jaxrs-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jaxrs-dev

--

Nicolas NESMON

_______________________________________________
jaxrs-dev mailing list
jaxrs-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jaxrs-dev