Hi, is the best I can hope for is a possible comment in few months or so
? Come on, lets make this list alive, is it where one the most
interesting JSRs is supposed to be discussed, even when no formal
process is under way ?
Sergey
On 20/01/14 11:53, Sergey Beryozkin wrote:
> By the way, here is why I asked.
>
> A project depending on Apache CXF has a root resource like this one:
>
> @Path("root")
> public class Root {
>
> @Consumes("*/*")
> @PUT
> public Response process(InputStream is) {
> // auto-detect a stream content type by reading into IS if needed
> and parse it
>
> }
> }
>
> where the content is submitted with a "curl -T" command which, note,
> does not set Content-Type in the request.
>
> And all has worked fine before a new method has been added:
>
> @Path("root")
> public class Root {
>
> @Consumes("*/*")
> @PUT
> public Response process(InputStream is) {
> // auto-detect a stream content type by reading into IS if needed
> and parse it
>
> }
>
> @Consumes("multipart/form-data")
> @PUT
> public Response processForm(SomeMultipartPart part) {
> // extract the attachments and deal with them
> }
> }
>
> what happens, now that JAX-RS 2.0 clearly specifies how to choose
> between multiple resource method candidates listening on the same path,
> is that "processForm" is selected when "curl -T" is used due to the
> latter setting no Content-Type.
>
> Next, when reading SomeMultipartPart, Content-Type (as per the spec) is
> set to application/octet-stream, and the multipart provider fails to
> recognize it and the processing fails.
>
> Now, if the spec said "If CT is not available then set it to
> application/octet-stream before the method selection is done" then
> adding the new processForm() method would have no negative side-effect,
> the original process() would've been selected and things would work as
> usual.
>
> Now the easy fix if for the client to add Content-Type - this is
> reasonable but in the above case I know people have written their
> scripts/tests to use "curl -T" without setting a CT which worked fine
> due to the auto-detection logic of the server.
>
> Effectively after migrating to JAX-RS 2.0 aware Apache CXF they now face
> a minor backward-compatibility issue.
>
> I'm perfectly OK with accepting it is a CXF bug but as I said below I
> quite firmly believe the defaulting to application/octet-stream is
> delayed in CXF till the moment the stream is read due to TCK failures.
>
> As such I'd like to treat it as a JAX-RS 2.0 spec text bug, and would
> like to propose to fix it for 2.1.
>
> Any comments ? When does Jersey or RestEasy default to
> application/octet-stream if no CT is specified in the request ?
>
> Thanks, Sergey
>
> On 19/01/14 18:52, Sergey Beryozkin wrote:
>> Hi
>>
>> According to the spec, if no Content-Type is specified in the request
>> then it has to be defaulted to application/octet-stream, this is
>> mentioned in the section describing how MBR can be found for mapping the
>> stream into a given Java type.
>>
>> My question is, should this 'no CT to application/octet-stream
>> defaulting' take place earlier, when the method selection takes place ?
>>
>> I think I did try to do it earlier initially but saw CXF failing a
>> couple of early TCK tests as a result.
>>
>> So what CXF does now is this: if no CT is available - set it to '*/*'
>> and do the method selection. Next, when the method selection is done,
>> and when MBR is checked, it is set to application/octet-stream.
>>
>> I think this is wrong, but I said I believe it was TCK failures which
>> forced me to do it.
>>
>> Can someone please confirm the above algorithm is correct or should we
>> actually have a 2.1 JIRA issue clarifying that when no CT is available
>> then set it to application/octet-stream before the resource methods are
>> selected ?
>>
>>
>> Thanks, Sergey
>>
>