cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Beryozkin" <sergey.beryoz...@iona.com>
Subject Re: JAX-RS Support: Error in the JAX-RS specs for matching method types?
Date Mon, 11 Feb 2008 16:39:09 GMT
Barry, is it a blocker issue for you ?

Cheers, Sergey

----- Original Message ----- 
From: "Sergey Beryozkin" <sergey.beryozkin@iona.com>
To: <cxf-dev@incubator.apache.org>
Sent: Monday, February 11, 2008 4:00 PM
Subject: Re: JAX-RS Support: Error in the JAX-RS specs for matching method types?


Hi Barry

I'm wondering is it really an error in the spec or is it something our implementation
should improve upon ?

>   2. Iterate through the accept header list. For each one:
>   1. Find all matching methods
>      2. If there is only one method return this and break out of the
>      accept header loop
>      3. If there are multiple methods sort these methods using
>      consume mime and produce mime. Then return the first.

Looks like this is actually how an algorithm should work anyway.
I'm looking at the spec (dated 3rd Oct 2007) and I can see this :

"At least one of the acceptable response entity body media types is a supported output format..."

Thats' really it, no specifics on how to do the match *between a given accept type's value
and a method's produce mime* is given. 
So, perhaps, the right way is indeed to start from the first Accept value and do sort and
everything and pick up the first matching 
method, if none matches, then go to the next Accept value, if any etc...

Looks like we need to have a new JIRA opened :-)

Thanks, Sergey







----- Original Message ----- 
From: "Barry Fitzgerald" <barfitzgerald@gmail.com>
To: <cxf-dev@incubator.apache.org>
Sent: Monday, February 11, 2008 3:19 PM
Subject: Re: JAX-RS Support: Error in the JAX-RS specs for matching method types?


> Hi Sergey,
>
> To confirm I don't think this is an error in our implementation - it is an
> error on the spec.
>
>>What happens if you send just "text/xml" for example, will you have getUser
> invoked ?
>
> Yes, the correct method will be invoked.
>
> The problem is the steps in the alogrithm. Simply choosing all possible
> methods and then sorting these according to their produce and consume Mimes
> will not work.
>
> A correct algorithm would:
>
>   1. Sort the Accept header according to the W3 standards
>   2. Iterate through the accept header list. For each one:
>   1. Find all matching methods
>      2. If there is only one method return this and break out of the
>      accept header loop
>      3. If there are multiple methods sort these methods using
>      consume mime and produce mime. Then return the first.
>
> Therefore when accept header of "text/xml, text/*, */*" is sent in. Methods
> matching "text/html" are first searched for then "text/*" then "*/*". I
> think this would solve the problem.
>
> This isn't some arbitrary obscure scenario.
>
> Looking at firefox's defaults it sends
> "text/xml,application/xml,application/xhtml+xml,text/html;q=0.9
> ,text/plain;q=0.8,image/png,*/*;q=0.5"
>
> Surely for a request from firefox I'd expect to get back one of the stated
> accepts not "application/widget" or "application/json"?
>
> Barry
>
>
>
>
>
>
>
> On Feb 11, 2008 2:55 PM, Sergey Beryozkin <sergey.beryozkin@iona.com> wrote:
>
>> Hi Barry
>>
>> You're sending Accept "text/xml,*/*",
>> and thus I believe a method annotated with application/json is also picked
>> up.
>>
>> I agree that perhpas in this case a text/xml needs to be invoked, but how
>> the algorithm needs to be changed ?
>>
>> */* matches both methods, thus both methods are picked up.
>> But what happens next ? If we just have to accept types as in your case,
>> then using text/xml as a key one could pick up the right method, but what if
>> we have "application/json, text/xml,*/*" ?
>>
>> What happens if you send just "text/xml" for example, will you have
>> getUser invoked ?
>>
>> Cheers, Sergey
>>
>>
>>
>> ----- Original Message -----
>> From: "Barry Fitzgerald" <barfitzgerald@gmail.com>
>> To: <cxf-dev@incubator.apache.org>
>> Sent: Monday, February 11, 2008 1:23 PM
>> Subject: JAX-RS Support: Error in the JAX-RS specs for matching method
>> types?
>>
>>
>> > Hi all,
>> >
>> > I think there is an error in the algorithm in the JAX-RS specs for
>> choosing
>> > the resource method (see bullet 2. in section 2.6)
>> >
>> > Consider the following scenario:
>> >
>> > I have a resource with 2 methods:
>> >
>> > @HttpMethod("GET")
>> > @UriTemplate("/users/{id}")
>> > @ProduceMime("text/xml")
>> > public Response getUser(@UriParam("id") String id) throws Exception {
>> ....}
>> >
>> > @HttpMethod("GET")
>> > @UriTemplate("/users/{id}")
>> > @ProduceMime("application/json")
>> > public Response getUserJSON(@UriParam("id") String id) throws Exception
>> {
>> > ....}
>> >
>> > If I then send a request to /users/24 with Accept headers of  "text/xml,
>> > */*" one would expect the "text/xml" method to be invoked. However
>> following
>> > the algorithm in the spec it is undefined which method should be
>> invoked.
>> >
>> > More details:
>> >
>> > In the algorithm, both methods match the accept headers i.e. they are
>> both
>> > added to the list of "matching resource methods" This list is then
>> sorted
>> > using the consume mime type (not relevant in this case) and then by the
>> > produce mime. In this case it will compare "text/xml" against
>> > "application/json". As both are equally specific it is undefined which
>> > should be first. (The current version of CXF trunk sorts
>> application/json to
>> > the top of the list)
>> >
>> > However surely as the "text/xml" method matches the accept header
>> > specifically it should always be returned first? See -
>> > http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html for further
>> details
>> >
>> > I think this is an error in the spec (not how it's been implemented in
>> CXF).
>> >
>> >
>> > Can anyone confirm if I've made any mistakes in my reasoning?
>> >
>> > Barry
>> >
>>
>> ----------------------------
>> IONA Technologies PLC (registered in Ireland)
>> Registered Number: 171387
>> Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
>>
>

----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Mime
View raw message