I would personally prefer we do not add more defaults. It makes things confusing and every implementation is already able to deliver default providers that will deal with this situation.
Cheers,
Marek
> On 17 Feb 2015, at 23:29, Sergey Beryozkin <sberyozkin_at_talend.com> wrote:
>
> Hi Santiago
>
> It sounds convincing.
>
> I guess I'd only consider adding one more default,
> text/* -> text/plain.
>
> application/* -> application/octet-stream
> is already there and it works because ultimately any application/* is an octet stream.
>
> I just think that it is not 'friendly' for the following code
>
> String text = target.request("text/*").get(String.class);
>
> to fail with the 406-related exception in the case where a server has a text/* too.
>
> If we have multipart/* or image/* - it is different but text/plain can be a default.
>
> Do you reckon it may make sense to do a minor text update or prefer keep it unchanged ? Minor issue as far as I'm concerned
>
> Thanks, Sergey
>
>
> On 17/02/15 20:13, Santiago Pericas-Geertsen wrote:
>> Hi Sergey,
>>
>> I personally think that if a _static_ type is not concrete, like text/*, then the _dynamic_ type should be concrete. In other words, in this case the application code should return a Response with the actual media type in the family text/* that it wants to use, such as text/plain.
>>
>> If it does so, the algorithm in Section 3.8 stops after step (1). In addition, the static type could be a list of concrete types, which would also be an improvement. We could add more defaults, but frankly these are just guesses and nothing more.
>>
>> — Santiago
>>
>>> On Feb 16, 2015, at 4:51 PM, Sergey Beryozkin <sberyozkin_at_talend.com> wrote:
>>>
>>> Hi All,
>>>
>>> I'm resuming this thread that was started at the JSR-339 list (more comments to the original email can be checked at that list).
>>> I've just seen another CXF issue opened specifically to do with this issue.
>>>
>>> The client does:
>>> GET /a
>>> Accept: text/*
>>>
>>> The server has
>>>
>>> @Produces(text/*)
>>> @GET @Path("/a")
>>>
>>> The spec requires 406 in this case and this just appears to be wrong.
>>> Neither a client nor a server have made a mistake: the client is stating it can take any text variations, the server is expecting the client to specify a concrete Accept - in fact some other clients may do just that.
>>>
>>> Any ideas how it can be improved ?
>>> Given a final text/*, what can server actually return ?
>>>
>>> CXF does application/octet-stream. The client can at least react to the possible deserialization issue locally or it may even work if String is expected for example.
>>>
>>> Should we at least provide the defaults for some well known types, IMHO this might be a reasonable compromise.
>>>
>>> For example, the spec defaults application/* to application/octet-stream. Similarly text/* can be to text/plain. Do the same for few more well known types ?
>>>
>>>
>>> Thanks, Sergey
>>>
>>>
>>>
>>>
>>> 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.
>>>>
>>>> -- 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
>>>>>
>>>>>
>>>>
>>>
>>
>