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