Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[JENKINS-72469] Avoid repeated tool downloads from misconfigured HTTP…
… servers (jenkinsci#8814) * [JENKINS-72469] Avoid repeated tool downloads from misconfigured HTTP servers The Azul Systems content delivery network stopped providing the last-modified header in their URL responses. They only provide the ETag header. Add ETag support to the Jenkins FilePath URL download method so that if ETag is provided, we use the ETag value. If last-modified is provided and matches, we continue to honor it as well. https://issues.jenkins.io/browse/JENKINS-72469 has more details. https://community.jenkins.io/t/job-stuck-on-unpacking-global-jdk-tool/11272 also includes more details. Testing done * Automated test added to FilePathTest for code changes on the controller. The automated test confirms that even without a last-modified value, the later downloads are skipped if a matching ETag is received. The automated test also confirms that download is skipped if OK is received with a matching ETag. No automated test was added to confirm download on the agent because that path is not tested by any of the other test automation of this class. * Interactive test with the Azul Systems JDK installer on the controller. I created a tool installer for the Azul JDK. I verified that before this change it was downloaded each time the job was run. I verified that after the change it was downloaded only once. * Interactive test with the Azul Systems JDK installer on an agent. I created a tool installer for the Azul JDK. I verified that before this change it was downloaded each time the job was run. I verified that after the change it was downloaded only once. * Interactive test on the controller with a file download from an NGINX web server confirmed that the tool is downloaded once and then later runs of the job did not download the file again. * Use equals instead of contains to check ETag Don't risk that a substring of an earlier ETag might cause a later ETag to incorrectly assume it does not need to download a modified installer. * Use weak comparison for ETag values https://httpwg.org/specs/rfc9110.html#field.etag describes weak comparison cases and notes that content providers may provide weak or strong entity tags. Updated code to correctly compare weak and strong entity tags. Also improves the null checks based on the suggestions from @mawinter69 in jenkinsci#8814 (comment) * Test comparison of weak and strong validators * Do not duplicate test args, more readable * Use better variable names in test Cover more branches in the equalEtags method as well * Fix variable declaration order (cherry picked from commit c8156d4)
- Loading branch information