|
Today I ran across a problem with our office jenkins server. When I tried to go to /monitoring I was greeted with a page full of gibberish which matches JENKINS-14050. I looked at the traffic using charles proxy and I discovered that the Content-Encoding: gzip was not playing nice with the incorrect Transfer-Encoding: chunked implementation.
I have resolved my issue with /monitoring by disabling gzip encoding. I did this by adding "RequestHeader unset Accept-Encoding" to the Apache proxy that sits in front of my jenkins server. This is functional enough, but it does not address the core issue.
My Jenkins server is running with the default Winstone servlet engine as packaged for RHEL5. It responds with HTTP/1.1, Connection: close, and Transfer-Encoding: chunked. It then sends data in HTTP/1.0 mode where it closes the connection when done and does no chunked encoding. Adding Content-Encoding: gzip to this broken Transfer-Encoding mode reproduced the broken behavior documented in JENKINS-14050.
I updated another jenkins server to the latest (1.503) and upgraded the monitoring plugin to its newest version and I still see the incorrect Transfer-Encoding.
A proper chunked encoding should prefix every chunk with the chunk length in hex and append a CRLF after the chunk.
"<chunklen as hex>\r\n\r\n<chunkdata>\r\n"
After the final chunk an empty chunk is sent to signal the end of the chunk encoded response.
"0\r\n\r\n"
Another place where superfluous headers are being sent is /ajaxExecutors and /ajaxBuildQueue. Both of these set Content-Encoding: gzip while not gzipping the content.
|
