Paul Sandoz wrote:
> Reto Bachmann-Gmür wrote:
>> Paul Sandoz wrote:
>>>
>>> Or the Accept header could be:
>>> Accept: image/jpeg
>>>
>>> and i could have a resource method:
>>>
>>> @Produces("image/*")
>>> public Response getGeneralImage() { ... }
>>>
>>> Changing this method to be asymmetric will essentially render it
>>> useless.
>>
>> With the accept header image/jpeg a producer of image/jpeg is to be
>> preferred over image/jpeg, so you could first iterate over the
>> candidate producer (sorting them by q-value) checking if there is a
>> subtype of image/jpeg if no match look for exactly image/* and then
>> */*. Returning a subtype (where a type is a subtype of itself) is
>> best, using a generic producer is a fall-back.
>>
>
> The spec says that media types for resource methods or readers/writers
> are sorted before comparison. For readers/writers see section 4.3.2:
>
> When choosing an entity provider an implementation sorts the available
> providers according to the media types they declare support for.
> Sorting of media types follows the general rule: x/y < x/* < */*, i.e.
> a provider that explicitly lists a media types is sorted before a
> provider that lists */*. Quality parameter values are also used such
> that x/y;q=1.0 < x/y;q=0.7.
I understood this text as quality parameter being the secondary key. But
the algorithm (section 3.8) for determining the media type uses the
q-value as primary key. I think using the specificity as primary key for
producers would have the advantage that implementations could provide
multiple type specific providers with different q-value overriding the
default ('*/*', no @Produces) providers.
>
>> Accept: image/x-weird-format, image/png;q=.9
>>
>> the BodyWriter for image/* matches image/x-weird-format but will fail
>> to produce that format and throw an exception. Had the mediatype been
>> passed to isWriteable the BodyWriter could have detected that it
>> doesn't support image/x-weird-format allowing the producer for next
>> accepted format to be used.
>>
>
> The wild card reader can get access to the ordered list of acceptable
> media types (via HttpHeaders) so could choose another media type if the
> most acceptable media type is not supported. This presumes that such a
> reader would support common formats, like image/png in your example.
The implementation would set the Content-Type response header to the
wrong content-type, I think providers should never return another media
type as the one requested by the parameter.
>
> If we want the isReadable/isWriteable methods to have more information
> then they probably require all parameters of the readFrom/writeTo
> methods, minus those for the Input/OutputStream.
I agree with adding media type, as it's not acceptable that adding a
value to the Accept-Header of an otherwise successfully answered request
could render the server unable to respond.
Not sure if other headers should be able to cause the provider to be
skipped in favor of another, Accept-Language maybe?
Reto