users@jax-rs-spec.java.net

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

From: Marek Potociar <marek.potociar_at_oracle.com>
Date: Fri, 16 Dec 2011 14:08:49 +0100

On 12/16/2011 12:46 PM, Sergey Beryozkin wrote:
> 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;
>

Yes, that's what I was thinking too.

> 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...

Me neither. It's still good to keep these potential future use cases in mind.

Marek

> 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
>>>
>>>