01:26:14 | | Jake (Jake) joins |
01:38:59 | | nyakase (nyakase) joins |
01:41:12 | | HP_Archivist (HP_Archivist) joins |
01:50:05 | <nicolas17> | 7404/8695 [3:24:25<33:10, 1.54s/MiB] |
02:10:03 | <nicolas17> | 185/8579 [08:25<23:39:18, 10.15s/MiB] ok wtf |
03:59:19 | | pabs quits [Read error: Connection reset by peer] |
04:00:05 | | pabs (pabs) joins |
07:44:12 | | qwertyasdfuiopghjkl2 quits [Ping timeout: 260 seconds] |
08:22:08 | | BornOn420_ quits [Ping timeout: 276 seconds] |
08:34:38 | | BornOn420 (BornOn420) joins |
10:03:14 | | Dango360 quits [Read error: Connection reset by peer] |
10:41:52 | | BornOn420 quits [Ping timeout: 276 seconds] |
11:37:27 | | nicolas17 quits [Ping timeout: 265 seconds] |
11:40:47 | | nicolas17 joins |
14:13:58 | | Dango360 (Dango360) joins |
16:23:22 | | pabs quits [Ping timeout: 260 seconds] |
16:24:13 | | pabs (pabs) joins |
16:40:10 | | MrMcNuggets (MrMcNuggets) joins |
16:55:29 | | BornOn420 (BornOn420) joins |
17:14:26 | | MrMcNuggets quits [Client Quit] |
19:04:27 | <nicolas17> | https://web.archive.org/web/20241211183425/https://updates.cdn-apple.com/2024FallFCS/fullrestores/072-41951/5790575D-5E1C-472E-8CC2-86E297A25AFD/UniversalMac_15.2_24C2101_Restore.ipsw https://web.archive.org/web/20241211193512/https://updates.cdn-apple.com/2024FallFCS/fullrestores/072-41951/5790575D-5E1C-472E-8CC2-86E297A25AFD/UniversalMac_15.2_24C2101_Restore.ipsw these two captures are returning HTTP 504, even to HEAD |
19:37:20 | <@JAA> | The WBM seems pretty sad today, so that might not mean anything about the captures. |
19:38:12 | <nicolas17> | ah okay |
19:38:18 | <nicolas17> | the first of those eventually worked |
19:38:44 | <nicolas17> | and I think it was my AB capture, which makes me extra curious about what the second one is |
19:58:02 | | pabs quits [Ping timeout: 260 seconds] |
19:59:33 | | pabs (pabs) joins |
20:32:12 | | DogsRNice joins |
20:36:01 | | nicolas17 is now authenticated as nicolas17 |
21:42:59 | <IDK> | any idea what bug this is? https://web.archive.org/web/20230904083904/https://sh.vnet.cn/ |
21:44:10 | <IDK> | also, exact same copy appeared twice even when only done once: https://web.archive.org/web/20240904234641/https://sh.vnet.cn/ |
21:44:11 | <IDK> | https://archive.fart.website/archivebot/viewer/domain/sh.vnet.cn |
21:45:11 | <nicolas17> | IDK: https://web.archive.org/web/20231013192404/https://support.apple.com/en-us/102458 |
21:45:13 | <nicolas17> | same thing here? |
21:45:27 | <IDK> | yep |
21:45:34 | <IDK> | but the second point is much more urgent |
21:45:48 | <IDK> | or not |
21:45:51 | <IDK> | nvm |
21:47:06 | <IDK> | nicolas17: it is trying to load https://web.archive.org/web/20231013192404/https://support.apple.com/en-us/%EF%BB%BF/_static/%EF%BB%BFimages/toolbar/wayback-toolbar-logo-100.png |
21:49:02 | <nicolas17> | what the *fuck* |
21:49:22 | <nicolas17> | the original page https://web.archive.org/web/20231013192404im_/https://support.apple.com/en-us/102458 has a UTF-8 BOM mark at the beginning |
21:49:46 | <nicolas17> | the processed page has U+FEFF BOM marks *all over the markup* |
21:50:42 | <nicolas17> | https://transfer.archivete.am/inline/KDkze/Screenshot_20241212_185016.png |
21:51:11 | <nicolas17> | IDK: vnet.cn is affected by the same thing |
21:53:26 | <nicolas17> | it's like every HTML parsing token gets a FEFF prefix |
21:53:57 | <nicolas17> | FILE ARCHIVED ON <feff>08:39:04 Sep 04, 2023<feff> AND RETRIEVED FROM THE |
21:59:39 | <imer> | mh. x-archive-src: spn2-20231013201300/spn2-20231013175142-wwwb-spn10.us.archive.org-8002.warc.gz |
22:02:30 | <nicolas17> | imer: the im_ response only has a FEFF at the beginning so I think the capture is fine |
22:02:34 | <nicolas17> | playback is the problem |
22:02:42 | <imer> | ah, right |
22:10:08 | | nulldata quits [Ping timeout: 265 seconds] |