scgi_param  REQUEST_METHOD     $request_method;
scgi_param  REQUEST_URI        $request_uri;
scgi_param  QUERY_STRING       $query_string;
scgi_param  CONTENT_TYPE       $content_type;

scgi_param  DOCUMENT_URI       $document_uri;
scgi_param  DOCUMENT_ROOT      $document_root;
scgi_param  SCGI               1;
scgi_param  SERVER_PROTOCOL    $server_protocol;
scgi_param  REQUEST_SCHEME     $scheme;
scgi_param  HTTPS              $https if_not_empty;

scgi_param  REMOTE_ADDR        $remote_addr;
scgi_param  REMOTE_PORT        $remote_port;
scgi_param  SERVER_PORT        $server_port;
scgi_param  SERVER_NAME        $server_name;

# !!! Security workaround !!!
# Do not use HTTP_HOST as "$http_host".
#
# "$http_host" is the Host header exactly as supplied by the client.
# This is unsafe when a client sends an absolute-form request target together
# with a different Host header, for example:
#
#     GET https://example.com/ HTTP/1.1
#     Host: malformedhost
#
# In such a case, passing "$http_host" upstream exposes the raw client-supplied
# Host value ("malformedhost") to the backend application, even though it does
# not match the effective request target. Applications often use HTTP_HOST for
# redirects, absolute URL generation, virtual host routing, or security checks;
# forwarding the raw Host header can therefore lead to incorrect or unsafe
# behaviour.
#
# Newer nginx versions (since 1.30.0) introduce variables "$is_request_port" and
# "$request_port", allowing HTTP_HOST to be constructed as:
#     $host$is_request_port$request_port
#
# In stable/oldstable packages we use "$host" as a security workaround.
# It avoids forwarding an untrusted raw Host header to the backend.
#
# Note: this changes behaviour compared to previous versions, because "$host"
# does not preserve the client-supplied port, while "$http_host" typically
# does. Existing deployments that rely on "$http_host" containing a port number
# may therefore break or behave differently after this change.

scgi_param  HTTP_HOST        $host;