Hi Sekhar,
I can imagine that default OPTIONS handlers are implicitly defined for all
@Path, and that maybe a perfectly reasonable behavior.
But, it is unfortunate that I have to maintain OPTIONS for all Path of
other methods.
In any case, it be better documented. Does anyone know the expected
behavior?
I can update the wiki if somebody can point me to the right answer and the
location in the wiki..
Thanks,
Go
On Thu, Dec 1, 2011 at 12:10 PM, Sekhar Vajjhala <sekharv01_at_gmail.com>wrote:
> That doesn't look right to me. I would have expected the default handler
> to apply only if no method is explicitly designated with HEAD (or OPTIONS).
>
> My reading of the spec (included below) confirms this. So, what you are
> seeing looks like a bug to me.
> As an aside, the default rule for HEAD is clear but not for OPTIONS (i.e.
> bullet item 2 "Generate an automatic ...." is hard to decipher).
>
> --------- From JAX-RS spec Nov 1, 2011 , section 3.3.5 "HEAD and OPTIONS"
> ---------
>
> HEAD and OPTIONS requests receive additional automated support. On receipt
> of a HEAD request an implementation MUST either:
> 1. Call a method annotated with a request method designator for HEAD
> or, if none present,
> 2. Call a method annotated with a request method designator for GET
> and discard any returned entity.
> Note that option 2 may result in reduced performance where entity creation
> is significant.
> On receipt of an OPTIONS request an implementation MUST either:
> 1. Call a method annotated with a request method designator for
> OPTIONS or, if none present,
> 2. Generate an automatic response using the metadata provided by the
> JAX-RS annotations on the matching class and its methods.
>
> ----------- End excerpt from JAX-RS spec --------
>
> Sekhar Vajjhala
>
>
> On Tue, Nov 29, 2011 at 1:51 PM, Go Hori <go_at_livemocha.com> wrote:
>
>> Hello Jersey experts.
>>
>> I have yet another problem I have encounter for which I hope there is a
>> better solution than I came up with.
>>
>> Jersey handles OPTIONS and HEAD requests automatically unless a method
>> is implicitly implemented.
>> I found out that I need to implement OPTIONS method for all methods I
>> have unique @Path.
>>
>> It's easier with an example. Let's say I have two methods like the
>> followings to begin with.
>>
>> @GET
>> @Path("foo")
>> public Response foo() {
>> }
>> @GET
>> @Path("{path: .*}")
>> public Response all() {
>> }
>>
>> Then, I want to handle OPTIONS request for any path, so I add something
>> like this hoping OPTIONS /anything will go to this method.
>> @OPTIONS
>> @Path("{path: .*}")
>> public Response allOptions() {
>> }
>>
>> But, it doesn't. A request to OPTIONS /bar will go to the method, but
>> OPTIONS /foo won't because Jersey will find default Options handler for a
>> path "foo".
>> This makes sense. "foo" is a better match, and Jersey is finding a
>> default Options handler for "foo" path.
>>
>> So, then I have to have this in order for me to handle the request.
>> @OPTIONS
>> @Path("foo")
>> public Response fooOptions() {
>> }
>>
>> Now, my question is, "is there a better way to do this other than to have
>> corresponding OPTIONS handler for all the @Path I am handling in a
>> resource?".
>> It seems like there is ought to be a better way that I don't know of.
>>
>> Thanks in advance,
>> Go
>>
>>
>