Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

BindHeaders panics on nil or empty header value slices

Aberta Para iniciantes
  • Algo errado?
#3,169 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

@SashaMIT já está trabalhando nisso.

Desde 11/10/2026.

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

Avaliação

Dificuldade
2/5
Tempo estimado
1-3 horas
Facilidade para iniciantes
73/100
Tipo de issue
Bug
Clareza
Claramente especificada
Status de atividade
Ativa
Stack de tecnologia
go
Domínio
api, backend

Direção de pesquisa

Comece em bind.go e siga BindHeaders por bindData até os caminhos de mapas escalares e structs com tags identificados na issue. Use a reprodução em processo fornecida para slices de valores de header nil e vazios; em seguida, verifique os três tipos de destino e os casos de controle indicados. O trabalho estará concluído quando o binding não causar mais panic e o comportamento escolhido estiver coberto por testes de regressão.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.
Linguagem predominante
Go
Estrelas
32.8k
Forks
5.1k
Merge médio
14h 51min
PRs com merge (30d)
32

Preparar o ambiente

Este projeto não oferece contêiner de desenvolvimento, Dockerfile nem guia de contribuição, então a configuração fica por sua conta: comece pelo README e veja nosso guia da primeira contribuição para os passos gerais.

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de labstack/echo

Todas as issues de labstack/echo

Issues semelhantes

Mais issues de Go

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.