WebTransport : frontières d’origine, de flux et de confidentialité
Utilisez WebTransport avec discernement : distinguez contexte sécurisé, sémantique des flux, politique serveur et limites de BotBrowser.
BotBrowser Team
Vous voulez la documentation structurée pour Plateforme ?
Cet article fait partie de la bibliothèque éditoriale. Pour les étapes de configuration, la référence et les mises à jour continues, passez directement à la section docs.
WebTransport est une API de navigateur destinée à communiquer avec un serveur par un transport sécurisé et multiplexé. La réponse dépend du contexte : une page ne peut construire WebTransport que dans un contexte sécurisé compatible, et une connexion établie ne prouve ni l’autorisation, ni l’identité du pair, ni la confidentialité de l’application. BotBrowser peut répéter un parcours de profil autorisé pour fournir des éléments de compatibilité ; il n’accorde pas de permission, ne contourne pas les politiques d’origine, n’inspecte pas une autre origine et ne prouve pas que le serveur traite les données en toute sécurité.
- Vérifiez la présence de
WebTransport, exigez un contexte sécurisé et traitez le rejet de connexion comme un état normal. - Une session accepte des flux bidirectionnels et des datagrammes ; ordre et fiabilité sont des choix distincts.
- La politique de même origine et l’autorisation du serveur restent applicables ; une connexion réussie ne garantit ni identité ni confidentialité.
- Ne consignez que le résultat minimal nécessaire au support ; ne transformez pas les métadonnées de connexion en empreinte persistante.
- BotBrowser peut répéter un parcours autorisé, mais la page, le serveur, le proxy et la politique de conservation gardent leurs responsabilités.
TL;DR
WebTransport nécessite un contexte sécurisé et une politique serveur explicite. Les flux sont fiables et ordonnés ; les datagrammes peuvent être perdus. BotBrowser peut rejouer un parcours autorisé pour documenter un résultat, mais ne garantit ni l’autorisation du serveur ni la conservation des données.
Sommaire
- Ce que garantit l’API
- Un test de connexion borné
- Frontières d’origine et de confidentialité
- Matrice de preuves et de décisions
- Conclusion
- Questions fréquentes
Ce que garantit l’API
La spécification W3C définit une API client sécurisée et liée à une origine. new WebTransport(url) crée une session candidate ; ready se résout quand la session est établie, tandis que closed signale sa fermeture finale. Les flux apportent une contre-pression et des octets fiables et ordonnés. Les datagrammes sont des messages indépendants sans garantie de livraison ni d’ordre. L’API ne définit ni connexion utilisateur, ni schéma de message, ni contrôle d’accès, ni conservation côté serveur.
L’URL doit utiliser https: (sauf exception de développement local prise en charge) et le navigateur applique ses contrôles habituels de contexte sécurisé et d’origine. Le serveur peut rejeter la session, le certificat échouer, un proxy ne pas prendre en charge le chemin HTTP/3 ou une politique bloquer la requête. Traitez ces causes séparément dans le parcours de repli ; ne qualifiez pas chaque échec d’« incompatibilité du navigateur ».
Un test de connexion borné
Ce test garde le contrat de l’application petit et rend le résultat observable :
async function openSession(url, report) {
if (!('WebTransport' in globalThis)) return report({ state: 'unsupported' });
let transport;
try {
transport = new WebTransport(url);
await transport.ready;
report({ state: 'ready' });
transport.closed.finally(() => report({ state: 'closed' }));
} catch (error) {
report({ state: 'rejected', code: error?.name || 'connection-error' });
}
}
Les résultats attendus sont unsupported, ready puis closed, ou rejected. Un résultat ready prouve uniquement que cette page et ce point de terminaison ont établi une session dans les conditions testées. Il ne prouve ni la réception d’un datagramme, ni l’autorisation d’un flux, ni la validation d’un enregistrement par le serveur. Ajoutez un petit test d’écho et une échéance applicative si ces résultats comptent.
Frontières d’origine et de confidentialité
L’origine est la frontière de sécurité du navigateur pour la page qui lance la session. Les en-têtes CORS ne rendent pas n’importe quel point de terminaison digne de confiance ; le serveur doit toujours authentifier et autoriser chaque opération. Ne placez pas de jeton d’accès dans une URL et ne prenez pas le nom d’hôte distant pour preuve du compte ou de l’organisation. Utilisez le canal d’identifiants habituel de l’application et faites tourner les secrets indépendamment des tests de transport.
Les délais de connexion, codes de fermeture, négociations de protocole et chemins réseau varient selon la version du navigateur, le proxy, le système et la charge serveur. Ce sont des observations opérationnelles, pas un motif pour déduire une personne ou un appareil. Limitez la télémétrie à l’état de session, la version du test, l’étiquette de version et une classe générale d’échec. Évitez les charges utiles, les URL complètes contenant des identifiants et les empreintes de connexion persistantes.
La limite de capacité de BotBrowser est précise. Il peut exécuter un parcours de profil autorisé et répéter le même test sous une version, une plateforme et une configuration de proxy déclarées. Il n’expose pas la session d’une autre origine, ne neutralise pas la validation TLS, ne force pas un serveur à accepter HTTP/3, ne garantit pas la livraison des datagrammes et ne certifie ni conservation ni autorisation. Rapportez le chemin et le repli testés, pas une garantie universelle.
Matrice de preuves et de décisions
Exécutez le test sur un point de terminaison contrôlé, avec une charge synthétique et une déclaration fixe de navigateur et de profil. Consignez l’origine de la page, la catégorie du point de terminaison, le résultat de contexte sécurisé, l’état de session, le résultat flux/datagramme, la raison de fermeture et le repli affiché. N’enregistrez ni identifiants ni contenu de charge.
| Observation | Interprétation prudente | Action suivante |
|---|---|---|
unsupported | L’API manque dans ce contexte testé | Gardez le repli WebSocket ou HTTPS et indiquez sa limite |
rejected avant ready | Échec de contexte, certificat, proxy, politique ou négociation serveur | Classez l’échec ; ne l’attribuez pas au moteur sans nouveau test contrôlé |
ready, écho du flux réussi | Ce chemin prend en charge le flux fiable testé | Gardez la contre-pression et l’échéance ; testez la reconnexion |
ready, écho du datagramme perdu | La sémantique du datagramme ou le chemin autorise la perte | Réservez les flux aux messages obligatoires et affichez le mode dégradé |
closed après l’échéance applicative | Session terminée ; résultat métier potentiellement inconnu | Réconciliez avec une clé d’idempotence avant de réessayer |
Cette matrice est l’artefact pratique de l’article : elle relie un résultat observable à une décision produit prudente. Répétez-la si le navigateur, le profil, le proxy, le point de terminaison ou le serveur change, en ne modifiant qu’une variable à la fois.
Conclusion
Choisissez WebTransport lorsque ses contrats de contexte sécurisé, de flux, de datagrammes et de serveur correspondent à la tâche. Détectez l’API, gardez un repli fonctionnel et consignez des preuves bornées. La prochaine étape sûre consiste à exécuter le test d’écho synthétique sur l’origine réelle et à vérifier reconnexion et récupération des résultats incertains, plutôt qu’à vérifier seulement l’existence du constructeur.
Questions fréquentes
WebTransport remplace-t-il l’authentification ?
Non. Il transporte des messages applicatifs ; le serveur doit encore authentifier, autoriser, valider et enregistrer les opérations.
Les datagrammes sont-ils fiables ?
Non. Ils sont indépendants, peuvent être perdus ou arriver dans le désordre. Utilisez un flux bidirectionnel pour les données qui doivent arriver dans l’ordre.
Une session réussie prouve-t-elle la confidentialité ?
Non. Elle prouve qu’un chemin a établi une session. Traitement des charges, journaux, visibilité du proxy, conservation et accès restent des décisions distinctes.
BotBrowser peut-il forcer une connexion bloquée ?
Non. Il peut répéter un parcours autorisé pour produire des preuves. Il ne contourne pas les politiques de contexte sécurisé, d’origine, de certificat, de proxy ou du serveur.
Sources et lectures suivantes
- WebTransport du W3C
- API WebTransport de MDN
- Contextes sécurisés et fonctionnalités puissantes
- Compatibilité des API et solutions de repli
Sources
Articles Connexes
Faites passer BotBrowser de la recherche à la production
Utilisez ces guides pour comprendre le modèle, puis passez à la validation multi-plateforme, aux contextes isolés et au déploiement navigateur prêt pour l'échelle.