happy to be sending few mails to the temporarily quiet list :-),
https://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-26#section-3.1:
"When a message includes a payload body..."
Sergey
On 29/04/15 16:39, Sergey Beryozkin wrote:
> 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
>>>>>
>>>>
>>>
>>
>