Barry, is it a blocker issue for you ?
Cheers, Sergey
----- Original Message -----
From: "Sergey Beryozkin" <[EMAIL PROTECTED]>
To: <[email protected]>
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" <[EMAIL PROTECTED]>
To: <[email protected]>
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 <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]>
To: <[email protected]>
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
