users@jax-rs-spec.java.net

[jax-rs-spec users] [jsr339-experts] Re: Allow header in (Request)HttpHeaders

From: Sergey Beryozkin <sberyozkin_at_talend.com>
Date: Fri, 16 Dec 2011 14:05:11 +0000

Hi,
On 16/12/11 13:55, Bill Burke wrote:
>
>
> On 12/16/11 5:52 AM, 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,o
>> 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.
>>
>
> It seems to me that Allow would be rarely (99% never) be used by either
> the client or server(prolly never on the server as JAX-RS will
> automatically do this for you).

Allow is supposed to be included in the response to OPTIONS

Sergey

> So I'd say either remove it entirely
> from the API, or be fair to the other HTTP headers that you've
> selectively omitted.
>
>