[resteasy-dev] Fwd: [Resteasy-developers] Proper handling of NotModified/304

[Marek Kopecky]

Hi.

The mailing-list on sourceforge 
(resteasy-developers at lists.sourceforge.net) has been deprecated. 
Forwarding to correct mailing list ( resteasy-dev at lists.jboss.org ).

Yes, "A 304 response cannot contain a message-body", see 
https://tools.ietf.org/html/rfc7232#section-4.1

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 at gmail.com>
To: 	resteasy-devel. <resteasy-developers at lists.sourceforge.net>

I posted this on users but I'm thinking it's a RestEasy bug at this point.
The code seems to buffer the entity and then throw a processing 
exception if the status is bad.
In the case of 304, no body is provided (and this seems to be correct 
according to the standard).  I have found no way server side to return 
anything but null as the entity.  So attempting to buffer it on a 304 
just seems plain incorrect (and results in an NPE).
Am I missing something?
Setting the custom header on the response does work - but I'm not sure 
that'll make it back to the client when it passes through servers that 
usually strip those out.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/resteasy-dev/attachments/20160614/40deb221/attachment.html 
-------------- next part --------------
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
-------------- next part --------------
_______________________________________________
Resteasy-developers mailing list
Resteasy-developers at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/resteasy-developers