users@jax-rs-spec.java.net

[jax-rs-spec users] [jsr339-experts] Re: Re: _at_Consumes matching when Content-Type is null

From: Marek Potociar <marek.potociar_at_oracle.com>
Date: Thu, 23 May 2013 19:47:27 +0200

On May 23, 2013, at 7:34 PM, Bill Burke <bburke_at_redhat.com> wrote:

>
>
> On 5/23/2013 11:00 AM, Marek Potociar wrote:
>>
>> On May 22, 2013, at 9:56 PM, Bill Burke <bburke_at_redhat.com> wrote:
>>
>>>
>>> @Consumes("text/plain")
>>> @POST
>>> @Path("plain")
>>> public void tckPOST();
>>>
>>> @Path("start")
>>> @POST
>>> public void start()
>>>
>>> @Path("start")
>>> @POST
>>> @Consumes("application/xml")
>>> public void start(XML xml)
>>>
>>>
>>> I have 2 different test cases whose solutions currently conflict.
>>>
>>>
>>> Case #1:
>>>
>>> The TCK is posting a NULL entity with no Content-Type header to:
>>>
>>> POST /plain
>>>
>>> The TCK is expecting this to match tckPOST() even though two different sections of the spec conflict:
>>>
>>> - Section 4.2.1.1 Says that if the request does not contain a Content-Type, then application/octet-stream is used. This is for matching bodies though.
>>
>> Yes, I think that one should not apply to requests without a body.
>>
>>>
>>> - The matching algorithm in Step 3(a) says:
>>>
>>> "The media type of the request entity body *(if any)* is supported by the input format"
>>>
>>> What does *if any* mean? The TCK seems to assume that if the Content-Type header is null, then the @Consumes annotation is ignored. Or am I supposed to look at the method to see if it is expecting a request body?
>>
>> I guess that's the correct interpretation. FWIW, the whole test is good in that it uncovers these hidden portability issues, but I would in this case even support removing the test as it is testing a completely artificial use case.
>>
>
> Only real way to test for a body is to either a) check the Content-Type header is null or b) check the resource method to see if it expects a body. So the 2 start() methods would be ambiguous so I'm free to match them however I see fit. This is another user posted use case where they want a no-param start() method to match if there is no content.

What about checking Content-Length and/or trying to read from an entity input stream?

Marek

>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com