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