Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

BindHeaders panics on nil or empty header value slices

Aperta Adatta ai principianti
  • Qualcosa non va?
#3,169 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
73/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
go
Ambito
api, backend

Direzione di ricerca

Inizia in bind.go e segui BindHeaders attraverso bindData fino ai percorsi delle mappe scalari e delle struct con tag indicati nell’issue. Usa la riproduzione in-process fornita per gli slice di valori degli header nil e vuoti, poi controlla tutti e tre i tipi di destinazione e i casi di controllo indicati. Il lavoro è completato quando il binding non provoca più un panic e il comportamento scelto è coperto da test di regressione.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.
Lingua principale
Go
Stelle
32.8k
Fork
4.2k
Merge medio
8h 54m
PR unite (30g)
32

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di labstack/echo

Tutte le issue di labstack/echo

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.