Hi Santiago
Please see below,
On 29/04/15 16:57, Santiago Pericas-Geertsen wrote:
>
>> 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.
>
As far as I'm concerned I have to admit it is not something that I'm
prepared to get CXF failing a test for, i.e, for CXF continuing removing
'Content-Type' if the body is empty, i.e the CXF compatibility is
ultimately more important.
Similarly to the issue discussed earlier, it is just about removing a
single if (body is null -> remove CT) branch. Of course that would be
configurable in CXF so that people can choose not to ship CT with the
empty body.
But I honestly would like to give it a try and keep that branch working
by default because I believe it is right.
I'm fine with keeping the text intact. But I've also recommended a user
to challenge a specific test. I'll be applying a fix if the challenge
fails. I guess it might also be accepted if you and Marek get to agree
it may be reasonable not to enforce sending a CT with the empty body at
a test level.
Not a big issue in the end of the day...
Cheers, Sergey
> — 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
>>>>>
>>>>
>>>
>>
>