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