Misc. bug: URL query is parsed into the host when the URL has no path
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 82/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- cpp
- Domain
- networking
Research direction
Start with common/http.h and run the provided C++ reproduction to inspect common_http_parse_url() for query-only URLs. Check the affected callers in common/download.cpp, common/hf-cache.cpp, tools/cli/cli-client.cpp, and tools/server/server-cors-proxy.h. Done means the host and query/path are parsed correctly and the query reaches HTTP requests.
Written by the indexing model from the issue text.
Description
Name and Version
$ llama-server --version
version: 0.3.0-dev (build 10797, commit 235f4e8)
Operating systems
Linux
Which llama.cpp modules do you know to be affected?
llama-cli, llama-server, libllama (core library)
Command line
llama-cli -mu 'https://example.com/model.gguf?download=1'
Problem description & steps to reproduce
Description
common_http_parse_url() in common/http.h splits the authority from the path by searching for the first /:
auto slash_pos = rest.find('/');
RFC 3986 ends the authority at the first /, ? or #, so a URL that carries a query but no path never terminates the authority. For https://example.com?download=1 the parser produces:
host -> example.com?download=1
path -> /
Two things then go wrong in common_http_client(), which builds the httplib::Client out of parts.host: the connection is attempted against a hostname that cannot resolve, and the query string is dropped from the request even if it could.
This parser is shared, so the same failure reaches every HTTP caller in the tree:
common/download.cpp (-mu / --model-url and remote GGUF fetches), common/hf-cache.cpp,
tools/cli/cli-client.cpp, and the server CORS proxy in tools/server/server-cors-proxy.h.
Query-only URLs are ordinary and commonly machine-generated, signed download links, CDN cache-busting parameters, and ?download=1-style flags, so this is hit by real endpoints rather than only by malformed input.
Repro
#include "common/http.h"
#include <iostream>
int main() {
const auto parts = common_http_parse_url("https://example.com?download=1");
std::cout << "host=" << parts.host << " path=" << parts.path << '\n';
}
g++ -std=c++17 -I. -Ivendor -Ivendor/cpp-httplib repro.cpp vendor/cpp-httplib/httplib.cpp -pthread -o repro
./repro
First Bad Commit
The find('/') split has been present since common/http.h was introduced in #16373;
Relevant log output
Logs
expected host=example.com path=?download=1
actual host=example.com?download=1 path=/
- Dominant language
- C++
- Stars
- 129k
- Forks
- 23.5k
- Avg merge
- 2d 11h
- Merged PRs (30d)
- 411
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from ggml-org/llama.cpp
-
bug-unconfirmed
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
bug-unconfirmed
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
-
bug-unconfirmed
Difficulty 1/5 Under an hour Newbie friendliness 90/100
-
/v1/responses: reasoning item with "summary": null rejected as "Cannot determine type of 'item'" Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
All issues in ggml-org/llama.cpp
Similar issues
-
Difficulty 1/5 Under an hour Newbie friendliness 90/100
AXERA-TECH/ax-llm#77 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
NVIDIA/cuda-samples#453 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
infiniflow/infinity#3502 ·
-
level/task module/gcp type/bug
Difficulty 2/5 1-3 hours Newbie friendliness 85/100