On 08 Nov 2013, at 17:31, Bill Burke <bburke_at_redhat.com> 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?
Am I? All I am suggesting is that if the Variant field contains null, then this null value should not override any existing header previously set by the user in the client request. My suggestion is based on the fact that relevant javadoc is not strict in that respect. Please point me to the part of the spec I'm changing and I reconsider (and most likely take back) my proposal.
Marek
>
> 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
>>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com