Uploaded image for project: 'JBoss Enterprise Application Platform'
  1. JBoss Enterprise Application Platform
  2. JBEAP-23722

[GSS](7.4.z) UNDERTOW-2241 Undertow write-timeout can cause missing the last zero-length chunk in long polling

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Major Major
    • 7.4.12.CR1, 7.4.12.GA
    • 7.4.5.GA
    • Undertow
    • None
    • False
    • None
    • False
    • ?
    • Hide
      • Set write-timeout longer than long-polling interval, or unset write-timeout. write-timeout is not set by default.
      • Avoid calling flush() from the servlet. If response type is Content-length: <byte>, this error does not occur.
      Show
      Set write-timeout longer than long-polling interval, or unset write-timeout. write-timeout is not set by default. Avoid calling flush() from the servlet. If response type is Content-length: <byte>, this error does not occur.
    • Hide

      This issue can be reproduced in JBoss EAP 7.4.5 as the latest update.

      1. build attachment reproducer by maven

      cd long-polling
      mvn package
      

      2. deploy the application

      cp target/ROOT.war jboss-eap-7.4/standalone/deployments/
      

      3. set write-timeout="5000" in standalone.xml

      <http-listener name="default" socket-binding="http" write-timeout="5000" redirect-socket="https" enable-http2="true"/>
      

      4. start packet capture on loopback by wireshark or tcpdump
      5. access http://127.0.0.1:8080/ with Chrome or Firefox
      6. After 10 seconds, long-polling timeout occurs and a response with missing zero chunks can be seen in pcap. A sample packet capture is attached.

      Show
      This issue can be reproduced in JBoss EAP 7.4.5 as the latest update. 1. build attachment reproducer by maven cd long-polling mvn package 2. deploy the application cp target/ROOT.war jboss-eap-7.4/standalone/deployments/ 3. set write-timeout="5000" in standalone.xml <http-listener name= " default " socket-binding= "http" write-timeout= "5000" redirect-socket= "https" enable-http2= " true " /> 4. start packet capture on loopback by wireshark or tcpdump 5. access http://127.0.0.1:8080/ with Chrome or Firefox 6. After 10 seconds, long-polling timeout occurs and a response with missing zero chunks can be seen in pcap. A sample packet capture is attached.

      Undertow write-timeout can cause closing a connection for a long-polling request without sending the last zero-length chunk like 0\r\n\r\n. This behavior causes a browser-side error, e.g. net::ERR_INCOMPLETE_CHUNKED_ENCODING in Google Chrome.

      In current Undertow implementation of write-timeout, for requests that re-use a keep-alive connection, the write-timeout set during the previous request processing is taken over to the next request. As a result, a zero chunk truncated response is returned if meet the following conditions are true:

      • The request re-use a keep-alive connection.
      • The request takes longer than write-timeout like long-polling processing by AsyncServlet.
      • Transfer-Encoding: chunked is applied to the response by calling flush() in the servlet.

      Even if the write-timeout is reached, it is expected to write the last chunk to the socket before closing a connection.

        1. wireshark.png
          wireshark.png
          227 kB
        2. TraceLastChunk.btm
          0.9 kB
        3. test.pcap
          3 kB
        4. long-polling.zip
          3 kB

              istudens@redhat.com Ivo Studensky
              rhn-support-nagetsum Norito Agetsuma
              Votes:
              0 Vote for this issue
              Watchers:
              14 Start watching this issue

                Created:
                Updated:
                Resolved: