Sean, can you sent example of your end-point and client part? I tried to use this endpoint and client. It works as I expected. Any NPE is thrown:

@GET
@Path("nothing")
@Produces("application/octet-stream")
public InputStream nothing() {
    if (true) {
        throw new WebApplicationException(304);
    }
    return new ByteArrayInputStream("hello".getBytes());
}

-----------------------------------------------------------------------------------

Response response = client.target(generateURL("/nothing")).request().get();
int code = response.getStatus();
if (code == 200) {
    InputStream is = response.readEntity(InputStream.class);
    Assert.assertEquals("hello", TestUtil.readString(is));
}
if (code == 304) {
    try {
        response.readEntity(InputStream.class);
        Assert.fail("ProcessingException was not thrown");
    } catch (ProcessingException e) {
        // expected exception
    }
}
response.close();

But I found some performance issue with 304. If I use this end-point:

@GET
@Path("nothing")
public Response nothing()
{
   return Response.status(304).entity("test").build();
}

In WildFly, body is erased in Undertow (AFAIK), but RESTEasy could do this too. Check for 304 can be implemented here: https://github.com/resteasy/Resteasy/blob/master/resteasy-jaxrs/src/main/java/org/jboss/resteasy/core/ServerResponseWriter.java#L50 Now, interceptors are applied to these kinds of responses. This is not necessary and it may not be optimal for performance. Alessio, Ron, WDYT? Marek -------- Forwarded Message --------

Subject:	[Resteasy-developers] Proper handling of NotModified/304
Date:	Fri, 10 Jun 2016 10:50:03 -0400
From:	Sean Dawson <sean.dawson2014@gmail.com>
To:	resteasy-devel. <resteasy-developers@lists.sourceforge.net>