You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Donal Fellows (JIRA)" <ji...@apache.org> on 2010/07/22 02:51:51 UTC
[jira] Created: (CXF-2903) Unexpected HTTP response code for
@Consumes mismatch
Unexpected HTTP response code for @Consumes mismatch
----------------------------------------------------
Key: CXF-2903
URL: https://issues.apache.org/jira/browse/CXF-2903
Project: CXF
Issue Type: Bug
Components: JAX-RS
Affects Versions: 2.2.9
Reporter: Donal Fellows
I have an interface with a method annotated as accepting XML (with {{@Consumes("application/xml")}} and {{@POST}}) and a class that implements that interface; the {{@Path}} is not matched for {{@POST}} by any other method. When I call it and pass in content with that MIME type, it all works. When I pass in content of another MIME type, I get a 404 response; this is unexpected, as I'd expect a 406 (Not Acceptable) response that tells me to pass in XML (to be clear, this _is_ an error case). Having to work around this by accepting all types and doing my own content type negotiation is unacceptable, especially since that decreases the utility of the generated WADL file significantly. Surely CXF should be doing this sort of work for me?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-2903) Unexpected HTTP response code for
@Consumes mismatch
Posted by "Sergey Beryozkin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-2903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12892450#action_12892450 ]
Sergey Beryozkin commented on CXF-2903:
---------------------------------------
I can definitely see a test verifying 415 being returned and I suspect TCK would've failed otherwise.
I'm just curious, could it be that
int status = pathMatched == 0 ? 404 : methodMatched == 0 ? 405
: consumeMatched == 0 ? 415 : produceMatched == 0 ? 406 : 404;
is broken a bit (too complicated) and say JVM spec makes it vague enough to figure out how this if loop is executed ?
Which SDK do you use ?
I feel that the only thing that I can do is to write the explicit if expression and hope it fixes it for you. If you could download CXF 2.2.9 source and put a breakpoint in JAXRSUtils.findTargetMethod, at a point where the above expression is executed then it would really help
> Unexpected HTTP response code for @Consumes mismatch
> ----------------------------------------------------
>
> Key: CXF-2903
> URL: https://issues.apache.org/jira/browse/CXF-2903
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
> Affects Versions: 2.2.9
> Reporter: Donal Fellows
> Attachments: taverna.log
>
>
> I have an interface with a method annotated as accepting XML (with {{@Consumes("application/xml")}} and {{@POST}}) and a class that implements that interface; the {{@Path}} is not matched for {{@POST}} by any other method. When I call it and pass in content with that MIME type, it all works. When I pass in content of another MIME type, I get a 404 response; this is unexpected, as I'd expect a 406 (Not Acceptable) response that tells me to pass in XML (to be clear, this _is_ an error case). Having to work around this by accepting all types and doing my own content type negotiation is unacceptable, especially since that decreases the utility of the generated WADL file significantly. Surely CXF should be doing this sort of work for me?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-2903) Unexpected HTTP response code for
@Consumes mismatch
Posted by "Sergey Beryozkin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-2903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12892491#action_12892491 ]
Sergey Beryozkin commented on CXF-2903:
---------------------------------------
try the latest 2.2.10-SNAPSHOT or please debug
> Unexpected HTTP response code for @Consumes mismatch
> ----------------------------------------------------
>
> Key: CXF-2903
> URL: https://issues.apache.org/jira/browse/CXF-2903
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
> Affects Versions: 2.2.9
> Reporter: Donal Fellows
> Attachments: taverna.log
>
>
> I have an interface with a method annotated as accepting XML (with {{@Consumes("application/xml")}} and {{@POST}}) and a class that implements that interface; the {{@Path}} is not matched for {{@POST}} by any other method. When I call it and pass in content with that MIME type, it all works. When I pass in content of another MIME type, I get a 404 response; this is unexpected, as I'd expect a 406 (Not Acceptable) response that tells me to pass in XML (to be clear, this _is_ an error case). Having to work around this by accepting all types and doing my own content type negotiation is unacceptable, especially since that decreases the utility of the generated WADL file significantly. Surely CXF should be doing this sort of work for me?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-2903) Unexpected HTTP response code for
@Consumes mismatch
Posted by "Donal Fellows (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-2903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12892313#action_12892313 ]
Donal Fellows commented on CXF-2903:
------------------------------------
I've attached a section of the log file from the webapp, logged at level FINE. It's... noisy, but the relevant lines are probably these two (the second split only for clarity):
{code:title=Log section}26-Jul-2010 14:47:07 org.apache.cxf.jaxrs.utils.JAXRSUtils logNoMatchMessage
FINE: No method match, method name : setStatus, request path : /status,
method @Path : /status, HTTP Method : PUT, method HTTP Method : PUT,
ContentType : text/html, method @Consumes : text/plain,, Accept : */*,,
method @Produces : text/plain,.{code}
While the failure to match is correct, it seems to be just forgetting that it saw it. (I know the client shouldn't be producing text/html here. It's just a hacked-around script to expose this issue.)
> Unexpected HTTP response code for @Consumes mismatch
> ----------------------------------------------------
>
> Key: CXF-2903
> URL: https://issues.apache.org/jira/browse/CXF-2903
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
> Affects Versions: 2.2.9
> Reporter: Donal Fellows
> Attachments: taverna.log
>
>
> I have an interface with a method annotated as accepting XML (with {{@Consumes("application/xml")}} and {{@POST}}) and a class that implements that interface; the {{@Path}} is not matched for {{@POST}} by any other method. When I call it and pass in content with that MIME type, it all works. When I pass in content of another MIME type, I get a 404 response; this is unexpected, as I'd expect a 406 (Not Acceptable) response that tells me to pass in XML (to be clear, this _is_ an error case). Having to work around this by accepting all types and doing my own content type negotiation is unacceptable, especially since that decreases the utility of the generated WADL file significantly. Surely CXF should be doing this sort of work for me?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-2903) Unexpected HTTP response code for
@Consumes mismatch
Posted by "Sergey Beryozkin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-2903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12892386#action_12892386 ]
Sergey Beryozkin commented on CXF-2903:
---------------------------------------
thanks for posting the log message.
I'm a bit confused though by "it seems to be just forgetting that it saw it" - you've commented that it is indeed 415 - did you mean that you agree that the spec requires it for @Consumes not matching Content-Type cases or do you actually see 415 being returned ?
> Unexpected HTTP response code for @Consumes mismatch
> ----------------------------------------------------
>
> Key: CXF-2903
> URL: https://issues.apache.org/jira/browse/CXF-2903
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
> Affects Versions: 2.2.9
> Reporter: Donal Fellows
> Attachments: taverna.log
>
>
> I have an interface with a method annotated as accepting XML (with {{@Consumes("application/xml")}} and {{@POST}}) and a class that implements that interface; the {{@Path}} is not matched for {{@POST}} by any other method. When I call it and pass in content with that MIME type, it all works. When I pass in content of another MIME type, I get a 404 response; this is unexpected, as I'd expect a 406 (Not Acceptable) response that tells me to pass in XML (to be clear, this _is_ an error case). Having to work around this by accepting all types and doing my own content type negotiation is unacceptable, especially since that decreases the utility of the generated WADL file significantly. Surely CXF should be doing this sort of work for me?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-2903) Unexpected HTTP response code for
@Consumes mismatch
Posted by "Sergey Beryozkin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-2903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12891342#action_12891342 ]
Sergey Beryozkin commented on CXF-2903:
---------------------------------------
Hi
this is the rather cryptic code fragment :
int status = pathMatched == 0 ? 404 : methodMatched == 0 ? 405
: consumeMatched == 0 ? 415 : produceMatched == 0 ? 406 : 404;
404 would be reported if either path not matched or if the candidate list is empty. Note that according to the spec
Consumes mismatch will result in 415 and Produces mismatch will result in 406.
I'd expect 415 in your case given that @Consumes does not match the media type.
Can you enable DEBUG log level - it should give you more info about what is happening. Let us know the details please
> Unexpected HTTP response code for @Consumes mismatch
> ----------------------------------------------------
>
> Key: CXF-2903
> URL: https://issues.apache.org/jira/browse/CXF-2903
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
> Affects Versions: 2.2.9
> Reporter: Donal Fellows
>
> I have an interface with a method annotated as accepting XML (with {{@Consumes("application/xml")}} and {{@POST}}) and a class that implements that interface; the {{@Path}} is not matched for {{@POST}} by any other method. When I call it and pass in content with that MIME type, it all works. When I pass in content of another MIME type, I get a 404 response; this is unexpected, as I'd expect a 406 (Not Acceptable) response that tells me to pass in XML (to be clear, this _is_ an error case). Having to work around this by accepting all types and doing my own content type negotiation is unacceptable, especially since that decreases the utility of the generated WADL file significantly. Surely CXF should be doing this sort of work for me?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CXF-2903) Unexpected HTTP response code for
@Consumes mismatch
Posted by "Donal Fellows (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-2903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Donal Fellows updated CXF-2903:
-------------------------------
Attachment: example.zip
Zipped simple project that demonstrates
> Unexpected HTTP response code for @Consumes mismatch
> ----------------------------------------------------
>
> Key: CXF-2903
> URL: https://issues.apache.org/jira/browse/CXF-2903
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
> Affects Versions: 2.2.9
> Reporter: Donal Fellows
> Attachments: example.zip, taverna.log
>
>
> I have an interface with a method annotated as accepting XML (with {{@Consumes("application/xml")}} and {{@POST}}) and a class that implements that interface; the {{@Path}} is not matched for {{@POST}} by any other method. When I call it and pass in content with that MIME type, it all works. When I pass in content of another MIME type, I get a 404 response; this is unexpected, as I'd expect a 406 (Not Acceptable) response that tells me to pass in XML (to be clear, this _is_ an error case). Having to work around this by accepting all types and doing my own content type negotiation is unacceptable, especially since that decreases the utility of the generated WADL file significantly. Surely CXF should be doing this sort of work for me?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-2903) Unexpected HTTP response code for
@Consumes mismatch
Posted by "Donal Fellows (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-2903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12902816#action_12902816 ]
Donal Fellows commented on CXF-2903:
------------------------------------
I suspect that the right way forward here is to consider what the mental model of programmers trying to use such things is. While this is something which should probably be considered fairly widely, I'll just go ahead and explain _my_ model. Maybe others will match up too. :-)
I'd expect (on consideration) the path to be the most fundamental thing (though not the matching of the query part, any cookies, etc.) If the path can't be matched, it's {{404}}.
Then I'd expect the verb to be checked; that's definitely more fundamental than the type of the data being passed in or asked for. (Path matched but not method would be {{405}}.)
It's only once you've got past that and are considering produces and consumes that things get a bit ambiguous, though I might go for considering consume matching first on the grounds that that's data the user is giving to you and it's of some definite type (assuming it's present). Produce matching is the least possible I suppose, since a fair fraction of clients say they'll accept anything anyway...
In this case, we've got {{GET/no-data}} and {{PUT/plain}} available, and {{PUT/html}} offered, so that sounds to me like a double mismatch for one and a single mismatch on the other. To say that the response should be "use a different method" is a little surprising, since that's asking for variation in a way where it would take two steps to get to a match rather than in a way that is a single step to a match.
Maybe the _real_ right thing to do is for each potential match to consider the Hamming distance to a successful match, as it were? Hmm... (and yes, I've only just thought of that as I write this paragraph. ;-))
> Unexpected HTTP response code for @Consumes mismatch
> ----------------------------------------------------
>
> Key: CXF-2903
> URL: https://issues.apache.org/jira/browse/CXF-2903
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
> Affects Versions: 2.2.9, 2.2.10
> Reporter: Donal Fellows
> Attachments: example.zip, taverna.log
>
>
> I have an interface with a method annotated as accepting XML (with {{@Consumes("application/xml")}} and {{@POST}}) and a class that implements that interface; the {{@Path}} is not matched for {{@POST}} by any other method. When I call it and pass in content with that MIME type, it all works. When I pass in content of another MIME type, I get a 404 response; this is unexpected, as I'd expect a 406 (Not Acceptable) response that tells me to pass in XML (to be clear, this _is_ an error case). Having to work around this by accepting all types and doing my own content type negotiation is unacceptable, especially since that decreases the utility of the generated WADL file significantly. Surely CXF should be doing this sort of work for me?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-2903) Unexpected HTTP response code for
@Consumes mismatch
Posted by "Donal Fellows (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-2903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12892310#action_12892310 ]
Donal Fellows commented on CXF-2903:
------------------------------------
You're right about it being 415, not 406.
> Unexpected HTTP response code for @Consumes mismatch
> ----------------------------------------------------
>
> Key: CXF-2903
> URL: https://issues.apache.org/jira/browse/CXF-2903
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
> Affects Versions: 2.2.9
> Reporter: Donal Fellows
> Attachments: taverna.log
>
>
> I have an interface with a method annotated as accepting XML (with {{@Consumes("application/xml")}} and {{@POST}}) and a class that implements that interface; the {{@Path}} is not matched for {{@POST}} by any other method. When I call it and pass in content with that MIME type, it all works. When I pass in content of another MIME type, I get a 404 response; this is unexpected, as I'd expect a 406 (Not Acceptable) response that tells me to pass in XML (to be clear, this _is_ an error case). Having to work around this by accepting all types and doing my own content type negotiation is unacceptable, especially since that decreases the utility of the generated WADL file significantly. Surely CXF should be doing this sort of work for me?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-2903) Unexpected HTTP response code for
@Consumes mismatch
Posted by "Sergey Beryozkin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-2903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12903077#action_12903077 ]
Sergey Beryozkin commented on CXF-2903:
---------------------------------------
The following code should do much better :
if (pathMatched == 0) {
status = 404;
} else if (methodMatched == 0) {
status = 405;
} else if (consumeMatched <= produceMatched) {
status = 415;
} else {
status = 406;
}
If we have either path or method not matching at all then it's 404 or 405.
But if we have at least one HTTP verb match (in which case we definitely had at least one (the corresponding) path matched) then even if we had many other methods with verbs not matched, we still have case of a pretty close match where path and HTTP method matched and thus it is either a consume or produce mismatch.
thanks
> Unexpected HTTP response code for @Consumes mismatch
> ----------------------------------------------------
>
> Key: CXF-2903
> URL: https://issues.apache.org/jira/browse/CXF-2903
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
> Affects Versions: 2.2.9, 2.2.10
> Reporter: Donal Fellows
> Attachments: example.zip, taverna.log
>
>
> I have an interface with a method annotated as accepting XML (with {{@Consumes("application/xml")}} and {{@POST}}) and a class that implements that interface; the {{@Path}} is not matched for {{@POST}} by any other method. When I call it and pass in content with that MIME type, it all works. When I pass in content of another MIME type, I get a 404 response; this is unexpected, as I'd expect a 406 (Not Acceptable) response that tells me to pass in XML (to be clear, this _is_ an error case). Having to work around this by accepting all types and doing my own content type negotiation is unacceptable, especially since that decreases the utility of the generated WADL file significantly. Surely CXF should be doing this sort of work for me?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CXF-2903) Unexpected HTTP response code for
@Consumes mismatch
Posted by "Donal Fellows (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-2903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Donal Fellows updated CXF-2903:
-------------------------------
Attachment: taverna.log
> Unexpected HTTP response code for @Consumes mismatch
> ----------------------------------------------------
>
> Key: CXF-2903
> URL: https://issues.apache.org/jira/browse/CXF-2903
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
> Affects Versions: 2.2.9
> Reporter: Donal Fellows
> Attachments: taverna.log
>
>
> I have an interface with a method annotated as accepting XML (with {{@Consumes("application/xml")}} and {{@POST}}) and a class that implements that interface; the {{@Path}} is not matched for {{@POST}} by any other method. When I call it and pass in content with that MIME type, it all works. When I pass in content of another MIME type, I get a 404 response; this is unexpected, as I'd expect a 406 (Not Acceptable) response that tells me to pass in XML (to be clear, this _is_ an error case). Having to work around this by accepting all types and doing my own content type negotiation is unacceptable, especially since that decreases the utility of the generated WADL file significantly. Surely CXF should be doing this sort of work for me?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-2903) Unexpected HTTP response code for
@Consumes mismatch
Posted by "Sergey Beryozkin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-2903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12902097#action_12902097 ]
Sergey Beryozkin commented on CXF-2903:
---------------------------------------
thanks for providing an example webapp.
I've spent a bit of time debugging it today and finally I was able to reproduce 404. I was even nearly ready to commit a fix.
But then realized it was trickier than I thought.
See, HelloWorld has two methods and when the 2nd PUT with mismatching Content-Type is sent, we actually have two non-candidates,
one is the method annotated with GET and the other one with PUT and @Consumes(text/plain).
So the fact that both methods can not be selected is recorded (method mismatch for the 1st one and consumes mismatch for the 2nd one).
If you had say 2 separate methods annotated with PUTs but with different Consumes or just a single PUT then you;d get 415 as expected in case of wrong Content-Type.
but in this case we have the case of the mismatched method and the mismatched Consumes. The question is : which mismatch is the 'better' one, as far as selecting the error code is concerned ? Here we have GET and PUT but you might've had POST & PUT instead thus a method mismatch is equally serious...
Thoughts ?
Not really sure if it can be fixed cleanly. We could do a 'better analysis' in case of many methods being not matched. In that case we can check what did not match most : method, produces or consumes and the 'worst one' would be used to select the response code. Still not the perfect solution...
> Unexpected HTTP response code for @Consumes mismatch
> ----------------------------------------------------
>
> Key: CXF-2903
> URL: https://issues.apache.org/jira/browse/CXF-2903
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
> Affects Versions: 2.2.9, 2.2.10
> Reporter: Donal Fellows
> Attachments: example.zip, taverna.log
>
>
> I have an interface with a method annotated as accepting XML (with {{@Consumes("application/xml")}} and {{@POST}}) and a class that implements that interface; the {{@Path}} is not matched for {{@POST}} by any other method. When I call it and pass in content with that MIME type, it all works. When I pass in content of another MIME type, I get a 404 response; this is unexpected, as I'd expect a 406 (Not Acceptable) response that tells me to pass in XML (to be clear, this _is_ an error case). Having to work around this by accepting all types and doing my own content type negotiation is unacceptable, especially since that decreases the utility of the generated WADL file significantly. Surely CXF should be doing this sort of work for me?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CXF-2903) Unexpected HTTP response code for
@Consumes mismatch
Posted by "Donal Fellows (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-2903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Donal Fellows updated CXF-2903:
-------------------------------
Affects Version/s: 2.2.10
> Unexpected HTTP response code for @Consumes mismatch
> ----------------------------------------------------
>
> Key: CXF-2903
> URL: https://issues.apache.org/jira/browse/CXF-2903
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
> Affects Versions: 2.2.9, 2.2.10
> Reporter: Donal Fellows
> Attachments: example.zip, taverna.log
>
>
> I have an interface with a method annotated as accepting XML (with {{@Consumes("application/xml")}} and {{@POST}}) and a class that implements that interface; the {{@Path}} is not matched for {{@POST}} by any other method. When I call it and pass in content with that MIME type, it all works. When I pass in content of another MIME type, I get a 404 response; this is unexpected, as I'd expect a 406 (Not Acceptable) response that tells me to pass in XML (to be clear, this _is_ an error case). Having to work around this by accepting all types and doing my own content type negotiation is unacceptable, especially since that decreases the utility of the generated WADL file significantly. Surely CXF should be doing this sort of work for me?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-2903) Unexpected HTTP response code for
@Consumes mismatch
Posted by "Sergey Beryozkin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-2903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12902578#action_12902578 ]
Sergey Beryozkin commented on CXF-2903:
---------------------------------------
Well, I got a bit confused yesterday while writing that long comment above :-). I'm still mostly standing by it, except that there's indeed a bug in CXF leading to 404 being returned despite the fact that in the example webapp we have a case of
2 path matches
2 produce matches
1 method mismatch (405)
1 consume mismatch (415)
The code like this :
int status;
// criteria matched the least number of times will determine the error code;
// priority : path, method, consumes, produces;
if (pathMatched <= methodMatched && pathMatched <= consumeMatched && pathMatched <= produceMatched) {
status = 404;
} else if (methodMatched <= pathMatched && methodMatched <= consumeMatched
&& methodMatched <= produceMatched) {
status = 405;
} else if (consumeMatched <= pathMatched && consumeMatched <= methodMatched
&& consumeMatched <= produceMatched) {
status = 415;
} else {
status = 406;
}
will ensure that in the case of multiple non-matches the least matched criteria will be used to determine the error code, so if we have say consumes matching only once while the method has been matched twice in the case of two resource methods, then 415 will definitely be returned, etc.
But in this particular case we'll get 405 simply because of the order of branches above. Changing the order would make it more precise in this case but will likely be less in other cases.
What you can do is to spread methods dealing with GET, PUT, etc across multiple root resources.
And, if needed (if such resources have identical class-level @Path value), register a custom ResourceComparator as a jaxrs provider :
http://svn.apache.org/repos/asf/cxf/trunk/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/ext/ResourceComparator.java
which will have a map like this :
"GET" : ReadableRootResource
"PUT" : UpdatableRootResource
etc
and then in the comparator you can get the Message.HTTP_REQUEST_METHOD and select the root resource class which will be used to find the resource method.
This will ensure you always get correct 415 or 406 in case of consumes or produces non-matches
> Unexpected HTTP response code for @Consumes mismatch
> ----------------------------------------------------
>
> Key: CXF-2903
> URL: https://issues.apache.org/jira/browse/CXF-2903
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
> Affects Versions: 2.2.9, 2.2.10
> Reporter: Donal Fellows
> Attachments: example.zip, taverna.log
>
>
> I have an interface with a method annotated as accepting XML (with {{@Consumes("application/xml")}} and {{@POST}}) and a class that implements that interface; the {{@Path}} is not matched for {{@POST}} by any other method. When I call it and pass in content with that MIME type, it all works. When I pass in content of another MIME type, I get a 404 response; this is unexpected, as I'd expect a 406 (Not Acceptable) response that tells me to pass in XML (to be clear, this _is_ an error case). Having to work around this by accepting all types and doing my own content type negotiation is unacceptable, especially since that decreases the utility of the generated WADL file significantly. Surely CXF should be doing this sort of work for me?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-2903) Unexpected HTTP response code for
@Consumes mismatch
Posted by "Sergey Beryozkin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-2903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12892389#action_12892389 ]
Sergey Beryozkin commented on CXF-2903:
---------------------------------------
Actually, have just seen the log...Hmm, I can see the test in the source code verifying 415 is being returned...
I'll need to investigate - can you please post a sample resource class containing a setStatus() method only ? I'd like to see the signature
> Unexpected HTTP response code for @Consumes mismatch
> ----------------------------------------------------
>
> Key: CXF-2903
> URL: https://issues.apache.org/jira/browse/CXF-2903
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
> Affects Versions: 2.2.9
> Reporter: Donal Fellows
> Attachments: taverna.log
>
>
> I have an interface with a method annotated as accepting XML (with {{@Consumes("application/xml")}} and {{@POST}}) and a class that implements that interface; the {{@Path}} is not matched for {{@POST}} by any other method. When I call it and pass in content with that MIME type, it all works. When I pass in content of another MIME type, I get a 404 response; this is unexpected, as I'd expect a 406 (Not Acceptable) response that tells me to pass in XML (to be clear, this _is_ an error case). Having to work around this by accepting all types and doing my own content type negotiation is unacceptable, especially since that decreases the utility of the generated WADL file significantly. Surely CXF should be doing this sort of work for me?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-2903) Unexpected HTTP response code for
@Consumes mismatch
Posted by "Donal Fellows (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-2903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12900685#action_12900685 ]
Donal Fellows commented on CXF-2903:
------------------------------------
Sorry it's taken so long to get back to you on this. Was dealing with a software release and vacations. :-)
I've attached a _very_ simple project that demonstrates the problem, stripped of all the software overburden of my real project. One source file, minimal configuration (other than enabling message logging). There's also a client written in Tcl that submits two PUT requests to the service, one which goes with the correct type and one which goes with the wrong one. Build and install the webapp and run the client script (with the address of the webapp as command line argument) to demonstrate. Or do your own PUT requests; the client is *very* basic and unimportant.
When I run the client against my own deployment (in Tomcat 6, if that matters) I get this output
{code}
url: http://localhost:8080/example-1
uploadType: text/plain
uploadData: Good
code: HTTP/1.1 200 OK
downloadType: text/plain
downloadData: Bye, Good
url: http://localhost:8080/example-1
uploadType: text/html
uploadData: Bad
code: HTTP/1.1 404 Not Found
downloadType: text/xml
downloadData:
{code}
I get the same thing with the 2.2.10 release.
> Unexpected HTTP response code for @Consumes mismatch
> ----------------------------------------------------
>
> Key: CXF-2903
> URL: https://issues.apache.org/jira/browse/CXF-2903
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
> Affects Versions: 2.2.9, 2.2.10
> Reporter: Donal Fellows
> Attachments: example.zip, taverna.log
>
>
> I have an interface with a method annotated as accepting XML (with {{@Consumes("application/xml")}} and {{@POST}}) and a class that implements that interface; the {{@Path}} is not matched for {{@POST}} by any other method. When I call it and pass in content with that MIME type, it all works. When I pass in content of another MIME type, I get a 404 response; this is unexpected, as I'd expect a 406 (Not Acceptable) response that tells me to pass in XML (to be clear, this _is_ an error case). Having to work around this by accepting all types and doing my own content type negotiation is unacceptable, especially since that decreases the utility of the generated WADL file significantly. Surely CXF should be doing this sort of work for me?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CXF-2903) Unexpected HTTP response code for
@Consumes mismatch
Posted by "Sergey Beryozkin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-2903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sergey Beryozkin resolved CXF-2903.
-----------------------------------
Assignee: Sergey Beryozkin
Fix Version/s: 2.3
2.2.11
Resolution: Fixed
> Unexpected HTTP response code for @Consumes mismatch
> ----------------------------------------------------
>
> Key: CXF-2903
> URL: https://issues.apache.org/jira/browse/CXF-2903
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
> Affects Versions: 2.2.9, 2.2.10
> Reporter: Donal Fellows
> Assignee: Sergey Beryozkin
> Fix For: 2.3, 2.2.11
>
> Attachments: example.zip, taverna.log
>
>
> I have an interface with a method annotated as accepting XML (with {{@Consumes("application/xml")}} and {{@POST}}) and a class that implements that interface; the {{@Path}} is not matched for {{@POST}} by any other method. When I call it and pass in content with that MIME type, it all works. When I pass in content of another MIME type, I get a 404 response; this is unexpected, as I'd expect a 406 (Not Acceptable) response that tells me to pass in XML (to be clear, this _is_ an error case). Having to work around this by accepting all types and doing my own content type negotiation is unacceptable, especially since that decreases the utility of the generated WADL file significantly. Surely CXF should be doing this sort of work for me?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.