Not sure if it will make a difference - but I've introduced this
optimization (no Conetnt-Type if no entity body) few releases back based
on number of people complaining CXF sending Content-Type alongside an
empty body. One user has reported an issue that doing so broke his CXF
application to a legacy consumer.
I know JAX-RS is capable of processing empty payloads. But enforcing the
runtimes do it can only make it worse IMHO.
Consider the client code which reads some payload. If we have a broken
server code missing setting an entity then the client can get a default
response representation as per the JAX-RS spec and assume that was an
actual response. Instead of getting a fault. That is not good.
I agree the runtime should be able to deal with the empty payloads
accompanied by content types.
But I disagree the runtime should be enforced to send Content-Type with
empty payloads
Sergey
On 29/04/15 16:31, Sergey Beryozkin 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.
>
> See what I mean ?
>
> Sergey
>
>
>
> 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
>>>>
>>>
>>
>