> On Apr 29, 2015, at 11:31 AM, Sergey Beryozkin <sberyozkin_at_talend.com> wrote:
>
> Hi Santiago
>
> Perhaps the answer is in your reference to a filter possibly adding a body ? But no, I did not suggest to enforce a non-empty pre-condition on a entity immediately returned from the resource method but on a final response entity after all the response chain filters have finished.
>
>
> Note, section 3.7.8 is only referred to from section 4.2.2, which is where a MessageBodyWriter is discussed.
Although perhaps not explicitly stated in the spec (note that 4.2.2 existed before filters), I believe the algorithm in 3.8 (there is not 3.7.8 right?) should be executed before the response filter chain (so that Content-Type is available for processing). Thus, if an error is reported in that algorithm, it would be too early and not backward compatible as I said before.
Perhaps something could be done at the very last moment before writing the response, but I’m still not convinced this should be in the spec.
— Santiago
>
> On 29/04/15 16:17, Sergey Beryozkin wrote:
>> Hi,
>>
>> I don't understand what are you opposed to.
>>
>> So a programmer has written a bad code missing setting an entity, that
>> is understood.
>>
>> Why sending Content-Type without a body should be enforced ? Where in
>> HTTP specs it is advised/recommended ?
>>
>> It does not make sense from a practical point of view.
>>
>> If RI does it why should other frameworks bear the same burden and send
>> redundant headers ?
>>
>> Ok, I don't mind if the section is staying unchanged. Does not matter.
>>
>> What matters to me though is though an anti-pattern gets enforced at the
>> test level...
>>
>> Sergey.
>>
>>
>>
>>
>>
>> On 29/04/15 15:59, Santiago Pericas-Geertsen wrote:
>>> Sergey,
>>>
>>> This is basically a programmer error. Moreover, it may be possible
>>> that the entity is updated by a response filter. Thus, I don’t think
>>> this change would be backward compatible.
>>>
>>> -1.
>>>
>>> — Santiago
>>>
>>>> On Apr 29, 2015, at 9:05 AM, Sergey Beryozkin <sberyozkin_at_talend.com>
>>>> wrote:
>>>>
>>>> Hi Santiago, All,
>>>>
>>>> Section 3.7.8 (determining the media types of responses) specifies
>>>> how a response media type is determined.
>>>>
>>>> IMHO it is worth clarifying that this section is only effective if a
>>>> response *entity is not null*.
>>>>
>>>> We have a test issue reported something like the following is done:
>>>>
>>>> public Response getMediaType() {
>>>> return Response.ok().type(someMediType).build();
>>>> }
>>>>
>>>> and the client is checking Content-Type.
>>>>
>>>> But it is wrong to return Content-Type if no entity is available, it
>>>> is misleading at the very least as far as HTTP is concerned. It may
>>>> not necessarily break a client but IMHO the JAX-RS related tests
>>>> should not enforce the runtimes sending Content-Type with an empty body
>>>>
>>>> Do you agree ?
>>>>
>>>> Thanks, Sergey
>>>>
>>>
>>
>