#53313·beats

[bug-hunter] http_endpoint skips options_response_code validation for empty options_headers map

Author: github-actions[bot]Created Sep 18, 2026Updated Sep 18, 2026
Labelsneeds_team

Impact

A configuration with options_headers: {} and an invalid options_response_code passes validation, but OPTIONS requests are still accepted and the handler writes that invalid status code. This can crash request handling for preflight traffic and drop client connections.

Reproduction Steps

  1. Create this new test file at x-pack/filebeat/input/http_endpoint/repro_options_status_test.go:
go
package http_endpoint

import (
    "net/http"
    "testing"

    "github.com/stretchr/testify/require"
)

func TestValidateRejectsInvalidOptionsResponseCodeForEmptyOptionsHeaders(t *testing.T) {
    c := defaultConfig()
    c.OptionsHeaders = http.Header{}
    c.OptionsStatus = 0

    err := c.Validate()
    require.Error(t, err, "config with non-nil options_headers should validate options_response_code")
    require.Contains(t, err.Error(), "options_response_code must be a valid HTTP status code: 0", "error should explain invalid options_response_code")
}
  1. Run:
bash
go test -run TestValidateRejectsInvalidOptionsResponseCodeForEmptyOptionsHeaders -count=1 ./x-pack/filebeat/input/http_endpoint

Expected vs Actual

Expected: Validation fails when options_headers is configured (including empty map) and options_response_code is outside HTTP valid range.

Actual: Validation returns nil, causing the test to fail:

--- FAIL: TestValidateRejectsInvalidOptionsResponseCodeForEmptyOptionsHeaders (0.00s)
    repro_options_status_test.go:20:
                Error Trace:    /home/runner/work/beats/beats/x-pack/filebeat/input/http_endpoint/repro_options_status_test.go:20
                Error:          An error is expected but got nil.
                Test:           TestValidateRejectsInvalidOptionsResponseCodeForEmptyOptionsHeaders
                Messages:       config with non-nil options_headers should validate options_response_code
FAIL
FAIL    github.com/elastic/beats/v7/x-pack/filebeat/input/http_endpoint    0.006s
FAIL

Failing Test

go
package http_endpoint

import (
    "net/http"
    "testing"

    "github.com/stretchr/testify/require"
)

func TestValidateRejectsInvalidOptionsResponseCodeForEmptyOptionsHeaders(t *testing.T) {
    c := defaultConfig()
    c.OptionsHeaders = http.Header{}
    c.OptionsStatus = 0

    err := c.Validate()
    require.Error(t, err, "config with non-nil options_headers should validate options_response_code")
    require.Contains(t, err.Error(), "options_response_code must be a valid HTTP status code: 0", "error should explain invalid options_response_code")
}

Evidence

  • x-pack/filebeat/input/http_endpoint/config.go:129 validates options_response_code only when len(c.OptionsHeaders) > 0.
  • x-pack/filebeat/input/http_endpoint/validate.go:121-124 allows OPTIONS whenever optionsHeaders != nil (empty map still passes this check).
  • x-pack/filebeat/input/http_endpoint/handler.go:107-112 writes h.validator.optionsStatus directly for OPTIONS requests.
  • x-pack/filebeat/input/http_endpoint/config.go:124-126 already documents that out-of-range status codes panic in net/http, so skipping validation here is unsafe.

What is this? | From workflow: Bug Hunter

Give us feedback! React with if perfect, if helpful, if not.

  • expires on Sep 25, 2026, 11:19 AM UTC