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

ajp connection hangs if a post HTTP request header contains 'Transfer-Encoding: chunked'

XMLWordPrintable

    • Hide

      PREPERATION

      1. install Apache HTTP server 2.2.22 and config the mod_jk to route servlet request through ajp:9009
      2. used the attached standalone.xml
      3. deploy the attached service.war.
      4. Install CURL cli utility.

      STEPS:
      Run the command:

      curl -v -X POST  --header "Transfer-Encoding: chunked"   --header "Content-Type:appliation/octet-stream" http://localhost/service-1.0-SNAPSHOT/servlets/ContentSize -d @CURLS.txt

      EXPECTED:

      Note: Unnecessary use of -X or --request, POST is already inferred.
*   Trying ::1...
*   Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 8080 (#0)
> POST /service-1.0-SNAPSHOT/servlets/ContentSize HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/7.49.1
> Accept: */*
> Transfer-Encoding: chunked
> Content-Type:appliation/octet-stream
> Expect: 100-continue
>
* Done waiting for 100-continue
< HTTP/1.1 200 OK
< Connection: keep-alive
< X-Powered-By: Undertow/1
< Server: WildFly/10
< Content-Length: 30
< Date: Fri, 03 Jun 2016 18:21:30 GMT
<
<html> file size: 1561 </html>* Connection #0 to host localhost left intact

      ACTUAL

      Note: Unnecessary use of -X or --request, POST is already inferred.
*   Trying 10.4.18.179...
* Connected to river-v702 (10.4.18.179) port 80 (#0)
> POST /service-1.0-SNAPSHOT/servlets/ContentSize HTTP/1.1
> Host: river-v702
> User-Agent: curl/7.49.1
> Accept: */*
> Transfer-Encoding: chunked
> Content-Type:appliation/octet-stream
> Expect: 100-continue
>
< HTTP/1.1 100 Continue

      The curl command will not return until a CTRL-C is issued.

      If we append the :8080 to the url, the expected result is returned from server.

      Show
      PREPERATION install Apache HTTP server 2.2.22 and config the mod_jk to route servlet request through ajp:9009 used the attached standalone.xml deploy the attached service.war. Install CURL cli utility. STEPS: Run the command: curl -v -X POST --header "Transfer-Encoding: chunked" --header "Content-Type:appliation/octet-stream" http://localhost/service-1.0-SNAPSHOT/servlets/ContentSize -d @CURLS.txt EXPECTED: Note: Unnecessary use of -X or --request, POST is already inferred. * Trying ::1... * Trying 127.0.0.1... * Connected to localhost (127.0.0.1) port 8080 (#0) > POST /service-1.0-SNAPSHOT/servlets/ContentSize HTTP/1.1 > Host: localhost:8080 > User-Agent: curl/7.49.1 > Accept: */* > Transfer-Encoding: chunked > Content-Type:appliation/octet-stream > Expect: 100-continue > * Done waiting for 100-continue < HTTP/1.1 200 OK < Connection: keep-alive < X-Powered-By: Undertow/1 < Server: WildFly/10 < Content-Length: 30 < Date: Fri, 03 Jun 2016 18:21:30 GMT < <html> file size: 1561 </html>* Connection #0 to host localhost left intact ACTUAL Note: Unnecessary use of -X or --request, POST is already inferred. * Trying 10.4.18.179... * Connected to river-v702 (10.4.18.179) port 80 (#0) > POST /service-1.0-SNAPSHOT/servlets/ContentSize HTTP/1.1 > Host: river-v702 > User-Agent: curl/7.49.1 > Accept: */* > Transfer-Encoding: chunked > Content-Type:appliation/octet-stream > Expect: 100-continue > < HTTP/1.1 100 Continue The curl command will not return until a CTRL-C is issued. If we append the :8080 to the url, the expected result is returned from server.
    • Compatibility/Configuration, User Experience

      When upgrading from JBOSS 7 to WILDFLY10, we observed following behavior:
      if an HTTP post contains 'Transfer-Encoding: chunked' and 'Content-Type:appliation/octet-stream' in its head, A servlet which handles it will hang for ever ( until the client drop the connection) if it calls HttpServletRequest.getInputStream() and tries to read the whole content of the returned InputStream. The InputStream's read() method will block for ever at the end of the stream as opposed to return -1.

      It only happens when the request is routed by apache web server through ajp; it does not happen if the client talks to wildfly directly through its 8080 http port.

      We have attached a minimal web application that reproduce this issue.
      Also attached is the standalone.xml and the apache configuration file.

              sdouglas1@redhat.com Stuart Douglas (Inactive)
              river.shen river shen (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                Resolved: