I'm using a javax.ws.rs.WebApplicationException to trigger a 409 response with a non-empty entity body containing a JAXB-generated Fault type. Something like:

throw new WebApplicationException(
Response.status(Response.Status.CONFLICT)
.entity(fault)
.build());

The resource method is decorated with @Consumes & @Produces listing application/xml, application/yaml and application/json.

The incoming request that causes the 409 condition to fire has both Content-Type and Accept both set to application/xml.

Now for some reason, the Fault instance in the response is being marshalled as yaml, but with the Content-Type of the response left unset, literally as follows:

HTTP/1.1 409 Conflict
Content-Length: 122
Server: Jetty(6.1.23)
— !com.redhat.rhevm.api.model.Fault
detail: "Attempt to set immutable field: id"
reason: Broken immutability constraint

Whereas if I explicitly apply the conneg rules myself, and set the Content-Type of the response to the type specified in the incoming Accept header like so:

throw new WebApplicationException(
Response.status(Response.Status.CONFLICT)
.headers("Content-Type", <type from incoming Accept>)
.entity(fault)
.build());

then all is well again and the response plays out as follows:

HTTP/1.1 409 Conflict
Content-Type: application/xml
Content-Length: 168
Server: Jetty(6.1.23)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<fault>
<reason>Broken immutability constraint</reason>
<detail>Attempt to set immutable field: id</detail>
</fault>

exactly as I expected originally. Does this smell like a bug, as in shouldn't the appropriate content type be applied automatically?