users@jax-rs-spec.java.net

[jax-rs-spec users] Re: Possible issues with section 3.8 and sentences 9/10

From: Sergey Beryozkin <sberyozkin_at_talend.com>
Date: Wed, 18 Feb 2015 13:45:05 +0000

Hi Marek,

Are you referring to the fact a custom ContainerResponseFilter can set a
final response media type to a concrete type if the current one has a
wildcard ?
That is true. I guess it is better than defaulting. It resolves it then
as far as I'm concerned.

Thanks, Sergey

On 18/02/15 13:36, Marek Potociar wrote:
> 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
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>