Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

NO_PROXY implementation is incomplete

Abierto
  • ¿Algo no está bien?
#830 5 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
45/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
javascript
Área
networking

Línea de trabajo

Comienza con shouldProxy en lib/resolve-config.js cerca de las líneas enlazadas; después, lee la discusión de GitLab sobre NO_PROXY y la referencia de proxy-from-env. La corrección estará completa cuando el ejemplo de subdominio y los demás casos de NO_PROXY descritos en la issue omitan correctamente el proxy, con el comportamiento relevante cubierto por pruebas.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

feature help wanted

The function shouldProxy was
// Copied from Rob Wu's great proxy-from-env library: https://github.com/Rob--W/proxy-from-env/blob/96d01f8fcfdccfb776735751132930bbf79c4a3a/index.js#L62

Sadly the implementation is incomplete and misses many use cases.
There is a great page at:

https://about.gitlab.com/blog/2021/01/27/we-need-to-talk-no-proxy/

Which gives a good discussion about NO_PROXY and the issues that have arisen from it. Rob Wu's implementation suffers many problems the article discusses.

For example given:

export HTTP_PROXY=something
export HTTPS_PROXY=something
export NO_PROXY=subdomain.domain.com

A gitlab server at gitlab.subdomain.domain.com would not bypass the proxy as the block:

    if (!/^[.*]/.test(parsedProxyHostname)) {
      // No wildcards, so stop proxying if there is an exact match.
      return hostname !== parsedProxyHostname;
    }

Would do a comparison:

if(!/^[.*]/.test(subdomain.domain.com)){
   return gitlab.subdomain.domain.com !== subdomain.domain.com
}

resulting in a true response and hence the gitlab server being pushed through to the proxy.
Often proxies do not allow access to internal services hence this results in errors occurring in the semantic-release/gitlab plugin:

[12:06:30 AM] [semantic-release] › ℹ  Start step "verifyConditions" of plugin "@semantic-release/gitlab"
[12:06:30 AM] [semantic-release] [@semantic-release/gitlab] › ℹ  Verify GitLab authentication (https://gitlab.subdomain.domain.com/api/v4)
[12:06:30 AM] [semantic-release] › ✘  Failed step "verifyConditions" of plugin "@semantic-release/gitlab"
[12:06:30 AM] [semantic-release] › ✘  An error occurred while running semantic-release: RequestError: Bad response: 403

This bug report is to request a fix to the shouldProxy method to correctly handle NO_PROXY values which list [sub]domains without wild cards.

It seems the proxy-from-env still has the bug, but with the core code not being maintained for 5 years, and even nodejs commenting that it was incomplete when they implemented NO_PROXY support, the recommendation would be to either update the existing code base or convert the codebase to use an alternative library.

Lenguaje dominante
JavaScript
Estrellas
342
Forks
90
Merge medio
1 d 2 h
PR fusionados (30 d)
2

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de semantic-release/gitlab

Todos los issues de semantic-release/gitlab

Issues similares

Más issues de JavaScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.