Content-Type is evaluated for 204 No Content

[glassfishrobot]

We consume a REST service using the Jersey client API.
The code we use to execute the GET request is:

MyEntity myEntity = webTarget.request(MediaType.APPLICATION_JSON_TYPE).get(MyEntity.class);

This works well if the response contains an entity (so the return value is not null).
For empty responses we get the following exception:

org.glassfish.jersey.message.internal.MessageBodyProviderNotFoundException: MessageBodyReader not found for media type=text/plain; charset=UTF-8, type=class com.mypkg.MyEntity, genericType=class com.mypkg.MyEntity.

Request/response for the null case are:

1 * Request received on thread main
1 > GET https://rest.test.com/myservice/rest/myentity/unknown
1 > Accept: application/json

2 * Response received on thread main
2 < 204
2 < Date: Thu, 01 Aug 2013 12:05:50 GMT
2 < Content-Length: 0
2 < Keep-Alive: timeout=15, max=100
2 < Connection: Keep-Alive
2 < Content-Type: text/plain; charset=UTF-8
2 < Server: Apache
2 < Cache-Control: max-age=0

As you can see the HTTP status code is 204.
I do not know why, but the Content-Type 'text/plain' is returned.
This seems to be the cause of the exception above.

The behavior I would expect is that the client first evaluates the HTTP status code and only if applicable evaluates the content related stuff.
So as for status 204 the HTTP spec clearly states that there must be no content in the body, the client should ignore all that content stuff (content-type, content-length, etc.).

Right now our work-around is to get the Response object, check the status code ourself and only if not 204 read the entity. It works but is not the way I expected the client API to work.

Environment

JDK 1.6
Jersey 2.0 bundle and Jersey 2.1 bundle

Affected Versions

[2.0, 2.1]

[glassfishrobot]

Reported by fdanek

[glassfishrobot]

mfuksa said:
Which server deployment do you use? I have tried that with Grizzly where response headers are handled correctly. With simple-http container I am able to respond 204 with Content-Type defined.

If the client gets

• status: 204
• Content-Type defined (for example text/plain)
• no entity

and there is no MessageBodyReader the exception is thrown.

This bug consists of two parts: fix the server (to not send the Content-Type when 204 is returned) and fix the client (no to throw the exception when 204 is returned with Content-Type defined but MBR cannot be found). Client cannot be probably done in ReaderInterceptorExecutor as we don't have information about response status.

MBR defines that input stream can be empty and in that case MBR could return an entity which represents an empty entity. So, I would try to execute MBR even the response status is 204. This is not in contradictory to the fact that HTTP spec says that the entity should not be present for 204. But I would not throw an exception because of the missing reader and return null. In my opinion, this should be the solution.

[glassfishrobot]

mfuksa said:
I have added an ignored test to org.glassfish.jersey.tests.e2e.common.NoEntityTest. Please see it when fixing.

[glassfishrobot]

mfuksa said:
I am moving this issue to the backlog. The fix consists of two parts (client and server) described above.

[glassfishrobot]

This issue was imported from java.net JIRA JERSEY-1994