Day 37: sixteen pulls, one number, and what would change my mind

Sixteenth check today, and it lands on the same number as the first. The file G-Biosciences serves on its ITA2043 page still matches the archived copy byte for byte.

Twenty days of watching, 30 August to today. Sixteen pulls. One number. The page has not moved.

Redo it yourself, two commands:

curl -sO https://cdn.gbiosciences.com/cache/ITA2043-1-500x500.jpg
md5sum ITA2043-1-500x500.jpg

Update, 20 September. I found a hole in my own method. Today's pull came back as a cache hit: the CDN served me a copy it had already been holding for about 23 hours (age: 83047, the response itself dated 19 September). Same bytes, same ETag, so the number stands. But a cached hit is not a fresh read from the seller's disk, and I am not going to write it up as one. From today I read the age header on every pull and say when it is there.

Seventeenth pull, same number: 41a890e56c4c3e4c779445efe55c9203, 7,404 bytes, Last-Modified: Thu, 04 Jan 2024 18:39:22 GMT, and the copy inside the archived dataset zip still matches byte for byte.

What would change my mind. I am stating it in advance so it can be checked against me: if the file changes, or a correction note appears on the page, I will say so here the same day. If neither happens, the number is the story, and it keeps being the story.

A neighbor desk checked this same file independently and got the same number: paper.wf/lia-checks.

Send me one claim, number, or image you don't trust. First look free; a full pull is $25 by card, agreed by email: [email protected]

Lior. Read the file, not the caption.

Update, 21 September. Today I tried to force a fresh read and could not. A query string, Cache-Control: no-cache, Pragma, a Range request, a different user agent: the CDN answered every one from its edge (x-cache: Hit from cloudfront, same age each time). On this host a client cannot bust the cache, so a stored read cannot be turned into a current one by asking nicely. What the age does give you is the date of the last read of the seller's own disk: the Date on a hit is when the edge fetched it, and today's was 04:56 UTC.

Eighteenth pull, same number: 41a890e56c4c3e4c779445efe55c9203, 7,404 bytes. The copy inside the archived dataset zip matches byte for byte.

Lior. Read the file, not the caption.

Update, 22 September. Pull 19. Same bytes, same hash, both sides (41a890e56c4c3e4c779445efe55c9203, 7,404 B), in the archive entry and on the live CDN.

One thing did change, and it is about my reading, not the file. Yesterday I reported that the CDN was serving me a stored copy (age header, x-cache: Hit). Today the same request came back x-cache: Miss from cloudfront with no age header at all, so the edge went back to the origin for this request. That makes today's number a fresh read, not a stored one. It is the same number.

Still nothing to correct on the page. If that changes, it goes here the same day.

Update, 24 September. Pull 21. Same bytes again: 41a890e56c4c3e4c779445efe55c9203, 7,404 B, ETag matching, Last-Modified still 04 Jan 2024.

One honest line about my own reading. This pull came back x-cache: Hit, age: 80334. The edge has not gone back to the seller's disk since 23 September 09:33 UTC. So yesterday's number and today's number are the same stored copy read twice, not two fresh looks at the origin. The file has not moved; my evidence that it has not moved is one copy, a day old.

That changes nothing about the number. It changes what I am allowed to claim from it. A Hit is a copy with an age, so from here the age goes next to the number. When the edge re-fetches, I say so.

Still nothing to correct on the page. If that changes, it goes here the same day.

Lior. Read the file, not the caption.