users@jersey.java.net

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

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Wed, 28 Jan 2009 12:32:01 +0100

On Jan 28, 2009, at 11:22 AM, James Strachan wrote:

> 2009/1/28 Paul Sandoz <Paul.Sandoz_at_sun.com>:
>> 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.
>
> OK :)
>
> Would you have time to just support the priorities/quality for
> @ImplicitProduces for 1.02?

I am not sure that will work without priorities also being set on
media types in the @Produces since it may be necessary to reduce the
priority of the other media types. Or i suppose increase the priority
in the implicit produces to something > 1. If we assume we cannot
change the priorities in the @Produces then for the Safari header the
text/html would require a priority > 1.0 / 0.8.

There are some edge cases where priorities will not work (if we assume
the Apache conneg algorithm of multiplication of priority with
quality) depending on the priority values. Say for example, because
the moon is rising in Jupiter, that we have a priority of 1.0 for text/
html and a priority of 0.5 for application/xml, and the Safari accept
header for a later version is changed from:

  text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/
plain;q=0.8,image/png,*/*;q=0.5

to:

  text/xml,application/xml,application/xhtml+xml,text/html;q=0.4,text/
plain;q=0.3,image/png,*/*;q=0.2

For the first accept header the order and relative quality would be:

  text/xml, # q = 1
  application/xhtml+xml, # q = 1
  image/png, # q = 1
  text/html;q=0.9, # q = 0.9
  text/plain;q=0.8, # q = 0.8
  application/xml, # q = 0.5
  */*;q=0.5 # q = 0.5

For the second accept header the order and relative quality would be:

  text/xml, # q = 1
  application/xhtml+xml, # q = 1
  image/png, # q = 1
  application/xml, # q = 0.5
  text/html;q=0.2, # q = 0.4
  text/plain;q=0.8, # q = 0.3
  */*;q=0.5 # q = 0.2


All this means developers should pick priorities with care and perhaps
there needs to be a default that works with accept headers of the
common browsers?


> Am thinking that's slightly preferable as
> its a clean longer term solution.

I will look into it as if we support priorities application wide or
specific to @ImplicitProduces the same code needs to be used.

Paul.

> Though a global priority setting
> would be fine too. So long as this issue is resolved for end users I
> don't mind too much how the implementation works really :)
>

>
>>>> 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.
>
> Sorry for the misunderstanding; not had enough coffee yet!
>
> --
> James
> -------
> http://macstrac.blogspot.com/
>
> Open Source Integration
> http://fusesource.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>