Final input:
if we have
JAX-RS client <-> JAX-RS server
then CT + empty body works (but see a possible side-effect in case of
server bug and the client MBR defaulting to an empty content).
But JAX-RS is not about
JAX-RS client <-> JAX-RS server
it is about
JAX-RS client <-> HTTP server
and
HTTP client <-> JAX-RS server
i.e, IMHO there should be no enforcing CT + empty body based on a
possible expectation that a JAX-RS consumer is listening on the other
end...CT + empty body is not nice HTTP and is not something that a
producer can depend upon as a way to do some application specific flows
Sergey
On 29/04/15 17:23, Sergey Beryozkin wrote:
> 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
>>>>>>
>>>>>
>>>>
>>>
>>
>