Français

Vidéo et sous-titres · Téléchargeur multimédia direct

Pourquoi CORS peut bloquer un téléchargement direct dans le navigateur et ce que cela signifie

· Comment ça marche

cors http téléchargements performances de

Une requête de navigateur répondant à une limite de réponse d'origine croisée sur un hôte multimédia
Illustration vectorielle originale de ToolAcre

Un téléchargeur uniquement par navigateur vit dans la politique de même origine. Cet article explique ce qu'est CORS, pourquoi certains hôtes autorisent la récupération et d'autres non, et pourquoi un outil sans serveur relais ne peut pas contourner ce problème.

Le lien fonctionne dans un nouvel onglet mais échoue dans l'outil — le casse-tête qu'une erreur CORS crée pour les utilisateurs

Une enceinte de podcast peut être lue lorsqu'elle est saisie dans la barre d'adresse, mais échouer lorsqu'une page tente de la lire avec Fetch. La navigation et la lecture scriptée sont des puissances différentes du navigateur. Le premier affiche une ressource ; le second pourrait exposer ses octets à du code exécuté sur une autre origine.

Direct Media Downloader a besoin de la deuxième puissance car il lit les morceaux de réponse, rapporte la progression, crée un Blob et propose une sauvegarde nommée. Lorsque l'hébergeur multimédia n'a pas accepté cette lecture d'origine croisée, le navigateur empêche JavaScript de recevoir la réponse même si la navigation ordinaire peut toujours fonctionner. La même distinction explique pourquoi la copie de l'adresse dans une autre application peut produire un résultat différent sans qu'aucune des deux applications n'ait modifié le fichier distant.

La politique de même origine dans un paragraphe – pourquoi une page sur toolacre.com ne peut pas lire librement les octets servis à partir d'une autre origine

Une origine combine un schéma, un nom d'hôte et un port. Une page servie depuis ToolAcre et un fichier servi depuis un CDN éditeur ont donc généralement des origines différentes. La politique de même origine empêche le script d’une origine de lire librement les réponses d’une autre origine, protégeant ainsi les données exposées via l’accès au navigateur ambiant.

Cette restriction est appliquée par le navigateur, et non par un avertissement inventé dans le téléchargeur. Il s'applique avant que le code de l'application puisse inspecter les en-têtes ou les morceaux de corps protégés. L'hôte source peut toujours recevoir une demande, donc une lecture bloquée ne doit jamais être décrite comme « rien n'a été contacté ». Les limites d'origine s'appliquent aux réponses lisibles, pas seulement aux extensions de fichiers, donc un suffixe `.mp3` apparemment évident n'accorde aucune exemption spéciale aux scripts de page.

Ce que fait Access-Control-Allow-Origin : comment l'hôte du fichier, et non l'outil, décide si le navigateur peut transmettre les octets

Le serveur distant peut s'inscrire en renvoyant un en-tête `Access-Control-Allow-Origin` approprié. Cette décision appartient à la configuration de l’hôte du fichier. ToolAcre ne peut pas ajouter l'en-tête à la réponse de quelqu'un d'autre, et une option de requête ne peut pas accorder l'autorisation refusée au serveur de réception.

Un en-tête permissif permet au navigateur d'exposer la réponse à la page ; il ne certifie pas le droit d'auteur, la sécurité ou la qualité des médias. De même, un en-tête manquant ne prouve pas que l’URL est cassée. Cela signifie simplement que ce script multi-origine n'a pas l'autorisation de lire ce que le serveur a renvoyé. Les administrateurs hôtes doivent tester l'origine exacte de la demande et les méthodes qu'ils ont l'intention de prendre en charge, plutôt que d'ajouter aveuglément des en-têtes permissifs à l'intégralité d'un espace de noms de stockage.

Lectures d'origine croisée bloquées et raison pour laquelle le script ne reçoit aucune réponse enregistrable

Le téléchargeur utilise la récupération en mode CORS ordinaire plutôt que `no-cors`. En cas de lecture d'origine croisée refusée, Fetch rejette et le code d'application ne reçoit ni en-têtes ni corps utilisables. L'outil signale la catégorie combinée `CORS_OR_NETWORK` car les navigateurs ne révèlent intentionnellement pas suffisamment de détails pour distinguer CORS de chaque échec de transport.

Les réponses opaques appartiennent à des requêtes `no-cors` explicites, mais ce mode ne résoudrait pas ce travail : JavaScript ne peut pas inspecter un corps opaque et le transformer en Blob prévu. L’implémentation échoue donc honnêtement au lieu d’acquérir une réponse illisible et de prétendre pouvoir la sauver. Étant donné que l'application n'obtient jamais ces octets cachés, elle ne peut pas calculer fidèlement la progression, déduire un nom de fichier à partir des en-têtes protégés ou créer une URL d'objet utile à partir d'eux.

Exemple concret : lecture de la requête ayant échoué dans le panneau réseau – repérage de l'en-tête manquant et confirmation qu'aucun serveur relais n'a été contacté

Ouvrez le panneau Réseau, conservez le journal et appuyez une fois sur Vérifier le lien. La ligne HEAD tentée identifie la destination et peut afficher le diagnostic CORS du navigateur. Inspecter les en-têtes de réponse si disponibles ; l'absence d'en-tête d'autorisation explique pourquoi le code de la page n'a pas reçu la taille annoncée ou le type MIME.

Une vérification échouée est déjà la preuve qu'une véritable demande a été tentée. Il n'y a aucune ligne d'API ToolAcre contenant l'URL collée et aucune deuxième demande de relais. Si l'hôte autorise mal HEAD, Download peut toujours se comporter différemment car il utilise GET, mais aucun des deux chemins ne change silencieusement d'architecture. La formulation de la console varie selon les navigateurs. Conservez donc les preuves de ligne et d'en-tête défaillants au lieu de dépendre de la formulation d'un fournisseur pour un rapport opérationnel.

Pourquoi l'outil ne le contourne pas : un proxy signifierait envoyer votre lien vers un serveur, ce qui est exactement ce que l'outil promet de ne pas faire

Un proxy pourrait récupérer le fichier côté serveur et le renvoyer à partir d'un point de terminaison de même origine, évitant ainsi la lecture d'origine croisée du navigateur. Cela divulguerait également le lien et chaque octet relayé à cet opérateur, entraînerait une consommation de bande passante et créerait une surface de récupération arbitraire. ToolAcre n'a délibérément pas un tel point de terminaison.

La solution de secours suggérée par l'interface est l'action native Enregistrer le lien en tant que du navigateur, le cas échéant. Il s'agit de la gestion de la navigation ou du téléchargement plutôt que de la lecture du script de page. La suggestion n’affaiblit pas la politique d’hébergement, n’authentifie pas un visiteur ou ne transforme pas un flux protégé en fichier direct. Ce refus architectural empêche également ToolAcre d'accumuler des copies, des journaux d'accès ou des privilèges de récupération sortante uniquement pour transformer un refus du navigateur en succès apparent.

Ce que cela ne couvre pas — CORS n'est pas la même chose qu'un 403, un mur de connexion ou une URL signée expirée L'échec

CORS n'est pas un HTTP 403, bien que l'un ou l'autre puisse arrêter le flux de travail. Un 403 est un statut de réponse choisi par l'hôte ; une signature expirée peut en provoquer une. Un mur de connexion a besoin d’informations d’identification que cet outil omet. Une panne de réseau, une défaillance DNS et des problèmes de certificat peuvent partager le rejet générique de Fetch du navigateur.

Le diagnostic doit donc utiliser les panneaux Réseau et Console ensemble plutôt que de traiter chaque panne comme un en-tête manquant. ToolAcre signale les statuts HTTP connus lorsqu'une réponse lisible arrive, mais il refuse de deviner lorsque le navigateur fournit uniquement une exception en forme de transport. Garder ces catégories séparées dirige correctement le remède : configurez CORS pour un objet public autorisé, actualisez un lien expiré, connectez-vous via le fournisseur ou corrigez la connectivité.

À retenir : CORS est une décision côté hôte – comment Direct Media Downloader le signale honnêtement au lieu de revenir silencieusement à un serveur

CORS est contrôlé au niveau de l'hôte multimédia. Un téléchargeur uniquement par navigateur peut obéir à ce choix, l'expliquer et s'arrêter ; il ne peut pas remplacer le choix du code client. Cette limite est gênante précisément parce qu’elle empêche des pages arbitraires de devenir des lecteurs multisites universels.

Utilisez un contrôle de téléchargement fourni par l'hôte, demandez un fichier autorisé compatible CORS ou utilisez le lien d'enregistrement natif, le cas échéant. Direct Media Downloader tient sa promesse en exposant le refus et en préservant un chemin direct du navigateur vers l'hôte, et non en cachant un serveur derrière un bouton plus performant. Un résultat positif doit donc provenir d'un hôte coopératif ou d'une autre installation de navigateur légitime, jamais de la suppression du texte d'erreur tout en conservant la même lecture refusée.