00:36:07qwertyasdfuiopghjkl quits [Remote host closed the connection]
00:36:07Echo quits [Remote host closed the connection]
01:25:34qwertyasdfuiopghjkl (qwertyasdfuiopghjkl) joins
02:40:58pabs quits [Remote host closed the connection]
02:50:50pabs (pabs) joins
03:30:14<@JAA>FWIW, as of 2024-02-01, the SPN truncation limit is still 2 GiB. (Tested using https://web.archive.org/web/20240201052633/https://hobbes.nmsu.edu/archives/hobbes_ftp_11Jan2024.tar )
03:32:10<@JAA>The content-length header does not reflect the truncation, which I guess is good since it should lead to an error in a client unaware of the truncation (which is reported in the 'warning' header).
04:44:08DogsRNice quits [Read error: Connection reset by peer]
07:26:47Echo joins
07:31:09Arcorann (Arcorann) joins
09:39:48Echo70 joins
09:43:32Echo quits [Ping timeout: 265 seconds]
09:57:09SootBector quits [Remote host closed the connection]
09:57:32SootBector (SootBector) joins
10:26:37OrIdow6^2 is now known as OrIdow6
11:02:00igloo22225 quits [Quit: The Lounge - https://thelounge.chat]
11:02:35igloo22225 (igloo22225) joins
12:37:09Arcorann quits [Ping timeout: 272 seconds]
12:48:21<TheTechRobo>It really should just fail the job, should it not?
12:55:26Echo70 quits [Remote host closed the connection]
13:06:19ScenarioPlanet (ScenarioPlanet) joins
13:11:18<OrIdow6>For most files that big 2 GB is going to give at least something that can be meaningfully decoded
13:11:33<OrIdow6>Most files of that size that aren't complete garbage in the first place, that is
13:14:58Echo joins
13:25:31<TheTechRobo>I guess
13:28:46Echo quits [Ping timeout: 265 seconds]
14:35:06SootBector quits [Remote host closed the connection]
14:37:00SootBector (SootBector) joins
14:42:33SootBector quits [Remote host closed the connection]
14:43:00SootBector (SootBector) joins
16:23:19qwertyasdfuiopghjkl quits [Remote host closed the connection]
16:52:48that_lurker quits [Quit: I am most likely running a system update]
16:55:49that_lurker (that_lurker) joins
17:03:14zhongfu_ (zhongfu) joins
17:03:32zhongfu quits [Read error: Connection reset by peer]
17:59:10qwertyasdfuiopghjkl (qwertyasdfuiopghjkl) joins
19:30:56Echo joins
22:16:50clarkk joins
22:21:45<clarkk>What is the long number in a link to an archived page? So, 20240415000000, in https://web.archive.org/web/20240415000000*/www.cnn.com?
22:22:14<@JAA>Timestamp in YYYYMMDDHHMMSS format
22:22:16<clarkk>And is there a way to link directly to the archives for a specific page?
22:22:28<clarkk>JAA, what's it used for?
22:22:42<@JAA>The calendar pages are a bit special though.
22:22:58<clarkk>But 20240415000000 is in the future
22:23:17<clarkk>I just want the link to the latest calendar for the archived page
22:23:35<@JAA>https://web.archive.org/web/*/www.cnn.com should always load the current year's calendar.
22:24:31<@JAA>https://web.archive.org/web/20240415000000/www.cnn.com would redirect to the snapshot of the CNN homepage that's closest to 2024-04-15 00:00:00 UTC.
22:24:43<@JAA>Currently, that's the most recent snapshot, but that'll change in a bit over 2 months.
22:24:59<clarkk>JAA, ah, I see. Using just the asterisk worked a treat. Thank you
22:25:04<@JAA>In the snapshot URLs, the datetime is used for identifying the snapshot.
22:25:32<@JAA>I don't know why they introduced that behaviour with adding a month and day (usually the 15th, I think?) on the calendar URLs.
22:25:57<@JAA>It used to be just the year, I think, and only when you navigated to another year's calendar via the bar thingy.
22:27:10<@JAA>Also, in the prefix search, it'll use the timestamp to narrow down the search.
22:58:08<clarkk>Thanks for the info, JAA
23:05:24Echo quits [Ping timeout: 265 seconds]
23:06:39clarkk quits [Client Quit]