-
Bug
-
Resolution: Done
-
Blocker
-
8.0.0.Beta-CR1
-
False
-
None
-
False
-
-
-
-
-
-
+
-
-
-
To be honest - I'm not sure how much this is a bug or not. What I see is a change in server behavior after this commit in the Undertow component. It was introduced as a fix for UNDERTOW-2243.
What changed. Before this commit, our testing scenario for gzip filter received data with the regular "fixed-length" response from the server (Content-Length) header used (see gzip-content-length.png and gzip-content-length.pcapng). After this commit, server decide to use chunked transfer for the data without using the Content-Length header (see gzip-chunked.png and gzip-chunked.pcapng). Technically this may not be any problem, but this change means more ping-pongs between server and client. So I'm a bit worried that this may affect Undertow performance.
Is this change of behavior expected?
- is caused by
-
UNDERTOW-2243 Eager flush/close on content length response prevents POST from finishing
- Closed
- is cloned by
-
JBEAP-25198 [QE](7.4.z) Server responds with chunked transfer even for short data from deployment
- Closed
-
UNDERTOW-2293 Server responds with chunked transfer even for short data from deployment
- Closed
- is incorporated by
-
JBEAP-25695 Upgrade undertow from 2.3.7.SP1-redhat-00001 to 2.3.7.SP2-redhat-x
- Closed
- relates to
-
JBEAP-25164 Server responds with chunked transfer even if client starts communication with HTTP/1.0
- Closed