httpd(8) gains support for custom HTTP headers

In a change likely to be widely welcomed, Rafael Sadowski (rsadowski@) committed support for custom HTTP headers in httpd(8). This obviates the need to use FastCGI support or relayd(8) to achieve things like adding SSL/TLS security headers.

The commit reads:

CVSROOT:	/cvs
Module name:	src
Changes by:	rsadowski@cvs.openbsd.org	2026/07/24 23:48:39

Modified files:
	usr.sbin/httpd : config.c httpd.c httpd.conf.5 httpd.h parse.y 
	                 server.c server_fcgi.c server_http.c 

Log message:
httpd: add custom HTTP header support

Allow httpd.conf to set/add/remove custom HTTP response headers or Suppress
existing ones. This enables httpd to add security headers, custom metadata,
or remove unwanted headers without modifying app/fastcgi code.

Three new directives are added:

header option
Manipulate HTTP response headers.  Multiple header statements may
be specified.  Valid options are:

set name value [always]
Set a custom HTTP response header with the specified name
and value.  If a header with the same name is already
present in the response, its value will be replaced.  The
header is added to successful responses (2xx and 3xx
status codes) by default.

add name value [always]
Add a custom HTTP response header with the specified name
and value.  Unlike set, this option appends the header
even if one with the same name already exists, allowing
for multiple headers with the same name.  The header is
added to successful responses (2xx and 3xx status codes)
by default.

remove name [always]
Suppress the HTTP response header with the specified
name.  This can be used to remove headers added by
default, such as "Last-Modified", as well as headers
inherited from a parent server configuration.

If always is specified, the header is also added to error
responses (4xx and 5xx).

Header names are limited to 256 characters and values to 8192
characters.  Headers defined in a location block are inherited
from the server context and override defined headers with the
same name.  If you do not wish to inherit these, you can remove
them again with remove.

Example configuration:

server "example.com" {
listen on * tls port 443

header set "X-Content-Type-Options" "nosniff" always
header set "X-Frame-Options" "SAMEORIGIN" always
header set "Referrer-Policy" "no-referrer" always
header set "X-Permitted-Cross-Domain-Policies" "none" always
header set "X-XSS-Protection" "0" always

# Avoid info leak: strip the revealing header
header remove "X-Powered-By"

location "/api/*" {
header add "Access-Control-Allow-Origin" "https://app.example.com"
header add "Access-Control-Allow-Methods" "GET, POST, OPTIONS"

# Enforce cookie flags
header set "Set-Cookie" "id=5; HttpOnly; Secure; SameSite=Strict"

# Framing is irrelevant for a JSON API, drop from server context
header remove "X-Frame-Options"

# APIs should not be cached
header set "Cache-Control" "no-store" always
}
}

The implementation follows the existing pattern form FastCGI parameters.

Feedback and help from sthen@, claudio@, op@, kirill@ and many others.

OK op@ kirill@

As always, we encourage readers to test and play with the new features, and report back on your experience.

We are convinced that this change will be very welcome in a large chunk of our community.