cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Beryozkin (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CXF-2903) Unexpected HTTP response code for @Consumes mismatch
Date Tue, 24 Aug 2010 22:04:17 GMT

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


Mime
View raw message