I didn’t write anything about Oracle. The download only occurs once per initial installation and for my single controller, running for a few years now, that should only be when i update to a newer JDK. So this will never cause any excessive bandwidth from my instance. This bug has certainly caused excessive bandwidth…
However, you did point me into a good direction of hosting it my self, which should remedy the situation.
Nevertheless, this is still an issue, as i can download the file from the URL, Jenkins can do it too, but it simply doesn’t accept that the files are there, as it doesn’t write that special file, indicating the download is complete. The installation is just fine, as after a download, the rest of the job runs just fine.
I would highly appreciate it, if this issue was fixed, even if i did use it in an ill-advised manner, since it used to work and there is no reason why it shouldn’t work.
I’ve submitted a bug report / enhancement request asking that Jenkins core support the ETag HTTP header in addition to the last-modified HTTP header.
It is surprising that the Azul content delivery network has stopped providing the last-modified header. Other providers continue to send the last-modified HTTP header. Customers of Azul Systems that are Jenkins users might consider raising an issue with Azul Systems to let them know that the removal of the last-modified HTTP header has increased the use of their bandwidth.
I’ve submitted a pull request that adds ETag support to the Jenkins tool downloader. I continue to believe that it is unexpected to have an HTTP server that provides ETag headers and does not provide last-modified headers, but since we’ve seen an issue with one HTTP server configured that way, we can expect there are others configured that way as well.