On 12/16/2011 12:00 PM, Sergey Beryozkin wrote:
> On 16/12/11 10:52, Marek Potociar wrote:
>>
>>
>> On Fri 16 Dec 2011 11:17:40 AM CET, Sergey Beryozkin wrote:
>>>>>>> by the way, getAllowMethods() - is is supposed to be on the ResponseHeaders instead ?
>>>>>>
>>>>>> As an expert homework, kindly search through the HTTP spec or browse through this EG mailing list archive to find the
>>>>>> answer and come back with it ;)
>>>>>
>>>>> Yes I checked. Are you using this "MAY" bit: "The Allow header field MAY be provided with a PUT request to recommend
>>>>> the methods to be supported by the new or modified resource.". Does it deserve a dedicated method ? What is your
>>>>> target audience ? What do you expect the JAX-RS server implementation do ? We have 4 major HTTP verbs, that MAY thing
>>>>> talks about 1 verb, see what I mean ?
>>>>
>>>> No I don't. Do you want me to remove the method, because the HTTP spec does say the Allow is a mandatory request
>>>> header?
>>>> Allow is a general-purpose header. It surely is more frequent in the response, but if we have it in the response, we
>>>> should also have it on the request, as it is a general-purpose header.
>>>>
>>>
>>> My reading of
>>>
>>> http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-17#section-9.1
>>>
>>> tells me that it's supposed to be used by the server to advertise the methods a given resource supports;
>>
>> My reading is that the header is used to "list the set of methods
>> advertised as supported by the target resource". This does not say that
>> it is only supposed to be used by the server. When you create a new
>> resource via PUT, you can use the header field to specify the set of
>> methods that should be allowed for the resource being created.
>>
>
> Possibly; but I don't understand how in JAX-RS where methods are supported via annotations this requirement/wish can be
> supported
Perhaps via filters or a "router" resource method annotated with all HTTP annotations. But this raises a good point- do
we want to provide an easier support for this type of routing resource methods that are supposed to be invoked for ANY
request method? If yes, do you, or anyone else in this group, see a good way how to expose such router method? The
problem to solve is that the method should respond to ANY method, including all possibly unknown methods.
Marek
>
>
>>>
>>> Please keep it in - if you know why promoting it at the request interface level can help JAX-RS developers; all other
>>> 'promoted' headers can be useful (Accept, Content-Type, Content-Length, Accept-Language).
>>> I'd rather consider adding an Origin or Range helpers
>>
>> Feel free to file an enhancement in Jira. As with other convenience
>> method, we should conider them. Origin might be very useful, once it's
>> standardized, even though I think we should be addressing CORS in bulk,
>> not just pick out some of the headers. Similarly, in case of Range we
>> might want to consider addressing support of partial requests as a
>> whole, not just exposing a single header getter.
>
> OK
>
>>
>> Marek
>>
>>>
>>> Sergey
>
>