Hi Santiago
On 23/04/13 14:01, Santiago Pericas-Geertsen wrote:
> Hi Sergey,
>
> Certainly something we can look at in 2.1. I think this is a result of using wildcards in @Produces, something that I believe should be generally avoided. We can certainly look at this algorithm again and try to improve it.
I guess you are right that if a provider has @Produces("text/xml") then
if we have
Accept: text/*
@Produces("text/*") on the op resource method/class,
then it really should become "text/xml". But the way the spec text is
written prevents "text/xml" from being selected unless the op resource
method (or its class) has no explicitly declared @Produces.
We can probably say that if a response Content-Type (obtained after the
intersection of the selected operation's Produces and HTTP Accept
values) contains a wildcard then default to the 'best' media type of the
selected MBW, in this case, even if we end up with application/* then
we'd still most likely get application/xml or application/json, etc.
And then, as the last report, use that defaulting to
application/octet-stream
Sergey
>
> -- Santiago
>
> On Apr 22, 2013, at 12:49 PM, Sergey Beryozkin<sberyozkin_at_talend.com> wrote:
>
>> Hi
>>
>> Section 3.8 concludes with
>>
>> 9. If M contains ‘*/*’ or ‘application/*’, set Mselected = ‘application/octet-stream’, finish.
>> 10. Generate a NotAcceptableException (406 status) and no entity.
>>
>> I'm seeing an early test failing where we have
>>
>> Accept: text/*
>> Produces: text/*
>>
>> CXF produces: 200 + application/octet-stream, test expects 406.
>> It is not a big problem for us to make sure that if a wildcard response types does not meet requirements from 9, them it is 406 (as per 10.), however, I wonder, should we always do 9. whenever a response type contains "*", not only if it is a wildcard or application/* ?
>>
>> It is kind of strange to get 406 returned when a match has been successful.
>>
>> I can open a minor improvement request for 2.1 if you agree
>>
>> Sergey
>>
>>
>