Blocked (queued) connections, keep-alive and content-lengthFeeding the Cloud
<a href="https://creativecommons.org/licenses/by-sa/4.0/">Creative Commons Attribution-ShareAlike 4.0 International License</a>
https://feeding.cloud.geek.nz/posts/blocked-queued-connections-keep-alive/Feeding the Cloudikiwiki2014-11-25T20:14:31ZBrillianthttps://feeding.cloud.geek.nz/posts/blocked-queued-connections-keep-alive/comment_1_1809df2ee8cf6f21be9f15f56446e0a0/Anonyme2013-05-13T21:03:51Z2013-05-13T19:21:44Z
<p>Incorrect Content-Length headers for compressed resources on Keep-Alive connections causes the connection to hang until the timeout expires.</p>
<p>This is exactly what was happening to me--thanks for the writeup.</p>
Same here... and byte order mark issues!https://feeding.cloud.geek.nz/posts/blocked-queued-connections-keep-alive/comment_2_c4a5b5db201b2c6b33f4ec2744b72cd7/Eric Kramer2014-11-25T20:14:31Z2014-11-25T17:06:14Z
I just investigated something similar involving a caching proxy that performed decompression. In my case the Content-Length header was, in many instances, off by three bytes. Further investigation--including identifying the bytes 0xEE 0xBB 0xBF--led me to discover that the Byte Order Mark (BOM) at the head of some of my text files was being stripped away by the proxy...BUT the Content-Length wasn't being downward adjusted by the proxy! So basically clients of the proxy ended up with some content (likely because of a keep-alive between the browser and the caching proxy) that included the first three bytes of the next response! (Usually this was "HTT" at the end of the file... probably part of the "HTTP/1.1 200 OK" response header on the next reply in the stream! This took quite a bit of time to investigate but was quite interesting!