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,
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.
Marek
>
> Sergey