Hi Marek
CXF checks if Entity's Content-Language & Content-Encoding are not null
before setting them as headers. This check would be easy to remove and I
guess I agree that that example code is a bit 'disconnected', the
headers are set separately from the entity container also making it
possible to set those headers,
But I'd say this would lead to not maintaining the principle of the
least surprise, it can take awhile indeed for users to figure why the
explicitly set headers do not end up being sent.
Cheers, Sergey
On 05/11/13 19:28, Marek Potociar wrote:
> Fellow experts,
>
> Please take a look at this SO entry (and my answer):
> http://stackoverflow.com/questions/19794014/why-does-jersey-swallow-my-content-encoding-header
>
> While the javadoc in the JAX-RS client API is clear that:
>
> "/Any variant-related HTTP headers previously set (namely|Content-Type|,
> |Content-Language| and |Content-Encoding|) will be overwritten using the
> entity variant information./"
>
> I am still curious if we should consider null to be a "variant
> information". IOW, whether we should overwrite those Content-* headers
> that are set if we only have null in stored for the header in the
> variant instance. Jersey currently always overwrites all these headers.
> What are you doing in your implementations in this case?
>
> Thanks,
> Marek