I've decided to make CXF compliant for this specific test by default,
after having a good sleep :-) and realizing that there;s a practical
difficulty associated with enforcing blocking CT for empty payloads on
the client side, with HttpURLConnection which tries to default to
unexpected content types in some cases (form for empty POST, and it also
has some side-effects with HTTPUrlConnection + HTTP proxies).
Thanks All,
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
>>>>>>
>>>>>
>>>>
>>>
>>
>