What causes "invalid --allowed-methods value {method:?}: {e}" in vllm-project/vllm?

Use standard HTTP method names only: --allowed-methods GET --allowed-methods POST (repeat the flag per method) or a properly split list.

vllm-project/vllm · error

invalid --allowed-methods value {method:?}: {e}

Error message

invalid --allowed-methods value {method:?}: {e}

What it means

Thrown by CorsConfig::validate() in the Rust server's startup validation when a --allowed-methods entry (other than "*") fails to parse as an http::Method. The server pre-validates CORS entries so the tower CORS layer can be built infallibly afterwards. The offending value and the underlying parse error are included in the message.

Source

Thrown at rust/src/server/src/config.rs:95

        }
    }
}

impl CorsConfig {
    /// Validate that non-wildcard values parse into HTTP types, so the CORS
    /// layer can be built infallibly after startup validation has run.
    pub fn validate(&self) -> Result<()> {
        for origin in &self.allow_origins {
            if origin != "*" {
                origin.parse::<HeaderValue>().map_err(|e| {
                    anyhow::anyhow!("invalid --allowed-origins value {origin:?}: {e}")
                })?;
            }
        }
        for method in &self.allow_methods {
            if method != "*" {
                method.parse::<Method>().map_err(|e| {
                    anyhow::anyhow!("invalid --allowed-methods value {method:?}: {e}")
                })?;
            }
        }
        for header in &self.allow_headers {
            if header != "*" {
                header.parse::<HeaderName>().map_err(|e| {
                    anyhow::anyhow!("invalid --allowed-headers value {header:?}: {e}")
                })?;
            }
        }
        Ok(())
    }
}

/// TLS settings mirroring Python's uvicorn `ssl_*` arguments.
#[derive(Debug, Clone, PartialEq, Eq, Serialize)]
pub struct TlsConfig {
    /// PEM certificate chain file. Required when TLS is configured; may also

View on GitHub (pinned to c794754062)

Solutions

Use standard HTTP method names only: --allowed-methods GET --allowed-methods POST (repeat the flag per method) or a properly split list.
Use "*" to allow all methods.
Trim whitespace and remove delimiters from each entry before passing them.
Check the {method:?} value in the message to see exactly which entry failed to parse.

Example fix

# before
--allowed-methods 'GET, POST,fetch'

# after
--allowed-methods GET --allowed-methods POST --allowed-methods FETCH  # note: FETCH is invalid; use real verbs
# or simply allow all:
--allowed-methods '*'

Defensive patterns

Strategy: validation

Validate before calling

fn valid_methods(methods: &[String]) -> bool {
    methods.iter().all(|m| m == "*" || m.parse::<http::Method>().is_ok())
}
// before building Config:
assert!(valid_methods(&cfg.allow_methods), "bad --allowed-methods entry");

Type guard

fn is_valid_method_list(methods: &[String]) -> bool {
    methods.iter().all(|m| m == "*" || m.parse::<http::Method>().is_ok())
}

Prevention

Emit each method as its own flag value instead of one comma-joined string.
Trim whitespace from every entry before validation.
Add a startup config lint step in CI that runs Config::validate() on the rendered args.

When it happens

Trigger: Passing --allowed-methods with a value that is not a valid HTTP method token, e.g. --allowed-methods 'GET,fetch' or --allowed-methods 'GET;' (delimiters or lowercase-with-typos like 'post ' with whitespace). Validation runs at server startup before any listener is bound; the first bad entry aborts boot.

Common situations: Copy-pasting a CORS methods list from a browser fetch preflight example (which may include custom verbs or commas), quoting the whole list as one token ('GET,POST' without splitting), or trailing whitespace/newlines in a env-derived list.

Related errors

AI-assisted analysis of vllm-project/vllm@c794754062 (2026-08-14). Data as JSON: /api/errors/e872b417471e1b49. Report an issue: GitHub.