On 5/17/2013 9:40 AM, Sergey Beryozkin wrote:
> 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
> \
Again, go walk through the algorithm in the spec. The spec algorithm
does not check which methods are available until step 3(a).
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com