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

Reply via email to