Hi Bill
On 08/11/13 16:31, Bill Burke wrote:
> Its not covered by the TCK as we pass the TCK :)
>
> But, you're changing the behavior of Variant post spec release. Thought
> that was a no-no?
>
The docs can be considered to be under-specified, for example, does
"entity variant information" includes the uninitialized values or not ?
It is reasonably open to the different interpretations and such given
that 2.1 is a fix release, it might be tweaked a bit
Sergey
> On 11/8/2013 8:28 AM, Marek Potociar wrote:
>> Hi Bill,
>> I'll check if this is covered by TCK, and if it is not, would you
>> agree we should updated our implementations to not override the
>> headers with null values?
>>
>> Marek
>>
>> On 05 Nov 2013, at 22:40, Bill Burke <bburke_at_redhat.com> wrote:
>>
>>> We make the same mistake.
>>>
>>> On 11/5/2013 2:28 PM, 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
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>
>