Uploaded image for project: 'Undertow'
  1. Undertow
  2. UNDERTOW-2604

2.3.19 regression w/ Java's HTTP client

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Blocker Blocker
    • 2.2.38.Final, 2.3.20.Final
    • 2.3.19.Final
    • Core
    • None
    • Hide

      (non-isolated) Reproducer:

      1. Clone the repository
      2. Run ./gradlew :nessie-client:test (Java 21 required) - tests are passing w/ Undertow 2.3.18
      3. Checkout this Renovate branch
      4. Run ./gradlew :nessie-client:test - test using the Java HTTP client are failing w/ Undertow 2.3.19

      Alternatively, run/debug the test class directly from IntelliJ.
      Additional Gradle args to run the Java 11 HTTP client test only: -tests TestJavaHttpClient (alternatively for the HttpURLConnection based client: -tests TestHttpUrlConnectionClient).

      Show
      (non-isolated) Reproducer: Clone the repository Run ./gradlew :nessie-client:test (Java 21 required) - tests are passing w/ Undertow 2.3.18 Checkout this Renovate branch Run ./gradlew :nessie-client:test - test using the Java HTTP client are failing w/ Undertow 2.3.19 Alternatively, run/debug the test class directly from IntelliJ. Additional Gradle args to run the Java 11 HTTP client test only: - tests TestJavaHttpClient (alternatively for the HttpURLConnection based client: -tests TestHttpUrlConnectionClient ).

      We have encountered a CI failure with the bump of Undertow from 2.3.18 to 2.3.19 via this Renovate PR., which seems related to changes to compressed and/or chunked request body handling.

      Background: In Nessie, we have 3 different HTTP clients:

      • for the "good old" Java HttpURLConnection
      • for the "new Java 11" HttpClient
      • for the Apache HTTP client

      There's a common BaseTestHttpClient with implementations for each of those. Only the one for the Java 11 HttpClient fails w/ Undertow 2.3.19.

      One of the test cases performs POST+PUT  requests with large-ish request bodies (large enough to "trigger" compression) in all 8 possible combinations of with(out) gzip compression, http2-upgrade, ssl. The ones that use with gzip compression fail for 2.3.19, but only for the Java 11 based implementation.

      Our clients include the follwing HTTP headers for requests using compression

      Accept: application/json; charset=utf-8
Accept-Encoding: gzip;q=1.0, deflate;q=0.9
Content-Encoding: gzip
Content-Type: application/json; charset=utf-8

      Both the HttpURLConnection and the Java-11 HttpClient based implementations share a common code path for preparing the request and wrapping the request body output stream with a GZIPOutputStream.

       

      The exceptions within the server-side request handler are like this, thrown at this line:

      Caused by: java.io.IOException: java.util.zip.DataFormatException: invalid stored block lengths
    at io.undertow.conduits.InflatingStreamSourceConduit.read(InflatingStreamSourceConduit.java:208)
    at org.xnio.conduits.ConduitStreamSourceChannel.read(ConduitStreamSourceChannel.java:127)
    at io.undertow.channels.DetachableStreamSourceChannel.read(DetachableStreamSourceChannel.java:206)
    at io.undertow.server.HttpServerExchange$ReadDispatchChannel.read(HttpServerExchange.java:2480)
    at org.xnio.channels.Channels.readBlocking(Channels.java:344)
    at io.undertow.servlet.spec.ServletInputStreamImpl.readIntoBuffer(ServletInputStreamImpl.java:201)
    at io.undertow.servlet.spec.ServletInputStreamImpl.read(ServletInputStreamImpl.java:176)
    at com.google.common.io.CountingInputStream.read(CountingInputStream.java:63)
    at com.fasterxml.jackson.core.json.UTF8StreamJsonParser._loadMore(UTF8StreamJsonParser.java:220)
    at com.fasterxml.jackson.core.json.UTF8StreamJsonParser._loadMoreGuaranteed(UTF8StreamJsonParser.java:2457)
    at com.fasterxml.jackson.core.json.UTF8StreamJsonParser._finishString2(UTF8StreamJsonParser.java:2540)
    at com.fasterxml.jackson.core.json.UTF8StreamJsonParser._finishAndReturnString(UTF8StreamJsonParser.java:2520)
    at com.fasterxml.jackson.core.json.UTF8StreamJsonParser.getText(UTF8StreamJsonParser.java:294)
    at com.fasterxml.jackson.core.json.UTF8StreamJsonParser.nextTextValue(UTF8StreamJsonParser.java:1304)
    at com.fasterxml.jackson.databind.deser.std.StringCollectionDeserializer.deserialize(StringCollectionDeserializer.java:203)
    ... 43 more
Caused by: java.util.zip.DataFormatException: invalid stored block lengths
    at java.base/java.util.zip.Inflater.inflateBytesBytes(Native Method)
    at java.base/java.util.zip.Inflater.inflate(Inflater.java:376)
    at io.undertow.conduits.InflatingStreamSourceConduit.read(InflatingStreamSourceConduit.java:191)
    ... 57 more

       

              flaviarnn Flavia Rainone
              snazy Robert Stupp (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                Resolved: