Comments on L'Internet Archive et YouTube veulent me rendre malheureux

Ptitboul (2025-04-12T12:30:53Z)

Je viens de tester avec http://vampirerpg.free.fr/ et l'archivage a marché.
https://web.archive.org/web/20250412122815/http://vampirerpg.free.fr/

Ruxor (2025-04-10T21:34:10Z)

@Subbak: Merci des recommandations. Certaines que tu évoques m'étaient connues (j'avais oublié de les citer, mais bon, ma liste ne se voulait pas exhaustive), comme Histony dont j'aime beaucoup la série sur la France au XIXe, ou Contrapoints (je n'en ai regardé que 2-3 parce que c'est long, mais j'ai bien aimé), donc tu as dû assez bien cerner mes goûts. Du coup je vais sans doute jeter un œil au reste !

Subbak (2025-04-10T11:24:54Z)

Ça ne résoudra rien de tes problèmes mais si tu cherches d'autres chaînes Youtube qui peuvent t'intéresser :
- J'ai du mal à croire que tu ne connaisses pas le "bread tube", à savoir Hbomberguy (Harry Brewis), Contrapoints (Natalie Wynn) et Philosophy Tube (Abigail Thorn), surtout que tu suis Legal Eagle qui fait régulièrement des pubs pour Nebula dans ses vidéos, et que Abigail Thorn a cofondé Nebula. Ce sont des video essays en général assez longs voir très longs, avec des grosses production values, qui parlent de divers sujets.
- Histony, un historien français qui fait de la vulga, à la fois sur des sujets généraux (en ce moment il fait une série longue sur la France de 1818 à 1871, après en avoir fait une sur 1814-1848 et une beaucoup plus vieille sur 1789-1799) et sur le sujet dont il est spécialistes (l'histoire des paquebots transatlantiques, notamment le Titanic)
- Jenny Draper, une guide touristique de Londres qui fait des vidéos super intéressantes sur l'histoire de Londres et du Royaume-Uni. Ça peut prendre la forme de réponses à des questions fréquemment posées, de deep dives dans un sujet de niche, ou de commentaire autour d'un film avec des aspects historiques (par exemple l'été dernier elle a parlé de la vraie histoire derrière le film "Pride" de 2014 qui raconte le mouvent du Lesbians and Gays Supporting Miners).

Apokrif (2025-04-01T11:12:21Z)

Pour YouTube: il me semble qu'il existe des interfaces alternatives, sinon ça doit être facile à bricoler en interfaçant le HTML d'origine avec yt-dlp?

Charles (2025-03-30T20:21:41Z)

> je me suis plaint du problème sur Twitter

Dommage, il faut être abonné X pour pouvoir voir la discussion.

> Peut-être qu'un jour ça cessera de marcher, et alors j'arrêterai de regarder YouTube parce que, de ce que je comprends, leurs pubs sont atrocement envahissantes et insupportables

Alternative, payer l'abonnement. 24 euros abonnement famille, que l'on peut partager avec 4 autres personnes. Je trouve que ça en vaut largement le prix vu l'utilité du produit. Disons une dizaine d'euro par mois, c'est le prix d'un cinéma ou de deux magazines papiers.

jeanas (2025-03-29T15:02:10Z)

(J'ai résumé ça sur ta question <URL:https://webmasters.stackexchange.com/q/145994/>.)

jeanas (2025-03-29T14:43:59Z)

Je viens de faire un nouveau test qui donne des résultats intéressants.

D'abord, j'ai demandé à l'Archive d'enregistrer une page servie par ce script Rust :

```
use tiny_http::{Header, Response, Server, StatusCode};
use std::time::Duration;

fn main() {
let server = Server::http("localhost:8085").unwrap();
loop {
let Ok(req) = server.recv() else {
eprintln!("couldn't read request?");
continue;
};
std::thread::sleep(Duration::from_secs(3));
let loc = Header::from_bytes(b"Location", "https://jean.abou-samra.fr/img/nympheas.jpg").unwrap();
let resp = Response::empty(StatusCode(301)).with_header(loc);
let res = req.respond(resp);
eprintln!("Result: {res:?}");
}
}
```

Après avoir reçu la requête HTTP, il attend 3 secondes avant d'envoyer une réponse de redirection avec code 301 et Location vers une autre page, mais sans plus de contenu.

Résultat : l'Archive a bien suivi le redirecteur, en attendant donc les 3 secondes, et enregistré la page pointée. <URL:https://web.archive.org/web/20250329132826/http://archive-test.abou-samra.fr/>

Ensuite, j'ai fait ceci :

```
use std::net::TcpListener;
use std::io::Write;
use std::time::Duration;

fn main() {
let listener = TcpListener::bind("localhost:8085").unwrap();
for stream in listener.incoming() {
let mut stream = stream.unwrap();
eprintln!("Received request, waiting");
std::thread::sleep(Duration::from_secs(3));
let text = "Lorem ipsum dolor sit amet consecutur elit adipiscem erat locusque tantrix ratem ichitiae poliifecis";
let headers = format!("HTTP/1.1 301 Moved Permanently\r\nLocation: https://jean.abou-samra.fr/img/nympheas.jpg\r\nContent-Length: {}\r\n\r\n", text.len());
eprintln!("Sending response headers");
if let Err(err) = stream.write_all(headers.as_bytes()) {
eprintln!("Error already while writing status line: {err}");
continue;
}
let mut first = true;
for (i, word) in text.split(' ').enumerate() {
eprintln!("Sending word {word}");
let res = if first {
stream.write_all(word.as_bytes())
} else {
stream.write_all((String::from(" ") + word).as_bytes())
};
if let Err(err) = res {
eprintln!("Error while writing {i}-th word: {err}");
break;
}
std::thread::sleep(Duration::from_secs_f32(0.1));
first = false;
}
}
}
```

Ça fait la même chose, mais en envoyant en plus un corps de réponse (normalement c'est quelque chose du genre « 301 Moved Permanently — nginx/1.22.1 ») avec un peu de texte qui est écrit mot par mot avec un délai de 0.1s entre deux mots. J'ai désactivé le buffering dans mon reverse proxy (`proxy_buffering off` dans `nginx.conf`), et vérifié avec `curl -Nv` que le texte était reçu de manière perlée par le client.

Résultat : mon serveur a reçu deux requêtes, l'une a fermé la connexion dès le 3ème mot (`Error while writing 3-th word: Broken pipe (os error 32)`), l'autre a attendu la fin. J'ai réessayé une deuxième fois, exactement le même résultat.

Pour finir, j'ai changé

```
let headers = format!("HTTP/1.1 301 Moved Permanently\r\nLocation: https://jean.abou-samra.fr/img/nympheas.jpg\r\nContent-Length: {}\r\n\r\n", text.len());
```

en

```
let headers = format!("HTTP/1.1 200 OK\r\nContent-Type: text/html;charset=utf-8\r\nContent-Length: {}\r\n\r\n", text.len());
```

pour envoyer cette fois le texte comme vraie page de réponse. Cette fois, je n'ai reçu qu'une requête, et à nouveau connexion fermée au 3ème mot. Et il décide que la page 404 du HTTPS est mieux à sauvegarder que la page HTTP :(

J'en conclus qu'il n'y a pas de timeout global, mais simplement des connexions qui sont (parfois) fermées dès que l'Archive a reçu une réponse HTTP 200 OK qui ne l'intéresse pas.

jeanas (2025-03-29T01:24:48Z)

Hypothèse qui me traverse l'esprit au milieu d'une insomnie :

Peut-être que l'Archive a imposé ce timeout très court parce qu'ils veulent surtout vérifier si le HTTP redirige autre part, et que pour ça il n'y a besoin que de regarder le tout début de la réponse (le code de statut HTTP et l'éventuel en-tête Location).

Ruxor (2025-03-28T22:04:06Z)

@jeanas: Merci du test !

jeanas (2025-03-28T21:51:45Z)

Après un rapide test sur mon propre site, je confirme qu'en HTTPS ça marche alors qu'en activant temporairement le HTTP (je veux dire, en le faisant servir lui-même la page, plutôt que de rediriger vers le HTTPS, et aussi en désactivant le HTTPS parce que sinon l'Internet Archive décide de récupérer le HTTPS même si je lui donne l'URL en HTTP…), il me donne la même erreur « Save Page Now could not capture this URL because it was unreachable. » (Je n'ai pas fait de tcpdump par contre, et j'avoue que je ne saurais même pas l'interpréter, je n'y connais vraiment rien en réseaux…)


You can post a comment using the following fields:
Name or nick (mandatory):
Web site URL (optional):
Email address (optional, will not appear):
Identifier phrase (optional, see below):
Attempt to remember the values above?
The comment itself (mandatory):

Optional message for moderator (hidden to others):

Spam protection: please enter below the following signs in reverse order: 70b6eb


Recent comments