Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakarta.ee-spec] CDN issues with TCK binaries

Ok, which matches what I see on download, but Joakime showed a download from today that is still seeing an older version, so his cache is out of date by 5 days. I asked for the curl -I output to see where he is being redirected for the actual download.


On Aug 12, 2019, at 3:45 PM, Bill Shannon <bill.shannon@xxxxxxxxxx> wrote:

The correct SHA is here.

I've seen cache delays in the download server that took overnight to resolve.

Scott Stark wrote on 8/12/19 3:33 PM:
On the certification request issue for WebSockets:

I calculate a different SHA256 then Joakin, but he is showing the download coming from the correct URL. I have added my download info and clearly they are different binaries as the sizes do not match. I had seen there be caching issues when working with the CDI TCK, but it as a most a few hours. It has been at least 7 hours between when Joakin downloaded and calculated the SHA256 vs when I did, so there is some significant cache delay somewhere. The curl -I header output indicates data should not be cached for more than 2 hours.

Is there an archived value in the build of this TCK:

In the build job that can be used to verify what the correct SHA256 should be for the websocket-tck?



Back to the top