Una URL de proxy funciona cuando se configura directamente, pero la autenticación falla después de que el mismo valor se traslada a un archivo por lotes de Windows. Compruebe si el analizador por lotes cambió los signos de porcentaje antes de que el cliente HTTP recibiera la URL.

Hay dos representaciones distintas. La codificación de URL puede representar una barra invertida como %5C y un signo de interrogación como %3F. Un signo de porcentaje literal en un comando de archivo por lotes debe escaparse como %%.

Para una cuenta ilustrativa domain\user con la contraseña de ejemplo pass?, un archivo .bat puede contener:

set "https_proxy=http://domain%%5Cuser:pass%%[email protected]:8080"

El proceso iniciado después debería recibir una URL que contenga domain%5Cuser:pass%3F. Los signos de porcentaje duplicados pertenecen al origen por lotes, no a la URL de proxy que almacena el cliente.

No copie esa grafía por lotes en un archivo .npmrc ni en el campo de proxy de una aplicación: esas entradas no pasan por el mismo paso de análisis por lotes. Del mismo modo, este ejemplo no es sintaxis de PowerShell. Otro contenedor, como CALL o un comando construido para un segundo shell, puede introducir otra pasada de análisis y necesita su propia revisión.

Ponga la asignación SET entre comillas como se muestra, para que los espacios incidentales o los metacaracteres del shell no formen parte de un comando no deseado. Las comillas por sí solas no impiden la expansión del porcentaje.

Al comprobar el resultado, compare la codificación esperada con una representación redactada en lugar de imprimir la URL con la contraseña en un registro compartido. Una reparación de escape del shell conserva la credencial; no selecciona un esquema de autenticación que el cliente ya no admitiera.

Artículos relacionados