Content negotiation woes

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Content negotiation woes

Daniel Larsson
Hi all,

How do people generally handle content negotiation? In theory, this is wonderfully handled with the Accept header, and Jersey's @Produces annotation, but in practice, several popular browsers send non-sensical Accept header values, making content negotiation a pain.

Jersey provides a way to fake Accept header values through URL extensions. The drawback with this approach is you have to be careful with resource naming (e.g. if you expose users as resources, and someone decides to name themselves "foo.xml").

Write a servlet filter to rewrite the Accept header for known bad user agents? *sigh*

Give up on content negotiation, and provide separate resources for different representations? :-/

Reply | Threaded
Open this post in threaded view
|

Re: Content negotiation woes

Paul Sandoz
Administrator
Hi Daniel,

Jersey supports what is termed quality of source, which means you can  
declare something like this:

  @Produces("text/html;qs=2")

and "text/html" will take priority over say:

  @Produces("application/xml") // qs defaults to 1

if "text/html" is compatible if any of the acceptable media types in  
the Accept header.

However, one issue with this is it can be a pain to modify the  
@Produces declarations. Jersey should also support the declaration of  
a default qs value for one or more media types. Could you log an issue?

I think this may be a better approach than implementing a filter that  
checks for certain user agents.

Paul.


On Jun 10, 2010, at 6:13 PM, Daniel Larsson wrote:

> Hi all,
>
> How do people generally handle content negotiation? In theory, this  
> is wonderfully handled with the Accept header, and Jersey's  
> @Produces annotation, but in practice, several popular browsers send  
> non-sensical Accept header values, making content negotiation a pain.
>
> Jersey provides a way to fake Accept header values through URL  
> extensions. The drawback with this approach is you have to be  
> careful with resource naming (e.g. if you expose users as resources,  
> and someone decides to name themselves "foo.xml").
>
> Write a servlet filter to rewrite the Accept header for known bad  
> user agents? *sigh*
>
> Give up on content negotiation, and provide separate resources for  
> different representations? :-/
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Content negotiation woes

Daniel Larsson
Logged as https://jersey.dev.java.net/issues/show_bug.cgi?id=544

On Fri, Jun 11, 2010 at 8:52 PM, Paul Sandoz <[hidden email]> wrote:
Hi Daniel,

Jersey supports what is termed quality of source, which means you can declare something like this:

 @Produces("text/html;qs=2")

and "text/html" will take priority over say:

 @Produces("application/xml") // qs defaults to 1

if "text/html" is compatible if any of the acceptable media types in the Accept header.

However, one issue with this is it can be a pain to modify the @Produces declarations. Jersey should also support the declaration of a default qs value for one or more media types. Could you log an issue?

I think this may be a better approach than implementing a filter that checks for certain user agents.

Paul.



On Jun 10, 2010, at 6:13 PM, Daniel Larsson wrote:

Hi all,

How do people generally handle content negotiation? In theory, this is wonderfully handled with the Accept header, and Jersey's @Produces annotation, but in practice, several popular browsers send non-sensical Accept header values, making content negotiation a pain.

Jersey provides a way to fake Accept header values through URL extensions. The drawback with this approach is you have to be careful with resource naming (e.g. if you expose users as resources, and someone decides to name themselves "foo.xml").

Write a servlet filter to rewrite the Accept header for known bad user agents? *sigh*

Give up on content negotiation, and provide separate resources for different representations? :-/



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]