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