Nicolas,
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).
Yes, you're right, the outcome tells us that a matching occurred so it is a kind of weird to not invoke post matching request filter...
Wel, to tell you the truth I'm not really comfortable with this default implementation concept. I think that no default implementation should be provided when there is no user defined java method to handle OPTION requests.
This behavior has been around for a very long time. Things can be changed, but backward compatibility is always an issue.
I say that because most of the time OPTIONS requests are used for CORS requests.
My initial question was precisely in the “context” of CORS and pre-flight requests. So as stated in the spec, with only "the metadata provided by the JAX-RS annotations on the matching class and its methods" how can the JAX-RS implementation decide if request coming from origin X is allowed or not ?
To my opinion, it can't since there is no
native JAX-RS annotations dealing with hosting\domain.
Obviously JAX-RS does not provide CORS support now. But JAX-RS extensions have been created, some may require developers to _override_ OPTIONS to avoid getting the default behavior and use post-matching filters to implement the CORS logic (for simple and not simple requests). That was the “context” that I mentioned before. So what are we expecting as default behavior ? - If default generated response does not contain header "Access-Control-Allow-Origin" it is an error
- If
default generated response contains
header "Access-Control-Allow-Origin" set to "*" it is a security problem. From a security point of view allow every-thing is not an acceptable default behavior. Default behavior should be the most restrictive one.
- if default
generated response contains
header "Access-Control-Allow-Origin" set to the value of "origin" header it is a security problem.
From a security point of view allow what has been asked is not an acceptable default behavior. Default behavior should be the most restrictive one.
So my point is that relying only on "the metadata provided by the JAX-RS annotations on the matching class and its methods" is not enough to get an acceptable default behavior, we need another user provided metadata: the allowed origin.
The additional metadata is typically provided in the form of a CORS annotation. Yes, we don’t have that now, but it’s a bit beyond the scope of my initial question —good for some other discussion. So since there is no such JAX-RS ANNOTATION to provide such metadata, I would suggest to remove this default implementation concept from the spec and then let each JAX-RS vendors provide support for this feature if they want.
WDYT ?
If we define precisely how a filter works with the default OPTIONS and what ResourceInfo returns, CORS can be implemented in filters and there’s no need to change the current JAX-RS behavior (at least is not required, even if it may be desirable). That is, a filter can intercept pre-flight requests and respond to them before the resource method is called —with the issue of CORS meta-data being completely orthogonal, it could be an annotation, config files etc.
— Santiago
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.
>> 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@xxxxxxxxxxxTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jaxrs-dev
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
|
