users@jersey.java.net

Re: [Jersey] prioritising HTML representations in web applications when using implicit or explicit views

From: James Strachan <james.strachan_at_gmail.com>
Date: Wed, 28 Jan 2009 09:38:36 +0000

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? 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've not tested with
other webkit based browsers yet so maybe Chromium & Android have a
similar accept header issues?

-- 
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://fusesource.com/