On 17/09/12 17:30, Bill Burke wrote:
> Santiago. I thought you were spot on in the comments. Either the user
> can use explicit @OPTIONS resource methods and/or write a response
> filter. We just need to make sure response filters are run in error
> conditions.
>
That introduces a possible inconsistency between the default runtime
processing and the custom one - in the latter all depends on the user
doing that interceptor - which is problematic on its own: the runtime
knows better what HTTP methods are supported by a given handler as
opposed to the user code.
Sergey
> On 9/17/2012 10:24 AM, Santiago Pericas-Geertsen wrote:
>>
>> On Sep 17, 2012, at 9:22 AM, Sergey Beryozkin wrote:
>>
>>> On 06/09/12 19:22, Santiago Pericas-Geertsen wrote:
>>>> Hello Experts,
>>>>
>>>> If you have an opinion on the matter, please chime in on this
>>>> discussion:
>>>>
>>>> http://java.net/jira/browse/JAX_RS_SPEC-21
>>>> <http://java.net/jira/browse/JAX_RS_SPEC-21http://java.net/jira/browse/JAX_RS_SPEC-21>
>>>>
>>>
>>> I agree with the original idea, think that the runtime should be
>>> responsible for making sure Allow is always in the response to OPTIONS
>>
>> The proposal in that issue was a bit more involved than that. But
>> let's assume we just do what you suggest. I.e., allow users to
>> implement @OPTIONS and then intercept the response to add Allow if not
>> there. I'm assuming we'd do that before running the response filter
>> chain.
>>
>> Is this sufficient for all cases? Is this really more intuitive than
>> writing a filter that updates the default response?
>>
>> -- Santiago
>>
>