On 16/12/11 11:35, Marek Potociar wrote:
>
>
> 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.
>
I think only filters may be able to do in the short term it by
overwriting the request HTTP method with the value known to be supported
by a given resource;
We could've added @All or similar annotation - but the question is then
how @All handler will choose the next handler without having the support
from the runtime's selection algorithm; may be it would do:
@All
public void router(@Context Request req)
{
// check headers, uri, etc, set http method to post/etc
req.next();
}
but I'm not sure we'd like to go there in 2.0...
Sergey
>
> 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
>>
>>