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.
>
> Which brings me to Case #2:
>
> User has the start() methods above. The request is:
>
> POST /start - no content-type
>
> Is this an ambiguous mapping since any @Consumes would be ignored because there is no Content-Type header? Or is Content-Type supposed to default to application/octet-stream? Or, am I supposed to introspect the method to see if it is expecting a body?
I think an important piece of information missing here is if the request contains body.
Marek
>
>
>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com