Hi Bill,
On 17/05/13 14:35, Sergey Beryozkin wrote:
> On 17/05/13 13:59, Bill Burke wrote:
>>
>>
>> On 5/17/2013 4:35 AM, Sergey Beryozkin wrote:
>>> Hi Bill
>>> On 17/05/13 04:41, Bill Burke wrote:
>>>> Let me give you an example:
>>>>
>>>> Given this request:
>>>>
>>>> OPTIONS /sub
>>>>
>>>> This will match:
>>>>
>>>> @Path("/")
>>>> class Resource {
>>>>
>>>> @Path("{id}")
>>>> public Locator locator() { return new Locator();}
>>>>
>>>> }
>>>>
>>>> class Locator {
>>>>
>>>> @OPTIONS
>>>> public String options() { return "OK"; }
>>>> }
>>>>
>>>> But this won't match:
>>>>
>>>> @Path("/")
>>>> class Resource {
>>>>
>>>> @GET
>>>> @Path("sub")
>>>> public String get() { return "OK"; }
>>>>
>>>> @Path("{id}")
>>>> public Locator locator() { return new Locator();}
>>>>
>>>> }
>>>>
>>> Seems to me it will too. @GET method is selected only if no @OPTIONS is
>>> available and in this case it is available.
>>>
>>
>> Check out the spec. It won't match because "sub" is matched in 2(h).
>> 2(h) says that if there are any non-locator matches, then go to 3, then
>> 3(a) will abort the request.
> But get() does not match OPTIONS, it will only match
>
> GET /sub
>
> and it will only match OPTIONS if no OPTIONS handler is available, but
> OPTIONS handler is available.
>
> Now we go to Locator and then we match OPTIONS. The only issue is that
> what happens if Locator has no OPTIONS too, I guess we have missed then
> the opportunity to match Resource.get because GET can be used to match
> OPTIONS if no OPTIONS exist. To be honest I do not see it as a big issue,
>
> I believe the spec says that if no OPTIONS handler is available then
> check GET, we have no GET on Locator so we should report all the verbs
> supported by it and its root Resource which is "GET", and it is cheaper
> than calling @GET method as a last resort as doing it may be expensive
>
Got confused here, this is a case of HEAD where GET may be called, did
you mean HEAD ? and if it is OPTIONS then Resource.get can not be
matched at all
Thanks, Sergey
>
> Cheers, Sergey
>
>>
>> I ran into this very problem when testing against the TCK. The TCK
>> assumes there is no loopback to Locators and one of the tests fails. I'm
>> able to fix this problem quite easily, but, I have some users that
>> reported this as a "bug". They will now "regress".
>>
>>
>
>