On 2011-12-16 11: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.
>
>>
>> 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,
-> RFC 6454