Issue raised: https://issues.apache.org/jira/browse/CXF-1431
On Feb 12, 2008 12:21 PM, Sergey Beryozkin <[EMAIL PROTECTED]> wrote: > Hi Barry > > > I'll raise an issue in JIRA later today. > > Please do, many thanks for indentifying this issue, and fixing the JSR-311 > spec a bit along the way too :-) > > Cheers, Sergey > > > > Hi Sergey, > > > > Thanks for asking - no it's not a little annoying but not a blocker. > > > > I sent a mail to the JSR-311 users list and they confirmed that my > algorithm > > is how it is intended to work and they'll rewrite the paragraph to make > it > > clearer. > > > > I'll raise an issue in JIRA later today. > > > > Barry > > > > On Feb 11, 2008 4:39 PM, Sergey Beryozkin <[EMAIL PROTECTED]> > wrote: > > > >> 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 > >> > > > > ---------------------------- > IONA Technologies PLC (registered in Ireland) > Registered Number: 171387 > Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland >
