On Feb 10, 2009, at 10:58 AM, Reto Bachmann-Gmür wrote:
> An application/octet-stream response is better than nothing, but
> should
> be avoided whenever possible. Basically I think it's confusing that
> the
> concreteness of the response-type depends on the verbosity of the
> accept-header: when the accept-header is just */* one will get
> application/octet-stream whenever the method does not specify a
> concrete
> response type (but is annotated with @Produces).
>
> One way to improve this would be to change step 2 of 3.8 so that the
> produced-types that are taken from the method or class are compared
> against the one taken from the producers and the more concrete of two
> compatible types (one from the method and one from the writer) is
> used.
>
> A different and independent approach would be to expand a */* on the
> server to a list of frequent types: if text/html is acceptable and we
> can produce it we should deliver this rather than
> application/octet-stream, even if it is accepted by a */* or a text/
> * entry.
>
Another possibility is for the writer to use Request.selectVariant
based on its capabilities and overwrite the content type in the
response.
Marc.
---
Marc Hadley <marc.hadley at sun.com>
Sun Microsystems.