You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After this pr jersey is no longer handling correctly any override of HttpServletRequest which does not return always the same input stream when invoking getInputStream.
Context about different implementation of ServletRequest#getInputStream
The servlet api does not seem to specify wether or not it is required for an implementation to always return the same input stream across multiple invocations and it therefore seems valid in some cases to override this method in an HttpServletRequestWrapper returning a new copy of the input stream for any invocation (to be able to consume the input stream multiple times). This is showcased for example in this stack overflow answer about how a servlet input stream could be consumed multiple times.
Current issue
With the aforementioned change the InputStreamWrapper will invoke the underlying ServletRequest#getInputStream whenever any operation is performed to the request input stream. This can cause the input stream to be read forever as invocations to InputStreamWrapper#available will create a new input stream every time that this has not yet been consumed.
How to reproduce this issue
When overriding the http servlet request in a servlet filter with a request such as the one showed in the previous stack overflow answer no jersey invocation to an endpoint consuming json seems to work.
Possible solutions
This use case seems quiet valid also considering that HttpServletRequest does not expose anywhere in its api a way to override the input stream and therefore allow for more easy input replayability. I therefore wondered if this could be fixed/supported by having InputStreamWrapper caching the result of InputStreamWrapper#getWrapped after it is invoked the first time?
The text was updated successfully, but these errors were encountered:
After this pr jersey is no longer handling correctly any override of
HttpServletRequest
which does not return always the same input stream when invokinggetInputStream
.Context about different implementation of ServletRequest#getInputStream
The servlet api does not seem to specify wether or not it is required for an implementation to always return the same input stream across multiple invocations and it therefore seems valid in some cases to override this method in an
HttpServletRequestWrapper
returning a new copy of the input stream for any invocation (to be able to consume the input stream multiple times). This is showcased for example in this stack overflow answer about how a servlet input stream could be consumed multiple times.Current issue
With the aforementioned change the
InputStreamWrapper
will invoke the underlyingServletRequest#getInputStream
whenever any operation is performed to the request input stream. This can cause the input stream to be read forever as invocations toInputStreamWrapper#available
will create a new input stream every time that this has not yet been consumed.How to reproduce this issue
When overriding the http servlet request in a servlet filter with a request such as the one showed in the previous stack overflow answer no jersey invocation to an endpoint consuming json seems to work.
Possible solutions
This use case seems quiet valid also considering that
HttpServletRequest
does not expose anywhere in its api a way to override the input stream and therefore allow for more easy input replayability. I therefore wondered if this could be fixed/supported by havingInputStreamWrapper
caching the result ofInputStreamWrapper#getWrapped
after it is invoked the first time?The text was updated successfully, but these errors were encountered: