[jira] Commented: (CXF-2903) Unexpected HTTP response code for @Consumes mismatch

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