[Rust Frontend] Add /server_info to Rust frontend

[Xunzhuo]

Summary

Adds /server_info to the Rust HTTP frontend alongside the existing /version route.

The endpoint follows the Python frontend's top-level response shape with vllm_config, vllm_env, and system_env. It returns a text config snapshot by default and supports ?config_format=json for structured config fields.

Tests

• cargo fmt --all --check (from rust/)
• git diff --check
• cargo check -p vllm-server --tests (from rust/)
• cargo test -p vllm-server version_returns_engine_vllm_version -- --nocapture (from rust/)
• cargo test -p vllm-server server_info_endpoint -- --nocapture (from rust/)

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Adds a new /server_info endpoint that returns a snapshot of server configuration and environment metadata for debugging/inspection.

Changes:

• Introduced ServerInfoSnapshot + ServerInfoConfigFormat and wired them into AppState.
• Added /server_info Axum route with config_format query parameter (text default, json optional).
• Added route tests validating default (text) and requested (json) config formats.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
rust/src/server/src/state.rs	Adds server info snapshot model, env collection helpers, and exposes /server_info response via AppState.
rust/src/server/src/routes/server_info.rs	Implements the /server_info handler and query param parsing.
rust/src/server/src/routes.rs	Registers the new /server_info route.
rust/src/server/src/lib.rs	Populates AppState with a config-derived ServerInfoSnapshot.
rust/src/server/src/routes/tests.rs	Adds endpoint tests for default and json config formats.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[depthfirst-app]

🟡 Severity: MEDIUM

Unlike the Python equivalent which iterates over a curated whitelist of ~240 known attributes in the vllm.envs module, this function reads all OS environment variables matching VLLM_*. Any custom deployment-set env var (e.g. VLLM_AUTH_TOKEN, VLLM_DB_PASSWORD) that doesn't contain "KEY" in its name would be leaked through the unauthenticated /server_info endpoint.
Helpful? Add 👍 / 👎

💡 Fix Suggestion

Suggestion: The collect_vllm_env() function reads ALL OS environment variables matching VLLM_*, unlike the Python equivalent which only iterates over a curated whitelist of ~240 known attributes defined in vllm.envs. Any deployment-custom env var (e.g. VLLM_AUTH_TOKEN, VLLM_DB_PASSWORD) that doesn't contain "KEY" in its name would be leaked through the unauthenticated /server_info endpoint.

The ideal fix is to replicate the Python behavior by maintaining an explicit allowlist of known VLLM environment variable names (the ~240 variables defined in vllm/envs.py), and only exposing those. This is a larger change requiring an allowlist constant to be kept in sync with the Python vllm.envs module.

As an immediate improvement, enhance the denylist filter to exclude additional common sensitive patterns such as SECRET, TOKEN, PASSWORD, CREDENTIAL, and AUTH. This reduces the attack surface but is not as robust as the allowlist approach.

⚠️ Experimental Feature: This code suggestion is automatically generated. Please review carefully.

Suggested change

	fn collect_vllm_env() -> BTreeMap<String, String> {
	std::env::vars()
	.filter(|(key, _)| key.starts_with("VLLM_") && !key.contains("KEY"))
	fn collect_vllm_env() -> BTreeMap<String, String> {
	const SENSITIVE_PATTERNS: &[&str] = &[
	"KEY", "SECRET", "TOKEN", "PASSWORD", "CREDENTIAL", "AUTH",
	];
	std::env::vars()
	.filter(|(key, _)| {
	key.starts_with("VLLM_")
	&& !SENSITIVE_PATTERNS.iter().any(|pat| key.contains(pat))
	})
	.collect()
	}

[depthfirst-app]

⚪ Severity: LOW

Unlike the Python equivalent (which reads only known declared attrs from vllm.envs — an allowlist), this reads all process env vars prefixed with VLLM_ and applies a key-name denylist. Custom operator env vars whose names don't match the denylist patterns (e.g. VLLM_DB_URL=postgres://user:pass@host/db) would have their values exposed through the /server_info endpoint.
Helpful? Add 👍 / 👎

💡 Fix Suggestion

Suggestion: Switch from a denylist approach to an allowlist approach, matching the Python frontend's behavior. Instead of reading all process env vars prefixed with VLLM_ and filtering out sensitive patterns, define an explicit allowlist of known safe VLLM environment variable names (mirroring the attributes declared in vllm/envs.py). This way, only recognized configuration env vars are exposed, and arbitrary operator-set env vars like VLLM_DB_URL with credential-bearing values won't leak.

Concretely:

1. Define a const KNOWN_VLLM_ENV_KEYS: &[&str] containing the recognized public VLLM environment variable names (e.g., VLLM_LOGGING_LEVEL, VLLM_USE_MODELSCOPE, etc.).
2. Change collect_vllm_env() to only read those specific keys from the environment rather than iterating all env vars.
3. Keep the sensitive pattern check as a defense-in-depth secondary filter.

Alternatively, as a minimal improvement, also scan the env var values for common credential patterns (e.g., ://...@ URI patterns) before including them in the output.

[BugenZhao]

What about also moving the construction-related logic into a separate module?

[BugenZhao]

I think it would be better to derive Serialize to replace these manually implemented conversions.

[mergify]

This pull request has merge conflicts that must be resolved before it can be
merged. Please rebase the PR, @Xunzhuo.

https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork

[depthfirst-app]

⚪ Severity: LOW

Unlike the Python frontend, which reads from a curated envs module (allowlist), this reads all process VLLM_* env vars and applies a denylist. Env vars whose names don't contain KEY/SECRET/TOKEN/PASSWORD/CREDENTIAL/AUTH but whose values carry secrets (e.g., VLLM_PROXY=http://user:pass@host, connection-string style vars) will be served to any unauthenticated client with dev-mode access.
Helpful? Add 👍 / 👎

💡 Fix Suggestion

Suggestion: Switch from a denylist approach to an allowlist approach to match the Python frontend's behavior. The Python frontend reads only from explicitly defined variables in vllm/envs.py (via dir(envs)), which acts as a curated allowlist. The current Rust implementation reads all VLLM_* process env vars and only excludes names containing sensitive keywords, which can leak secrets embedded in values (e.g., VLLM_PROXY=http://user:pass@host).

To fix this, define a static allowlist of known safe VLLM_* env var names (mirroring the keys defined in vllm/envs.py), and only collect env vars whose names appear in that allowlist. For example:

const KNOWN_PUBLIC_VLLM_ENV_KEYS: &[&str] = &[
    "VLLM_HOST_IP",
    "VLLM_PORT",
    "VLLM_USE_MODELSCOPE",
    "VLLM_LOGGING_LEVEL",
    "VLLM_CONFIGURE_LOGGING",
    "VLLM_TARGET_DEVICE",
    "VLLM_SERVER_DEV_MODE",
    // ... add all non-sensitive VLLM_* keys from vllm/envs.py
];

fn collect_vllm_env() -> BTreeMap<String, String> {
    std::env::vars()
        .filter(|(key, _)| {
            let upper = key.to_ascii_uppercase();
            KNOWN_PUBLIC_VLLM_ENV_KEYS.contains(&upper.as_str())
        })
        .collect()
}

Alternatively, at minimum, also filter values for patterns that may embed credentials (e.g., URLs containing @ after ://), though an allowlist is the more robust approach.

[mergify]

This pull request has merge conflicts that must be resolved before it can be
merged. Please rebase the PR, @Xunzhuo.

https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork

[BugenZhao]

Hi @Xunzhuo I've pushed a commit to simplify the implementation more by directly deriving Serialize on existing structures.

[BugenZhao]

LGTM. Thanks!