-
Bug
-
Resolution: Done
-
Blocker
-
7.4.12.CR2
-
None
-
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?
- clones
-
JBEAP-25163 Server responds with chunked transfer even for short data from deployment
- Closed
- is caused by
-
UNDERTOW-2243 Eager flush/close on content length response prevents POST from finishing
- Closed
- is incorporated by
-
JBEAP-25204 [GSS](7.4.z) Upgrade Undertow from 2.2.25.SP2-redhat-00001 to 2.2.25.SP3
- Closed
- relates to
-
JBEAP-25164 Server responds with chunked transfer even if client starts communication with HTTP/1.0
- Closed