users@jax-rs-spec.java.net

[jax-rs-spec users] [jsr339-experts] Re: Should null values in client entity variant overwrite Content-* headers?

From: Sergey Beryozkin <sberyozkin_at_talend.com>
Date: Tue, 5 Nov 2013 21:03:14 +0000

By the way, in case you agree, then the

"Any variant-related HTTP headers previously set (namely|Content-Type|
|Content-Language| and |Content-Encoding|) will be overwritten using the
entity variant information."

can be assumed to be not completely precise and safely enough adjusted a
bit to indicate that only the initialized entity variant bits will be used.

Sergey
On 05/11/13 20:58, Sergey Beryozkin wrote:
> 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