Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

BindHeaders panics on nil or empty header value slices

Ouverte Adaptée aux débutants
  • Quelque chose ne va pas ?
#3,169 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

@SashaMIT y travaille déjà.

Depuis le 11/10/2026.

  • #3170 par @SashaMIT — ouverte
  • #3171 par @skyfireitdiy — ouverte

Évaluation

Difficulté
2/5
Temps estimé
1-3 heures
Accessibilité débutants
73/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
go
Domaine
api, backend

Piste de recherche

Commencez dans bind.go et suivez BindHeaders via bindData jusqu’aux chemins des maps scalaires et des structs avec tags indiqués dans l’issue. Utilisez la reproduction en processus fournie pour les slices de valeurs d’en-tête nil et vides, puis vérifiez les trois types cibles ainsi que les cas témoins indiqués. Le travail est terminé lorsque le binding ne provoque plus de panic et que le comportement choisi est couvert par des tests de régression.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.
Langage dominant
Go
Étoiles
32.8k
Forks
4.2k
Merge moyen
8 h 54 min
PR mergées (30 j)
32

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de labstack/echo

Toutes les issues de labstack/echo

Issues similaires

Plus d'issues Go

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.