jersey
  1. jersey
  2. JERSEY-2498

ByteBufferInputStream violates InputStream definition

    Details

    • Type: Bug Bug
    • Status: Reopened
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.7
    • Fix Version/s: backlog
    • Component/s: core
    • Labels:
      None

      Description

      The ByteBufferInputStream implementation does not properly convert values returned by "ByteBuffer.get()" to integer values. The current implementation converts via numeric cast. The preserves the numeric value and the not bit pattern. Integer conversion should be preformed via a bitwise-and (ie ByteBuffer.read() & 0xFF).

      This is causing problems with binary http response entities when using the Async features of the Jersey HTTP client. In some cases I am seeing bytes within the response body whose value is 0xFF to be silently dropped.

        Issue Links

          Activity

          Hide
          Michal Gajdos added a comment -

          Closing the issue as I understood that there is no data corruption. Feel free to reopen the issue (or make a comment and I'll reopen it) if you have a particular use-case in which you encounter data corruption.

          Show
          Michal Gajdos added a comment - Closing the issue as I understood that there is no data corruption. Feel free to reopen the issue (or make a comment and I'll reopen it) if you have a particular use-case in which you encounter data corruption.
          Hide
          joey_hart added a comment -

          InputStream.read() requires that integer values returned be in the range '-1' to '255'. The current ByteBufferInputStream implementation allows values of the range '-128' to '127' to be returned from ByteBufferInputStream.read().

          This cause problems with some Filtering Input Stream implementations such as GZIPInputStream that expects these values to be returned as specified by InputStream.read().

          Further more there is no way to distinguish between end-of-stream and a -1 (ie 0xFF) in the payload.

          I need to clear it with my company but I do have a use case where I pre-compress an entity using gzip and server that compressed entity with a Content-Type of 'application/octet-stream' to clients. When I use any of the aync http client connectors (grizzly & jetty) I end up losing two bytes of data. Both of which happen to have the value of '0xFF'. In this case my http server delivers 1789 bytes of data but the client only delivers a byte[] of length 1787.

          Show
          joey_hart added a comment - InputStream.read() requires that integer values returned be in the range '-1' to '255'. The current ByteBufferInputStream implementation allows values of the range '-128' to '127' to be returned from ByteBufferInputStream.read(). This cause problems with some Filtering Input Stream implementations such as GZIPInputStream that expects these values to be returned as specified by InputStream.read(). Further more there is no way to distinguish between end-of-stream and a -1 (ie 0xFF) in the payload. I need to clear it with my company but I do have a use case where I pre-compress an entity using gzip and server that compressed entity with a Content-Type of 'application/octet-stream' to clients. When I use any of the aync http client connectors (grizzly & jetty) I end up losing two bytes of data. Both of which happen to have the value of '0xFF'. In this case my http server delivers 1789 bytes of data but the client only delivers a byte[] of length 1787.
          Hide
          joey_hart added a comment -

          I do not have permission to reopen this issue. Can someone please respond to my last comment?

          Show
          joey_hart added a comment - I do not have permission to reopen this issue. Can someone please respond to my last comment?
          Hide
          Michal Gajdos added a comment -

          Reopening. Please, provide a test case if possible.

          Do you use GzipEncoder from Jersey to do the encoding/decoding for you or are you working with GZIPInputStream/GZIPOutputStream directly?

          Show
          Michal Gajdos added a comment - Reopening. Please, provide a test case if possible. Do you use GzipEncoder from Jersey to do the encoding/decoding for you or are you working with GZIPInputStream/GZIPOutputStream directly?
          Hide
          joey_hart added a comment -

          I will work on the test case this weekend and should have something to you by Monday.

          GzipEncoder is not used. The binary response from the Jersey Client is decompressed using GZIPInputStream within my application code. The server is NOT sent the "Accept-Encoding: gzip" header when the GET is issued. As far as the HTTP Server & Jersey is concerned the Entity is just a plain old binary file.

          Show
          joey_hart added a comment - I will work on the test case this weekend and should have something to you by Monday. GzipEncoder is not used. The binary response from the Jersey Client is decompressed using GZIPInputStream within my application code. The server is NOT sent the "Accept-Encoding: gzip" header when the GET is issued. As far as the HTTP Server & Jersey is concerned the Entity is just a plain old binary file.
          Hide
          b_porter added a comment -

          I have run in to this issue, and created a pull request - with unit test.
          https://github.com/jersey/jersey/pull/147

          Show
          b_porter added a comment - I have run in to this issue, and created a pull request - with unit test. https://github.com/jersey/jersey/pull/147

            People

            • Assignee:
              Michal Gajdos
              Reporter:
              joey_hart
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated: