|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.

I think I may have conflated the two issues by combining them into a single bug report. I will drop the incorrect use of gzip and focus on the incorrect chunked encoding.
It is true that 'Transfer-Encoding: chunked' is the way to send a variable length response in HTTP/1.1. It is REQUIRED any time Content-Length: <size> is not set in an HTTP/1.1 response.
That being said, the problem with this HTTP/1.1 response is that it does not set a Content-Length header and thus requires a 'Transfer-Encoding: chunked' header, but it does not chunk encode the body.
The implication of this is that the client may incorrectly interpret the body. This problem was the real root cause of
JENKINS-14050. Resolving that ticket by disabling gzip content encoded responses made the symptom go away without fixing the real bug. Many browsers will fall back to making a best effort at rendering any received bytes when there is a problem with an http response.In the case of
JENKINS-14050the received bytes were gzip content encoded so the invalid chunked body format resulted in trying to render the gzip data directly instead of interpreting the Content-Encoding header and acting appropriately.I did upgrade and find that the monitoring plugin did start working properly. I am now hoping that we may resolve the deeper issue which may cause more odd bugs in the future.