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: Mon, 16 Feb 2015 21:51:35 +0000

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