--model Qwen/Qwen3-0.6B fails against the real hub. Measured 20 August 2026 with the binary built from a50c57d69, TLS on, HF_HOME pointed at an empty cache:
server: fatal: vllm.cpp: HF_ENDPOINT '/api/resolve-cache/models/Qwen/Qwen3-0.6B/c1899de289a04d12100db370d81485cdf75e47ca/config.json?%2FQwen%2FQwen3-0.6B%2Fresolve%2Fc1899de289a04d12100db370d81485cdf75e47ca%2Fconfig.json=&etag=%22f5c3703b78ae2a478ae15b247e9f855e0ce2107b%22' has no scheme; expected http:// or https://
Nothing was downloaded. The cache holds 24 KB of metadata and no weights.
Cause
HuggingFace answers the resolve request with a redirect whose Location is a relative reference, /api/resolve-cache/models/..., not an absolute URL. RFC 7231 section 7.1.2 permits that, and the hub uses it.
src/vllm/transformers_utils/downloader.cpp:376 and :526 both assign current = location with no resolution against the URL the redirect answered. The next iteration then parses a path as though it were a URL and the parser correctly refuses it, reporting the path as though the user had misconfigured HF_ENDPOINT.
Why no test caught it
set_follow_location(true) was deliberately removed in #1485, because httplib copies the whole request across a redirect including the Authorization header, which leaked the bearer token to whatever host the redirect named. The manual redirect loop that replaced it is correct about the token and wrong about relative targets.
Every hermetic fixture in tests/vllm/transformers_utils/ serves an absolute Location, so the suites cover the loop but not the shape the real hub sends. This is the first time this tree has fetched from huggingface.co rather than from an in-process fake, and it failed on the first attempt.
Fix
Resolve a Location against the URL that produced it, per RFC 3986 section 5. Both forms the hub can send need covering: an absolute-path reference beginning with /, and a relative-path reference. An absolute URL must keep working unchanged.
The token rule must survive the fix: a redirect that crosses to a different host must still not carry the Authorization header. Resolving a relative target against the current URL keeps the host the same, so the common case is unaffected, but the cross-host guard has to stay.
The red-first case is a fake hub that answers with a relative Location, which no current fixture does.
Severity
This blocks the feature end to end. --model org/repo works against any endpoint that redirects absolutely, including every hermetic test, and does not work against the hub it was built for.
--model Qwen/Qwen3-0.6Bfails against the real hub. Measured 20 August 2026 with the binary built froma50c57d69, TLS on,HF_HOMEpointed at an empty cache:Nothing was downloaded. The cache holds 24 KB of metadata and no weights.
Cause
HuggingFace answers the resolve request with a redirect whose
Locationis a relative reference,/api/resolve-cache/models/..., not an absolute URL. RFC 7231 section 7.1.2 permits that, and the hub uses it.src/vllm/transformers_utils/downloader.cpp:376and:526both assigncurrent = locationwith no resolution against the URL the redirect answered. The next iteration then parses a path as though it were a URL and the parser correctly refuses it, reporting the path as though the user had misconfiguredHF_ENDPOINT.Why no test caught it
set_follow_location(true)was deliberately removed in #1485, because httplib copies the whole request across a redirect including theAuthorizationheader, which leaked the bearer token to whatever host the redirect named. The manual redirect loop that replaced it is correct about the token and wrong about relative targets.Every hermetic fixture in
tests/vllm/transformers_utils/serves an absoluteLocation, so the suites cover the loop but not the shape the real hub sends. This is the first time this tree has fetched fromhuggingface.corather than from an in-process fake, and it failed on the first attempt.Fix
Resolve a
Locationagainst the URL that produced it, per RFC 3986 section 5. Both forms the hub can send need covering: an absolute-path reference beginning with/, and a relative-path reference. An absolute URL must keep working unchanged.The token rule must survive the fix: a redirect that crosses to a different host must still not carry the
Authorizationheader. Resolving a relative target against the current URL keeps the host the same, so the common case is unaffected, but the cross-host guard has to stay.The red-first case is a fake hub that answers with a relative
Location, which no current fixture does.Severity
This blocks the feature end to end.
--model org/repoworks against any endpoint that redirects absolutely, including every hermetic test, and does not work against the hub it was built for.