1

I have the below code using which I am trying to fetch and print the request stream's entities using ContainerRequestContext. However, its breaking the API call after I read the input stream. I am able to fetch other details from "ContainerRequestContext" using getters such as responseContext.getURiInfo() etc. Please note I dont want to use "aroundReadFrom" of "ReaderInterceptor" and Lombok anywhere. Any help is appreciated. Thanks !!

UPDATE: The request payload is "x-www-form-urlencoded" and how do I set the request payload back to "x-www-form-urlencoded" after reading it ? It might be the reason why the request fails after I read the payload. I might not be setting the "setEntityStream()" correctly.

public String getRequestEntityStream(ContainerRequestContext requestContext) throws IOException {

        try (InputStream in = requestContext.getEntityStream()) {
            ByteArrayOutputStream out = new ByteArrayOutputStream(64 * 1024);
            IOUtils.copy(in, out);
            byte[] entity = out.toByteArray();
            //restore input
            requestContext.setEntityStream(new ByteArrayInputStream(entity));
            String str=new String(entity);  
            
            return str;
        }
    }

I am using the above as below to append to StringBuilder :

@Override
    public void filter(ContainerRequestContext requestContext) throws IOException {

        StringBuilder sbRequest = new StringBuilder();
        
        sbRequest.append(" - Request Entity Stream : ").append(getRequestEntityStream(requestContext));
    
    }
jane
  • 211
  • 9
  • 30
  • From the code, the problem might be caused by different implementation of InputStream. You might try using the same implementation for setEntityStream and recheck. – Huy Nguyen Apr 08 '23 at 10:24
  • Thanks, The Input stream is "x-www-form-urlencoded " . After reading the payload of the inputStream how to encode it back to "x-www-form-urlencoded " - Thts where i am stuck. – jane Apr 08 '23 at 10:32
  • what is the real implementation? have you tried using wrapper to help to ready body multiple times: https://stackoverflow.com/questions/4449096/how-to-read-request-getinputstream-multiple-times?noredirect=1&lq=1 – Huy Nguyen Apr 08 '23 at 10:46
  • I am using "ContainerRequestContext" to intercept the request payload. I am not using a wrapper here and hence the implementation is not "HttpServletRequestWrapper". – jane Apr 08 '23 at 11:28

1 Answers1

0

The reason you are getting null when trying to fetch the request stream's entities using ContainerRequestContext is that the input stream is being read and consumed when you call IOUtils.copy(in, out).

Once the stream is read, the stream pointer reaches the end of the stream, and there are no more bytes left to read. Hence, when you try to access the request entity stream using requestContext.getEntityStream() after the input stream is read, it returns null.

To fix this issue, you can create a new instance of the ByteArrayInputStream using the entity byte array and set it back to the ContainerRequestContext using requestContext.setEntityStream() before returning the entity string. This will ensure that the request entity stream is reset to its initial state, and you can access it again if needed.

Try this please :

public String getRequestEntityStream(ContainerRequestContext requestContext) throws IOException {

    try (InputStream in = requestContext.getEntityStream()) {
        ByteArrayOutputStream out = new ByteArrayOutputStream(64 * 1024);
        IOUtils.copy(in, out);
        byte[] entity = out.toByteArray();
        
        //reset the input stream
        ByteArrayInputStream inNew = new ByteArrayInputStream(entity);
        requestContext.setEntityStream(inNew);

        String str = new String(entity);
        return str;
    }
}
elgsylvain85
  • 421
  • 4
  • 10
  • 1
    Thanks for your response. Unfortunately It didnt work. Probably I will have to just read the input stream without converting to byteArray. This will ensure that the dataType of Input stream is not messed. – jane Apr 06 '23 at 15:38