| 00:26:49 | | aarchi quits [Read error: Connection reset by peer] |
| 00:27:02 | | aarchi (aarchi) joins |
| 00:28:42 | | themadpro quits [Ping timeout: 622 seconds] |
| 00:30:48 | | themadpro (themadpro) joins |
| 02:08:00 | <OrIdow6> | Same 404 page gets returned on, AFAICT, all web.archive.org requests where the URL contains the substring "camelcamelcamel.com" |
| 02:12:03 | <OrIdow6> | Actually, the character in the place of the "." doesn't matter, as long as it is present, which suggests to me that, wherever this is configured, it takes a regex, but someone put in a literal "camelcamelcamel.com" |
| 02:13:21 | <@JAA> | lol |
| 02:15:13 | <@JAA> | Found a bypass but can't get it to work in a browser. |
| 02:16:27 | <@JAA> | Nevermind, found a way. :-) |
| 02:17:44 | <@JAA> | But I assume there's a pretty strong reason behind the block if they implemented it so broadly, so I won't share that in a publicly logged channel. |
| 02:18:54 | | HP_Archivist (HP_Archivist) joins |
| 02:21:08 | <OrIdow6> | Yeah |
| 04:52:41 | | qw3rty__ joins |
| 04:56:23 | | qw3rty_ quits [Ping timeout: 244 seconds] |
| 05:09:48 | | qwertyasdfuiopghjkl quits [Remote host closed the connection] |
| 06:07:34 | | HP_Archivist quits [Ping timeout: 258 seconds] |
| 06:43:51 | <OrIdow6> | Anyone know how to solve the problem where a (apparently) complex URL has a capture, but it gives a 404 when you try to access it? I know I've encountered this before, but can't remember what I did about it, if anything |
| 06:45:20 | <OrIdow6> | https://transfer.archivete.am/dnUg9/gdrive_url.txt is what I'm trying - it redirects for "found capture at", but then gives a not archived message at the destination |
| 06:46:00 | <OrIdow6> | It's in CDX and I can successfully retrieve URLs from the same item |
| 06:47:56 | <OrIdow6> | Hm, the CDX says the dest is a revisit, which from my memory is weird; maybe I'll try to look at the warc |
| 06:48:05 | <OrIdow6> | *CDX response |
| 06:49:51 | <@JAA> | I believe the WBM doesn't like redirects in revisit records. |
| 06:50:36 | <@JAA> | I came across that issue with my Picosong archive. For example, https://web.archive.org/web/2019*/https://picosong.com/cdn/0e136c10da7f0ec391da7bc7e8cff2b2.mp3 displays a snapshot, but it doesn't load. |
| 06:50:48 | <@JAA> | The relevant WARC record is here: `curl -sL --range "642358676-$((642358676+867-1))" https://archive.org/download/picosong.com_201910_part2/picosong-site-00260.warc.gz | zstdless` |
| 06:51:37 | <@JAA> | Not sure if it's the same issue, but could be. |
| 06:53:56 | <OrIdow6> | The thing I'm trying to get is apparently a 200 |
| 06:56:16 | <@JAA> | CDX API returns - for the status code though. |
| 06:58:41 | <OrIdow6> | Oh, didn't notice that |
| 06:59:15 | <@JAA> | Would definitely be interesting to see what the WARC record looks like. |
| 07:00:42 | <OrIdow6> | Though I think I've seen - a lot for revisits? |
| 07:00:59 | <OrIdow6> | Revisit: curl -Lr 10286327017-10286328415 'https://archive.org/download/archiveteam_googledrive_20210909134428_68c05e49/googledrive_20210909134428_68c05e49.megawarc.warc.gz' | zcat |
| 07:01:44 | <OrIdow6> | One with the data: curl -Lr 10286315978-10286317602 'https://archive.org/download/archiveteam_googledrive_20210909134428_68c05e49/googledrive_20210909134428_68c05e49.megawarc.warc.gz' | zcat |
| 07:02:01 | <OrIdow6> | I wonder if I'm missing something obvious here |
| 07:04:33 | <@JAA> | Hmm, don't see anything wrong there at a glance. |
| 07:09:53 | <OrIdow6> | Do you know of any more instances of this? |
| 07:12:25 | <@JAA> | I think I've seen issues around revisit records before on some of my qwarc archives, but I assumed those were somehow related to the original records being in different WARCs or even items. |
| 07:13:14 | <OrIdow6> | I do notice that both these and your picosing example have chunked transfer encoding |
| 07:14:10 | <OrIdow6> | (r"These" meaning the one I've given and another pair in what I assume is the same item with similar behavior) |
| 07:22:15 | <@JAA> | Hmm, interesting. |
| 07:33:04 | <OrIdow6> | I'm having difficulty find a non-chunked record to test this on |
| 07:33:35 | <OrIdow6> | Hm |
| 08:00:47 | | h3ndr1k leaves [ ] |
| 09:41:59 | | spirit quits [Client Quit] |
| 10:10:13 | | Terbium quits [Ping timeout: 258 seconds] |
| 10:59:21 | | qwertyasdfuiopghjkl joins |
| 12:01:37 | | spirit joins |
| 12:36:43 | | qwertyasdfuiopghjkl5 joins |
| 12:38:17 | | qwertyasdfuiopghjkl quits [Ping timeout: 244 seconds] |
| 12:41:55 | | qwertyasdfuiopghjkl5 is now known as qwertyasdfuiopghjkl |
| 13:19:06 | | qwertyasdfuiopghjkl quits [Client Quit] |
| 13:32:14 | | Arcorann_ quits [Ping timeout: 258 seconds] |
| 13:44:30 | | tzt quits [Ping timeout: 258 seconds] |
| 14:07:16 | | tzt (tzt) joins |
| 14:57:51 | | AK quits [Quit: Ping timeout (120 seconds)] |
| 14:57:51 | | Craigle quits [Quit: Ping timeout (120 seconds)] |
| 14:58:31 | | Craigle (Craigle) joins |
| 14:58:42 | | AK (AK) joins |
| 15:08:26 | | AK quits [Client Quit] |
| 15:09:14 | | AK (AK) joins |
| 15:20:26 | | HP_Archivist (HP_Archivist) joins |
| 15:42:11 | | tzt quits [Ping timeout: 258 seconds] |
| 16:24:20 | | qwertyasdfuiopghjkl joins |
| 16:26:32 | | fionera (Fionera) joins |
| 16:50:02 | | HP_Archivist quits [Ping timeout: 258 seconds] |
| 17:11:21 | | thetechrobo_ joins |
| 17:14:57 | | TheTechRobo quits [Ping timeout: 258 seconds] |
| 17:16:13 | | thetechrobo_ is now known as TheTechRobo |
| 17:16:22 | | TheTechRobo is now authenticated as TheTechRobo |
| 18:18:09 | | TheTechRobo quits [Remote host closed the connection] |
| 18:18:31 | | TheTechRobo joins |
| 20:04:47 | <@JAA> | OrIdow6: Yeah, the status - seems to be normal for all revisit records. Didn't noticed that previously for some reason. Also don't immediately see why it happens in CDX-Writer, but oh well. |
| 20:05:05 | <@JAA> | As for examples, here's one that also doesn't behave as I'd expect: https://web.archive.org/web/*/https://forum.supercell.com/printthread.php?t=1101200&pp=10&page=1 |
| 20:06:03 | <@JAA> | The snapshot at :21 is a revisit of the one at :26 (haven't looked into why, maybe just a slow response). But when you try to load the one at :21 it redirects to the :26 one instead. |
| 20:06:23 | <@JAA> | Since both have the same URL, that works, but if it were a revisit of a different URL, I guess it'd be a 404 as well. |
| 20:07:12 | | tzt (tzt) joins |
| 20:24:19 | | tzt quits [Ping timeout: 244 seconds] |
| 20:27:53 | | tzt (tzt) joins |
| 20:28:08 | | Sanqui_ is now known as Sanqui |
| 20:28:09 | | Sanqui is now authenticated as Sanqui |
| 21:07:12 | | qwertyasdfuiopghjkl quits [Ping timeout: 244 seconds] |
| 21:32:36 | | qwertyasdfuiopghjkl joins |
| 21:59:51 | <@JAA> | Another one like that: https://web.archive.org/web/*/https://forum.viva.nl/actueel/filesurvival-heb-jij-een-nooduitrusting/list_messages/98592 |
| 22:00:05 | <@JAA> | The snapshot from 2021-08-27 is a revisit of a 403, but it switches to the July snapshot instead. |
| 22:00:28 | <@JAA> | This one is not chunked: `curl -sL --range 533173426-$((533173426+711-1)) https://archive.org/download/forum.viva.nl_20210827/forum.viva.nl-00002.warc.gz | zstdcat` |
| 22:48:28 | <@JAA> | https://web.archive.org/web/*/https://mods.io/mods/187 is a 404 when trying to access it. |
| 22:49:02 | <@JAA> | WARC record: `curl -sL --range 1670286012-$((1670286012+1042-1)) https://archive.org/download/mods.io_20210823/mods.io-00000.warc.gz | zstdcat` |
| 23:39:15 | | knecht420 quits [Quit: The Lounge - https://thelounge.chat] |
| 23:39:51 | | knecht420 (knecht420) joins |
| 23:41:19 | | knecht420 quits [Client Quit] |
| 23:43:05 | | Arcorann_ joins |
| 23:43:34 | | knecht420 (knecht420) joins |