If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/libcpr/cpr shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Mixed signals — read the receipts

• Last commit 6d ago
• 21+ active contributors
• Other licensed
• CI configured
• Tests present
• ⚠ Concentrated ownership — top contributor handles 56% of recent commits
• ⚠ Non-standard license (Other) — review terms

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live libcpr/cpr repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/libcpr/cpr.

What it runs against: a local clone of libcpr/cpr — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in libcpr/cpr | Confirms the artifact applies here, not a fork | | 2 | License is still Other | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | Last commit ≤ 36 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of libcpr/cpr. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/libcpr/cpr.git
#   cd cpr
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of libcpr/cpr and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "libcpr/cpr(\\.git)?\\b" \\
  && ok "origin remote is libcpr/cpr" \\
  || miss "origin remote is not libcpr/cpr (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Other)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Other\"" package.json 2>/dev/null) \\
  && ok "license is Other" \\
  || miss "license drift — was Other at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 36 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~6d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/libcpr/cpr"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

libcpr is a C++17 wrapper around libcurl that provides a Python Requests-inspired API for making HTTP calls. It simplifies network requests by abstracting curl's complex easy interface into expressive C++ idioms, supporting authentication, parameters, multipart uploads, cookies, proxies, and async operations. Single library structure: root CMakeLists.txt orchestrates builds; cpr/ directory contains ~50 implementation files (auth.cpp, cookies.cpp, multipart.cpp, async.cpp, etc.) mirroring feature domains; cmake/ holds build config and external dependencies (mbedTLS, libpsl, zlib, mongoose); .github/workflows/ defines CI pipeline for multiple platforms and package formats (deb, nuget).

C++ developers building applications that need HTTP clients without wrestling with libcurl's low-level API. Primarily backend engineers, systems programmers, and library authors who want Pythonic request syntax in C++.

Production-ready and actively maintained. The project is on version 1.14.x (stable) with master branch targeting C++17. CI/CD is comprehensive (clang-format, clang-tidy, cppcheck workflows), indicating professional quality standards. Maintained by Fabian Sauter and Kilian Traub with active gitter community support.

Low risk for maintained code, but single-maintainer vulnerability exists (two maintainers reduce but don't eliminate bus-factor risk). Hard dependency on libcurl means security issues there impact this. Breaking changes from C++11 (≤1.9.x) to C++17 (1.10+) indicate version migration challenges. Check issue backlog and last commit date for activity verification.

Active maintenance visible through CI workflows for clang-format enforcement, static analysis (clang-tidy, cppcheck), and multi-platform builds. Recently added nuget and deb package builds. The dependabot.yml suggests dependency updates are being monitored. Focus appears to be on code quality and binary distribution rather than major feature additions.

git clone https://github.com/libcpr/cpr.git
cd cpr
mkdir build && cd build
cmake .. -DCMAKE_BUILD_TYPE=Release
make -j$(nproc)
make install

Daily commands: This is a library, not a runnable application. To verify build: cd build && ctest (runs unit tests). To use in your project: #include <cpr/cpr.h> after installation, then link against libcpr. See README.md example for minimal HTTP GET request.

• cpr/cpr.h: Main public header file; defines the API surface that users interact with (Get, Post, Response, etc.)
• cpr/curlholder.cpp: Core RAII wrapper around libcurl's CURL* handle; manages curl initialization and cleanup
• cpr/multiperform.cpp: Handles async multi-request execution via curl_multi API; critical for concurrent operations
• cpr/connection_pool.cpp: Manages reusable curl handles; optimizes performance for repeated requests
• CMakeLists.txt: Root build configuration; controls all targets, dependencies (libcurl, mbedTLS, zlib), and platform-specific logic
• .github/workflows/ci.yml: Primary CI pipeline; defines test matrix for Linux, macOS, Windows with multiple compilers and C++ standards
• cpr/auth.cpp: Implements HTTP authentication (Basic, Digest, Bearer); demonstrates parameter passing pattern

Feature additions: examine cpr/.cpp files for domain (e.g., cookies.cpp, auth.cpp, multipart.cpp). New HTTP feature? Add handler in cpr/ and expose in cpr/.h headers. Build system changes: edit CMakeLists.txt or cmake/.cmake. CI/testing: modify .github/workflows/.yml and add test files (typically paired with implementation). Code style: .clang-format and .clang-tidy enforce standards automatically.

libcurl threading model: curl handles are NOT thread-safe; use separate handles per thread or sync access. Build requires libcurl development headers (libcurl-dev on Ubuntu). Optional SSL: default uses system libcurl SSL backend; to use mbedTLS instead, pass -DCPR_USE_MBEDTLS=ON. DNS resolution in async mode (multiperform) blocks on gethostbyname; use curl's async DNS support if needed. CMake find_package() only works after install; during development, link against build directory. Windows builds need MSVC 2017+ or Clang for C++17 support.

• RAII (Resource Acquisition Is Initialization) — libcpr wraps libcurl's CURL* handle in curlholder.cpp using RAII; understanding this pattern is essential to avoid resource leaks and understand automatic handle cleanup in libcpr's destructor
• libcurl easy vs. multi interface — libcpr uses curl_easy for synchronous requests and curl_multi for async; distinguishing these two APIs in curlholder.cpp and multiperform.cpp is critical for performance tuning
• Connection pooling and handle reuse — cpr/connection_pool.cpp maintains a pool of reusable CURL handles to avoid the overhead of repeated curl_easy_init/cleanup; understanding this dramatically improves throughput in high-concurrency scenarios
• HTTP authentication schemes (Basic, Digest, Bearer, OAuth) — cpr/auth.cpp implements multiple auth schemes; knowing which scheme applies to your API (e.g., Basic for legacy, Bearer for tokens) is essential for secure request construction
• Multipart form data encoding (RFC 2388) — cpr/multipart.cpp handles file uploads and form fields; understanding boundary encoding and Content-Disposition headers is vital for correct multipart request construction
• HTTP/1.1 pipelining and HTTP/2 multiplexing — libcpr leverages libcurl's support for both; cpr/multiperform.cpp enables concurrent async requests via HTTP/2 multiplexing, reducing latency vs. sequential requests
• Certificate validation and SSL/TLS pinning — cpr/curlholder.cpp configures CA bundles and certificate verification; understanding CURLOPT_CAINFO, CURLOPT_VERIFYPEER, and pinning is critical for secure HTTPS requests

• curl/curl — The underlying libcurl C library that libcpr wraps; essential to understand curl options, error codes, and SSL backends
• chriskohlhoff/asio — Alternative async I/O library; relevant if considering non-libcurl async patterns or networking abstraction layers
• nlohmann/json — De facto standard C++ JSON library; frequently used alongside libcpr for parsing HTTP response bodies
• fmtlib/fmt — Modern C++ string formatting; useful for building URLs and request parameters in applications using libcpr
• pistacheio/pistache — C++ HTTP server framework; complements libcpr (client) for full-stack HTTP application development and testing

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive unit tests for SSL/TLS context handling (ssl_ctx.cpp)

The cpr library has SSL context management in cpr/ssl_ctx.cpp but lacks dedicated unit tests. Given that SSL/TLS is security-critical and the repo supports multiple SSL backends (OpenSSL, MbedTLS via cmake/FindMbedTLS.cmake), adding tests would prevent regressions and validate certificate validation, custom CA bundles, and client certificate authentication across different backends.

• [ ] Create tests/unit/ssl_ctx_test.cpp with test cases for certificate validation
• [ ] Add tests for custom CA bundle loading and verification
• [ ] Test client certificate (mTLS) authentication scenarios
• [ ] Validate behavior matches across OpenSSL and MbedTLS backends
• [ ] Reference cmake/FindMbedTLS.cmake to ensure cross-backend compatibility

Add integration tests for Unix domain socket functionality (unix_socket.cpp)

The cpr/unix_socket.cpp file handles Unix socket connections, a specialized use case for inter-process communication, but there are likely no dedicated integration tests. Given the platform-specific nature and the complexity of socket handling, integration tests would validate real-world usage with local services, error handling, and timeout behavior.

• [ ] Create tests/integration/unix_socket_test.cpp with test fixtures
• [ ] Add test cases for connecting to real Unix sockets with a test server (use mongoose from cmake/mongoose.CMakeLists.txt as reference)
• [ ] Test timeout and error scenarios on Unix sockets
• [ ] Validate connection pool behavior with Unix sockets (reference cpr/connection_pool.cpp)
• [ ] Add platform guards to skip tests on non-POSIX systems

Add GitHub Actions workflow for testing multiple C++ standard versions (C++17, C++20, C++23)

The README indicates C++17 as minimum standard for master, but the .github/workflows directory lacks a dedicated matrix build workflow testing multiple C++ standards. This is critical for catching breaking changes and ensuring forward/backward compatibility. The existing ci.yml likely tests only one standard.

• [ ] Create .github/workflows/cpp-standards-matrix.yml with jobs for C++17, C++20, and C++23
• [ ] Configure CMakeLists.txt flag variations (CMAKE_CXX_STANDARD) as matrix parameters
• [ ] Run core unit tests from tests/ directory for each standard version
• [ ] Include builds with both OpenSSL and MbedTLS backends (reference cmake/FindMbedTLS.cmake)
• [ ] Add workflow badge to README.md once established

• Add comprehensive HTTP/2 Server Push test coverage: cpr/multiperform.cpp and cpr/curlmultiholder.cpp handle multiplexed streams, but test files for push scenarios are sparse. Write integration tests in test/ directory exercising HTTP/2 push with the mock mongoose server.
• Improve error messages for SSL/TLS certificate validation failures: cpr/error.cpp and cpr/curlholder.cpp trap libcurl error codes, but CURLE_SSL_PEER_CERTIFICATE and related return generic text. Enhance error.cpp with detailed diagnostics (hostname mismatch, self-signed, expired) to aid debugging.
• Document connection pool tuning parameters: cpr/connection_pool.cpp exists but public API (in cpr/ headers) lacks example for MaxConnections, TTL settings. Add .md documentation with concrete benchmarks showing pool size impact on throughput for different workloads.

The libcpr codebase shows reasonable security posture as a wrapper around the mature libcurl library. However, several

• Medium · Potential Unvalidated SSL/TLS Certificate Handling — cpr/ssl_ctx.cpp, cpr/cert_info.cpp, include/cpr/ssl_ctx.h. The codebase includes SSL context configuration (ssl_ctx.cpp) and certificate info handling (cert_info.cpp). Without reviewing the actual implementation, there's a risk of improper certificate validation, hostname verification, or insecure cipher suite selection when wrapping libcurl. Fix: Review SSL/TLS implementation to ensure: 1) Certificate pinning is properly implemented if needed, 2) Hostname verification is enforced, 3) Strong cipher suites are used, 4) Expired/invalid certificates are properly rejected.
• Medium · Potential Insecure Connection Pool Management — cpr/connection_pool.cpp, cpr/curlmultiholder.cpp, include/cpr/connection_pool.h. Connection pooling in connection_pool.cpp and curlmultiholder.cpp could lead to connection reuse vulnerabilities if credentials, auth tokens, or sensitive headers are not properly isolated between different requests using pooled connections. Fix: Ensure that: 1) Connection state is properly reset between requests, 2) Sensitive headers are not leaked across pooled connections, 3) Authentication tokens are properly scoped to intended requests, 4) Connection cleanup is thorough.
• Medium · Potential Header Injection Vulnerabilities — cpr/parameters.cpp, cpr/payload.cpp, include/cpr/interface.h. The library allows custom headers and parameters (parameters.cpp, payload.cpp). If user input is not properly validated/sanitized before being used in HTTP headers, attackers could inject newline characters (\r\n) to inject arbitrary headers or split HTTP requests. Fix: Implement strict validation on all user-supplied headers and parameters: 1) Reject or escape newline characters (\r, \n), 2) Validate header names against HTTP specification, 3) Apply input sanitization before passing to libcurl.
• Medium · Potential Insecure Redirect Handling — cpr/redirect.cpp, include/cpr/redirect.h. The redirect.cpp module handles HTTP redirects. Improper redirect validation could lead to open redirect vulnerabilities or SSRF attacks if redirects to arbitrary origins are allowed without proper validation. Fix: Implement redirect validation: 1) Whitelist allowed redirect destinations, 2) Prevent redirects to different protocols (HTTP -> HTTPS is usually safe, but reverse is risky), 3) Limit redirect chain length, 4) Validate redirect URLs against whitelist if available.
• Low · Sensitive Data in Error Messages — cpr/error.cpp, include/cpr/error.h. The error.cpp and error handling throughout the codebase may inadvertently expose sensitive information (URLs with credentials, tokens, etc.) in error messages or logs. Fix: Sanitize error messages: 1) Redact URLs containing credentials before logging, 2) Avoid including full request/response bodies in errors, 3) Mask authentication tokens and sensitive headers in debug output.
• Low · Potential Integer Overflow in Size Handling — cpr/file.cpp, include/cpr/buffer.h, include/cpr/body_view.h. File operations and buffer handling (file.cpp, buffer.h) could be vulnerable to integer overflow when calculating sizes, especially when dealing with large files or responses. Fix: Add safe integer arithmetic: 1) Use safe math libraries or checked operations, 2) Validate size parameters before allocation, 3) Implement bounds checking on buffer operations.
• Low · Missing Security Headers Guidance — include/cpr/api.h, include/cpr/interface.h. The library wrapper around libcurl does not appear to enforce or guide users toward setting security-critical HTTP headers (HSTS, CSP, X-Frame-Options, etc.) by default. Fix: Add security header helper functions: 1) Provide convenience methods for common security headers, 2) Document security best practices in comments, 3) Add examples showing secure configuration.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.