WebTransport: límites de origen, flujos y privacidad
Use WebTransport con criterio: separe el soporte en contexto seguro, la semántica de los flujos, la política del servidor y los límites de BotBrowser.
BotBrowser Team
Quieres la documentación estructurada de Plataforma?
Este artículo forma parte de la biblioteca editorial. Para pasos de configuración, material de referencia y actualizaciones continuas, entra en la sección de docs.
WebTransport es una API del navegador para comunicarse con un servidor mediante transporte seguro y multiplexado. La respuesta depende del contexto: una página solo puede construir WebTransport cuando está en un contexto seguro compatible, y una conexión establecida no demuestra autorización, identidad del par ni privacidad de la aplicación. BotBrowser puede repetir un recorrido autorizado de perfil para obtener evidencia de compatibilidad; no concede permisos, evita políticas de origen, inspecciona otro origen ni demuestra que el servidor trate los datos de forma segura.
Resumen
- Compruebe la disponibilidad de
WebTransport, exija un contexto seguro y trate el rechazo de conexión como un estado normal. - Una sesión admite flujos bidireccionales y datagramas; orden y fiabilidad son decisiones distintas.
- La política de mismo origen y la autorización del servidor siguen vigentes; el éxito del transporte no garantiza identidad ni privacidad.
- Registre solo el resultado mínimo necesario para soporte; no convierta metadatos de conexión en una huella persistente.
- BotBrowser puede repetir un recorrido autorizado, pero la página, el servidor, el proxy y la política de retención conservan sus responsabilidades.
Contenido
- Qué garantiza la API
- Una prueba de conexión acotada
- Límites de origen y privacidad
- Matriz de evidencia y decisión
- Conclusión
- Preguntas frecuentes
Qué garantiza la API
La especificación W3C define una API cliente segura y vinculada a un origen. new WebTransport(url) crea una sesión candidata; ready se resuelve cuando se establece y closed informa del cierre final. Los flujos ofrecen contrapresión y bytes fiables y ordenados. Los datagramas son mensajes independientes sin garantía de entrega ni orden. La API no define su inicio de sesión, esquema de mensajes, control de acceso ni retención del servidor.
La URL debe usar https: (salvo la excepción admitida para desarrollo local) y el navegador aplica sus comprobaciones habituales de contexto seguro y origen. El servidor puede rechazar la sesión, fallar el certificado, un proxy puede no admitir la ruta HTTP/3 o una política puede bloquear la solicitud. Trate estos casos como motivos diferentes para la alternativa visible; no etiquete todo como «incompatibilidad del navegador».
Una prueba de conexión acotada
Esta prueba mantiene pequeño el contrato de la aplicación y hace observable el resultado:
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' });
}
}
Los resultados esperados son unsupported, ready seguido de closed, o rejected. Un ready correcto solo demuestra que esta página y este endpoint establecieron una sesión en las condiciones probadas. No demuestra que llegara un datagrama, que un flujo estuviera autorizado ni que el servidor confirmara un registro. Añada una prueba de eco pequeña y un plazo de aplicación cuando esos resultados importen.
Límites de origen y privacidad
El origen es el límite de seguridad del navegador para la página que inicia la sesión. Las cabeceras CORS no convierten un endpoint cualquiera en una aplicación confiable; el servidor todavía debe autenticar y autorizar cada operación. No incluya tokens de acceso en una URL ni trate el nombre del host remoto como prueba de la cuenta u organización. Use el canal normal de credenciales de la aplicación y rote las credenciales independientemente de las pruebas de transporte.
Los tiempos de conexión, códigos de cierre, negociación de protocolo y ruta de red varían según versión del navegador, proxy, sistema operativo y carga del servidor. Son observaciones operativas, no una licencia para inferir una persona o dispositivo. Limite la telemetría al estado de sesión, versión de prueba, etiqueta de versión y clase general de fallo. Evite cargas útiles, URL completas con identificadores y huellas de conexión duraderas.
El límite de capacidad de BotBrowser es concreto. Puede ejecutar un flujo autorizado de perfil y repetir la misma prueba bajo una compilación, plataforma y configuración de proxy declaradas. No expone la sesión de otro origen, anula la validación TLS, hace que un servidor acepte HTTP/3, garantiza la entrega de datagramas ni certifica retención o autorización. Informe la ruta y alternativa probadas, no una garantía universal.
Matriz de evidencia y decisión
Ejecute la prueba con un endpoint controlado, datos sintéticos y una declaración fija de navegador y perfil. Registre origen de página, clase de endpoint, estado de contexto seguro, estado de sesión, resultado de flujo/datagrama, razón de cierre y alternativa mostrada. No guarde credenciales ni contenido de carga útil.
| Observación | Interpretación segura | Siguiente acción |
|---|---|---|
unsupported | El contexto probado no ofrece la API | Mantenga la alternativa WebSocket o HTTPS y muestre su límite |
rejected antes de ready | Falló el contexto, certificado, proxy, política o negociación del servidor | Clasifique el fallo; no culpe al motor sin repetir una prueba controlada |
ready, eco del flujo correcto | Esta ruta admite el flujo fiable probado | Mantenga contrapresión y plazo; pruebe la reconexión |
ready, eco del datagrama perdido | La semántica del datagrama o la ruta permiten pérdida | Use flujos para mensajes obligatorios y muestre el modo degradado |
closed tras el plazo de la aplicación | La sesión terminó; el resultado de negocio puede ser incierto | Reconcilie con una clave de idempotencia antes de reintentar |
La matriz es el artefacto práctico: relaciona un resultado observable con una decisión de producto segura. Repítala si cambian navegador, perfil, proxy, endpoint o versión del servidor, y modifique una variable cada vez.
Conclusión
Use WebTransport cuando sus contratos de origen seguro, flujos, datagramas y servidor correspondan a la tarea del usuario. Detecte la API, conserve una alternativa y documente evidencia acotada. El siguiente paso seguro es ejecutar la prueba de eco sintética en el origen real y verificar reconexión y recuperación de resultados inciertos, no limitarse a comprobar que existe el constructor.
Preguntas frecuentes
¿WebTransport sustituye la autenticación?
No. Transporta mensajes de la aplicación; el servidor aún debe autenticar, autorizar, validar y registrar las operaciones.
¿Son fiables los datagramas?
No. Son independientes y pueden perderse o llegar desordenados. Use un flujo bidireccional para datos que deban llegar en orden.
¿Una sesión establecida demuestra privacidad?
No. Demuestra que una ruta estableció una sesión. El tratamiento de cargas útiles, registros, visibilidad del proxy, retención y acceso son decisiones separadas.
¿BotBrowser puede forzar una conexión bloqueada?
No. Puede repetir un flujo autorizado para obtener evidencia; no puede eludir políticas de contexto seguro, origen, certificado, proxy o servidor.
Fuentes y lecturas siguientes
- WebTransport del W3C
- API WebTransport de MDN
- Contextos seguros y funciones potentes
- Compatibilidad de API y alternativas
Fuentes
Artículos Relacionados
Lleva BotBrowser de la investigación a producción
Usa estas guías para entender el modelo y después avanzar hacia validación multiplataforma, contextos aislados y despliegue de navegador preparado para escalar.