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