On Jan 28, 2009, at 10:38 AM, James Strachan wrote:
> 2009/1/28 Paul Sandoz <Paul.Sandoz_at_sun.com>:
>> On Jan 28, 2009, at 12:47 AM, James Strachan wrote:
>>
>>> 2009/1/27 James Strachan <james.strachan_at_gmail.com>:
>>>>
>>>> Awesome stuff Paul, many thanks! Taking it for a spin now...
>>>
>>> It works like a charm! Great stuff Paul!
>>>
>>
>> Great. I am still not sure about the prioritization aspect of media
>> types
>> declared with @ImplicitProduces, it seems a hack that might be hard
>> to
>> remove when priorities are supported, or not be of the desirable
>> behavior
>> for some. It would be more consistent if @ImplicitProduces has the
>> same
>> order semantics as @Produces.
>
> Yeah.
>
> I wonder if we could just add support for priorities in the MIME types
> for now?
For @Produces that will require more work :-) I do not have time to
investigate and implement in time for the 1.0.2 release with all the
other things that need to be done.
> Few folks use them anyway right now so adding support for
> them doesn't seem to break anything? It seems like having the
> priority/quality modifier on MIME types is the long term clean
> solution to avoid hacks.
>
> Another option could just be some global setting on the Jersey servlet
> where you could add a ranking for MIME types (e.g. to weight text/html
> as 1.0 and text/xml as 0.5 to be able to work around the Safari
> oddness).
>
>
>> Thus I think instead we should support a application request filter
>> that
>> looks at the user-agent header and accept header and then modifies
>> the
>> latter. Then that filter can be included as part of the
>> application. IMHO
>> that would be a better way to work around the odd Safari accept
>> header. What
>> do you think?
>
> Anyone making a web application which serves up HTML and XML/JSON from
> the same set of resources is gonna hit this; so I'd rather avoid if we
> can end users having to write a custom filter. I'd rather it be some
> flag we turn on somewhere (which could enable a filter shipped with
> Jersey). Indeed I'd rather the flag be on by default (with suitable
> documentation in the Implicit/Explicit Views documentation) as any
> user serving HTML and XML/JSON is gonna hit this or get it as a bug
> report if they don't test with safari/iphone etc.
I agree. I was not suggesting that this would be left to Jersey users
to develop. I want to ensure the current behaviour is retained with
the ability to tweak it. Your suggestion of an application wide
priority support seems like a good approach with default settings when
implicit views are enabled.
> I've not tested with
> other webkit based browsers yet so maybe Chromium & Android have a
> similar accept header issues?
>
Quite possibly.
Paul.