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

BindHeaders panics on nil or empty header value slices

Abierto Apto para principiantes
  • ¿Algo no está bien?
#3,169 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@SashaMIT ya está trabajando en esto.

Desde el 11/10/2026.

  • #3170 de @SashaMIT — abierto
  • #3171 de @skyfireitdiy — abierto

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
73/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
go
Área
api, backend

Línea de trabajo

Empieza en bind.go y sigue BindHeaders a través de bindData hasta las rutas de mapas escalares y structs con etiquetas identificadas en el issue. Usa la reproducción en proceso proporcionada para los slices de valores de header nil y vacíos; después, comprueba los tres tipos de destino y los casos de control indicados. El trabajo estará terminado cuando el binding deje de provocar un panic y el comportamiento elegido esté cubierto por pruebas de regresión.

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

Descripción

Issue Description

BindHeaders panics when an in-process request header contains a key whose value is a nil or zero-length []string. This is different from []string{""}, which binds without a panic.

On current master, BindHeaders passes the header map to bindData. The scalar-map paths read v[0], and the tagged struct path reads inputValue[0], without checking the slice length. With Header["X-Empty"] = nil or []string{}, these paths panic with index out of range [0] with length 0 instead of returning normally/an error.

This reproduction constructs the request in-process. I have not demonstrated a way for a raw incoming HTTP header to produce this map state, and I am not claiming a remotely exploitable denial of service.

Working code to debug
package echo_test

import (
    "net/http"
    "net/http/httptest"
    "testing"

    "github.com/labstack/echo/v5"
)

func TestEmptyHeaderValues(t *testing.T) {
    for _, values := range [][]string{nil, {}} {
        func() {
            defer func() {
                if p := recover(); p != nil {
                    t.Errorf("BindHeaders panicked: %v", p)
                }
            }()
            e := echo.New()
            req := httptest.NewRequest(http.MethodGet, "/", nil)
            req.Header["X-Empty"] = values
            c := e.NewContext(req, httptest.NewRecorder())
            var dst struct { Value string `header:"X-Empty"` }
            if err := echo.BindHeaders(c, &dst); err != nil {
                t.Errorf("BindHeaders: %v", err)
            }
        }()
    }
}

I also reproduced the panic for ordinary *map[string]string and *map[string]any targets. A private table test against unchanged master produced 6 failing panic cases (nil/empty slices × three targets) and 6 passing no-panic controls (normal value/one empty string × three targets). Package go vet passed; no full-suite, race, other Go-version or OS run is claimed.

Proposed narrow follow-up

Would skipping entries with no values be the preferred treatment, or should binding return a specific error? I can prepare a narrow bind.go/regression follow-up after confirming this policy and coordination with #3150, which changes adjacent map assignment code but still indexes v[0]. This would not alter named-map conversions, first-value versus all-values behavior, []string{""} semantics, or existing custom multi-value unmarshalling without agreement. #2778's empty-string-to-nil-pointer proposal is a different input case.

Version/commit
  • master 3882266a3641a36fc2111b48cd597adab1c1ecea, module github.com/labstack/echo/v5
  • Go 1.27.1, Linux/arm64; synthetic requests, no running application/provider
  • OpenAI Codex assisted with source tracing and the reproduction. No production fix/PR has been submitted.
Lenguaje dominante
Go
Estrellas
32.8k
Forks
4.2k
Merge medio
8 h 54 min
PR fusionados (30 d)
32

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 labstack/echo

Todos los issues de labstack/echo

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.