On Feb 9, 2009, at 10:17 AM, Bill Burke wrote:
> Maybe section 3.8 should remove step 4 then?
Step 4 is just echoing the HTTP 1.1 spec (section 14.1): "If no Accept
header field is present, then it is assumed that the client accepts
all media types". I don't think we should assign any other
significance to its omission.
Marc.
> If there is no @Produces, and no response content-type header and
> no Accept header, IMO, a 406 should be returned.
>
> Marc Hadley wrote:
>> What does the request accept header look like, I'm guessing its not
>> very specific ? If it has anything other than text/yaml then the
>> runtime should select the ToStringProvider, for text/yaml it should
>> select the YamlProvider.
>> Requiring the content-type to be set means you have to edit all of
>> the resource classes to add support for a new media type, currently
>> you can just drop in a new MBW. I think the issue you bring up only
>> occurs when the client doesn't include a specific accept header
>> with a request.
>> Marc.
>> On Feb 7, 2009, at 12:10 AM, Bill Burke wrote:
>>> I've recently run into problems with the current rules on
>>> "Determining the MediaType of Responses" in Section 3.8.
>>>
>>> Specifically, if there is no @Produces and no Content-Type header
>>> set, the the JAX-RS provider creates a set of possible media types
>>> from MessageBodyWriters that "support" the entity type.
>>>
>>> *THIS IS BAD*
>>>
>>> Why? Adding a new provider can drastically change the behavior or
>>> your application.
>>>
>>> I have a writer that just does object.toString() for all text/*:
>>>
>>> @Produces("text/*")
>>> public class ToStringProvider implements MessageBodyWriter
>>> {
>>> boolean isWritable(...)
>>> {
>>> return true;
>>> }
>>> }
>>>
>>> I come along later in the app development cycle and introduce a
>>> provider that can generate YAML from any Java Object:
>>>
>>> @Produces({"text/yaml", "text/x-yaml", "application/x-yaml"})
>>> public class YamlProvider implements MessageBodyWriter
>>> {
>>> boolean isWritable(...)
>>> {
>>> return true;
>>> }
>>> }
>>>
>>> Now, instead of writing text/plain, I'm not outputting YAML. A
>>> seemingly innocent introduction of a provider change the whole
>>> behavior of the application (unknowingly).
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
>>> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>>>
>> ---
>> Marc Hadley <marc.hadley at sun.com>
>> CTO Office, Sun Microsystems.
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
>> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.