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/valyala/fasthttp 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.

GO — Healthy across the board

• Last commit 4d ago
• 13 active contributors
• MIT licensed
• CI configured
• Tests present
• ⚠ Concentrated ownership — top contributor handles 50% of recent commits

_{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 valyala/fasthttp repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/valyala/fasthttp.

What it runs against: a local clone of valyala/fasthttp — 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 valyala/fasthttp | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 34 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of valyala/fasthttp. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/valyala/fasthttp.git
#   cd fasthttp
#
# 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 valyala/fasthttp and re-run."
  exit 2
fi

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

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT 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"

# 4. Critical files exist
test -f "http.go" \\
  && ok "http.go" \\
  || miss "missing critical file: http.go"
test -f "client.go" \\
  && ok "client.go" \\
  || miss "missing critical file: client.go"
test -f "header.go" \\
  && ok "header.go" \\
  || miss "missing critical file: header.go"
test -f "bytesconv.go" \\
  && ok "bytesconv.go" \\
  || miss "missing critical file: bytesconv.go"
test -f "args.go" \\
  && ok "args.go" \\
  || miss "missing critical file: args.go"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 34 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~4d)"
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/valyala/fasthttp"
  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).

fasthttp is a high-performance HTTP server and client library for Go that eliminates memory allocations in hot code paths and achieves up to 10x faster throughput than net/http. It's specifically optimized for handling thousands of small-to-medium requests per second with consistent low-millisecond latency, proven in production serving 200K requests per second from 1.5M concurrent keep-alive connections. Flat monorepo structure: core HTTP implementation files (client.go, server.go, request.go, response.go) at the root, utility modules (args.go for query parsing, cookie.go for cookie handling, compress.go for compression, coarsetime.go for low-overhead timing), platform-specific bytesconv files (bytesconv_32.go, bytesconv_64.go), comprehensive test files, and examples/ directory with runnable servers (helloworldserver, fileserver, client, host_client).

Backend engineers and DevOps teams building high-throughput HTTP services (API gateways, microservices, reverse proxies, load balancers) who need edge-case performance optimization and can tolerate non-standard Go HTTP interfaces. Not recommended for typical CRUD web applications where net/http suffices.

Production-ready and actively maintained. The project is battle-tested (TechEmpower top-ranked, VertaMedia production deployment), includes comprehensive test coverage (allocation_test.go, client_test.go, cookie_test.go, compress_test.go), has CI/CD via GitHub Actions (.github/workflows/test.yml, lint.yml, security.yml), and targets Go 1.24. Single primary maintainer (valyala) with steady commit activity.

Low risk overall, but has architectural constraints: optimized for specific use cases (high-concurrency, simple request/response patterns), not a drop-in net/http replacement. External dependencies on compression (klauspost/compress, andybalholm/brotli) and bytebufferpool add supply-chain surface area. Single primary maintainer creates bus-factor risk, though the codebase is stable and well-documented.

Actively maintained with focus on performance and security. The CI/CD pipeline runs lint, security, fuzzing (cifuzz.yml), and tests on every change. Go version constraint recently bumped to 1.24. Dependabot configured for automated dependency updates. No visible breaking changes in recent commits; development is incremental optimization and bug fixes.

git clone https://github.com/valyala/fasthttp.git
cd fasthttp
go mod download
go test -bench=. -benchmem  # Run benchmarks
go run examples/helloworldserver/helloworldserver.go  # Start example server

Daily commands: Clone and test: go test ./... runs all tests. Examples: go run examples/helloworldserver/helloworldserver.go (port 8080 by default), go run examples/client/client.go (makes HTTP requests), go run examples/fileserver/fileserver.go (serves static files). No dev server; use go test -bench= for performance validation.

• http.go — Core HTTP server and request/response handling logic; defines the primary Server type and request handler interface that all endpoints depend on
• client.go — HTTP client implementation with connection pooling and keep-alive management; essential for understanding fasthttp's client-side architecture
• header.go — Header parsing and manipulation with zero-allocation optimizations; critical path for HTTP message processing
• bytesconv.go — Byte/string conversion utilities with platform-specific optimizations; foundational for avoiding allocations throughout the codebase
• args.go — Query argument and form data parsing with zero-copy techniques; handles URL parameter extraction and manipulation
• compress.go — Compression handling (gzip, deflate, brotli); manages request/response body compression for performance
• fs.go — Static file serving implementation; demonstrates efficient resource handling for common HTTP use case

Add a custom HTTP request handler

1. Implement a function matching RequestHandler signature (func(*RequestCtx)) (http.go)
2. Register handler with Server.ListenAndServe() or Server.RequestHandler (http.go)
3. Parse query args via ctx.QueryArgs().Get(key) or form data via ctx.PostArgs() (args.go)
4. Access request headers with ctx.Request.Header.Peek(name) and set response headers with ctx.Response.Header.Set() (header.go)
5. Write response body to ctx.SetBody() or ctx.SetBodyStream() (http.go)

Add static file serving with caching

1. Create a FS instance with FS{Root: '/path/to/files'} and optional compression settings (fs.go)
2. Register handler by passing fs.NewRequestHandler() to Server or wrapping in RequestHandler (fs.go)
3. Configure compression in FS struct (GenerateIndex, Compress, CompressedFileSuffixes) (fs.go)
4. Adjust caching via FS.CacheDirListings, CacheExpire, and other cache fields (fs.go)

Add compression to responses

1. Detect Accept-Encoding header from ctx.Request.Header.Peek('Accept-Encoding') (header.go)
2. Set Content-Encoding response header and compress body using CompressDeflate, CompressGzip, or CompressBrotli (compress.go)
3. Alternatively use FS compression for static files (CompressGzip, CompressBrotli fields) (fs.go)
4. Test compression with -H 'Accept-Encoding: gzip' curl requests (compress_test.go)

Add connection pooling for upstream HTTP calls

1. Create a Client instance (default or custom with custom dialer via Dial field) (client.go)
2. Reuse same Client instance across requests to benefit from connection pooling (MaxConns, MaxIdleConnDuration) (client.go)
3. Configure pool settings: MaxConns, MaxIdleConnDuration, MaxConnDuration, DisableHeaderNamesNormalizing (client.go)
4. Execute requests via client.Do(req, resp) within your handler (client.go)
5. For multiple hosts, use LBClient with custom HostClientFactory for load-balanced pooling (lbclient.go)

• Go 1.24+ — Efficient goroutines and memory management; fasthttp's zero-alloc design leverages Go's escape analysis and stack allocation
• bytebufferpool (valyala) — Reusable buffer pool reduces GC pressure by recycling byte buffers across high-volume requests
• brotli & klauspost/compress — Pluggable compression backends; brotli for highest compression ratio, klauspost for faster gzip/deflate
• golang.org/x/net, x/crypto, x/sys — Cross-platform networking primitives and TLS support; x/sys for syscall optimizations (TCP tuning)

• Unsafe pointer conversions (b2s.go) for zero-alloc string↔byte conversions

  • Why: Avoid allocations in hot paths; fasthttp targets sub-millisecond latency at 200K rps scales
  • Consequence: Risk of memory unsafety if buffer is modified; requires careful lifetime management

• Manual connection pooling and keep-alive instead of delegating to net.Dialer

  • Why: Fine-grained control over pool size, idle timeout, and per-host connection limits
  • Consequence: More complex client code; developers must manage pool lifecycle and reuse

• Coarse-grained time tracking (coarsetime.go) instead of time.Now()

  • Why: time.Now() syscall is too expensive at extreme request rates; ~5–10x slower
  • Consequence: Less precise timing; eventual consistency in timeout calculations

• No built-in middleware/routing framework (unlike net/http ecosystem)

  • Why: Minimize allocations and abstraction overhead; let users compose handlers as needed
  • Consequence: Requires manual routing logic or third-party router; less ergonomic than net/http mux

• Request-scoped objects (Request, Response) reused across requests via sync.Pool

  • Why: Amortize allocation cost and reduce GC pressure at scale
  • Consequence: Objects must be released and cannot be safely used after handler returns; can cause subtle bugs

• HTTP/2 or HTTP/3 support (fasthttp focuses on HTTP/1.1 keep-alive performance)
• Automatic request routing and middleware framework (users compose manually or integrate external routers)
• Integration with net/http standard library handlers (fasthttpadaptor bridge available, but not native)
• Graceful shutdown primitives (server shutdown is abrupt; users must implement SIG handling)
• Built-in authentication, session management, or CORS (scope limited

Memory pooling via sync.Pool can mask leaks if buffers aren't released; check RequestHandler signatures carefully. bytesconv uses unsafe pointers for string/slice casting—behavior differs between 32-bit (bytesconv_32.go) and 64-bit (bytesconv_64.go) platforms. Request/Response structs are not concurrency-safe and must not be accessed across goroutines without synchronization. The library aggressively reuses buffers, so holding references to Request/Response data beyond the handler returns causes data corruption. Compression negotiation in compress.go depends on Accept-Encoding headers; missing headers default to no compression.

• Zero-copy string/bytes conversions (unsafe pointers) — fasthttp's core optimization strategy; bytesconv.go uses unsafe.Pointer casts to avoid allocations when converting between []byte and string, critical to understanding why the library is fast but requires careful buffer management
• sync.Pool buffer pooling — fasthttp reuses Request/Response objects and buffers via sync.Pool (via bytebufferpool) to reduce GC pressure; essential to understanding memory allocation patterns and why buffers must be released promptly
• Coarse-grained (cached) time.Time updates — coarsetime.go avoids expensive time.Now() syscalls by caching timestamps updated in background goroutine; demonstrates low-level syscall avoidance techniques critical for high-throughput servers
• HTTP pipelining and keep-alive connection reuse — fasthttp's goroutine-per-connection model with persistent TCP streams enables pipelining; benchmarks show dramatic wins with keep-alive (BenchmarkNetHTTPServerGet10KReqPerConn), making this architectural choice critical
• Platform-specific integer conversions (32-bit vs 64-bit) — bytesconv_32.go and bytesconv_64.go implement different algorithms for byte-to-integer conversion; Go's compiler isn't always smart enough, so explicit platform-specific code yields 10-50% speed wins on hot paths
• Streaming compression codecs (Brotli, Deflate, Zstd) — compress.go integrates multiple compression libraries and negotiates via Accept-Encoding headers; choosing the right codec and streaming (chunked writes) vs. full buffering affects latency and memory use
• Escape analysis and inlining hints — fasthttp code is written to cooperate with Go's escape analysis (small functions, early returns); understanding this is necessary to avoid accidentally triggering heap allocations in otherwise zero-alloc code paths

• valyala/bytebufferpool — Direct dependency used by fasthttp for zero-allocation buffer pooling; understanding this is essential to fasthttp's performance strategy
• valyala/router — Companion router library optimized for fasthttp; commonly paired with fasthttp servers for request routing
• valyala/tcplisten — TCP listener library from same author, tuned for high-concurrency server setup complementary to fasthttp
• golang/net — Standard library net/http that fasthttp benchmarks against; understanding tradeoffs requires reading both
• fasthttp/router — Community router library built specifically for fasthttp API patterns

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 benchmarks for fasthttp vs net/http in examples/

The README claims 'Up to 10x faster than net/http' but there's no included benchmark example that users can run to verify this claim. Currently, only timing tests exist (client_timing_test.go, args_timing_test.go, etc.) but no standalone example that compares fasthttp directly against net/http with realistic workloads. This would help new contributors understand performance characteristics and serve as a reference implementation.

• [ ] Create examples/benchmark/ directory with a Go program that serves identical requests via both fasthttp and net/http
• [ ] Measure throughput, latency percentiles, and memory allocations for both implementations
• [ ] Include a README documenting how to run the benchmark and interpret results
• [ ] Add flags to customize request sizes, concurrency levels, and duration to match the '10x faster' claim conditions

Add integration tests for fasthttpadaptor/ with real net/http middleware

The fasthttpadaptor/ package exists to bridge fasthttp with net/http ecosystems, but fasthttpadaptor/adaptor_test.go only has minimal unit tests. There are no integration tests showing real-world scenarios like using fasthttp with popular net/http middleware (compression handlers, CORS, logging). This would increase confidence in the adaptor's correctness and catch edge cases.

• [ ] Review existing tests in fasthttpadaptor/adaptor_test.go and identify gaps
• [ ] Create fasthttpadaptor/integration_test.go with tests for: net/http.Handler wrapping, request/response header propagation, streaming bodies, and chunked transfer encoding
• [ ] Add test cases using mock net/http middleware chains (e.g., stacking multiple handlers)
• [ ] Document known limitations or gotchas in fasthttpadaptor/README.md if missing

Add missing cookie security feature tests in cookie_test.go

The cookie.go file handles HTTP cookies, and cookie_test.go exists, but comparing against OWASP cookie security best practices (SameSite enforcement, secure flag propagation, HttpOnly validation across edge cases) reveals gaps. The SECURITY.md exists but doesn't detail cookie security guarantees. New contributors should add tests validating that cookie handling is secure by default.

• [ ] Review cookie.go for SameSite, Secure, and HttpOnly attribute handling
• [ ] Add tests in cookie_test.go for: SameSite enforcement (Strict/Lax/None), Secure flag with HTTPS/HTTP, HttpOnly serialization, and cookie domain/path validation edge cases
• [ ] Add a test for cookie parsing from malformed Set-Cookie headers to ensure no security bypasses
• [ ] Update SECURITY.md with a 'Cookie Security' section documenting fasthttp's guarantees

• Add comprehensive benchmarks for cookie parsing performance (cookie_test.go exists but cookie_timing_test.go could be expanded with edge cases like very large numbers of cookies, special characters, and domain/path combinations)
• Extend args_timing_test.go to include pathological cases: deeply nested query parameters, very long parameter names, duplicate keys, and percent-encoding edge cases to identify performance cliffs
• Add missing allocation tests in allocation_test.go for the compress.go codecs (brotli and deflate streaming paths) to verify zero-allocation claims under compression negotiation

The fasthttp project has a solid security posture as a low-level HTTP library with minimal dependencies. However, there are areas for improvement: (1) Cryptographic and network dependencies should be updated to the latest versions to address potential vulnerabilities, (2) The security policy documentation is incomplete and should define clear vulnerability handling procedures and supported versions, (3) Security reporting relies on a single contact point which creates a potential bottleneck, and (4) Security best practice documentation for HTTP implementation is lacking. No hardcoded credentials, SQL injection vectors, or infrastructure issues were identified. The project follows Go security guidelines but should strengthen its dependency management and security communication practices.

• Medium · Outdated Go Toolchain Version — go.mod. The project specifies Go 1.24.0 with toolchain go1.24.1, but the go.mod file shows these are development versions. This may expose the project to unpatched vulnerabilities in older Go runtime versions. Regular security updates are critical for cryptographic operations and network handling. Fix: Regularly update to the latest stable Go release and monitor Go security advisories at https://go.dev/security. Consider using a stable release instead of development versions for production dependencies.
• Medium · Outdated Cryptographic Dependencies — go.mod (golang.org/x/crypto, golang.org/x/net). golang.org/x/crypto v0.48.0 and golang.org/x/net v0.50.0 are not the latest versions. These packages handle critical security functions including TLS, certificate validation, and network protocols. Outdated versions may contain known vulnerabilities. Fix: Update to the latest versions: run 'go get -u golang.org/x/crypto@latest golang.org/x/net@latest'. Subscribe to security mailing lists for these packages and maintain regular update schedules.
• Low · Limited Security Disclosure Information — SECURITY.md. The SECURITY.md file is incomplete (truncated at 'Our project uses the following disclosure process:'). The security policy lacks critical information about vulnerability response timelines, patch release procedures, and supported versions. Fix: Complete the SECURITY.md file with: 1) Supported versions and patch policies, 2) Expected timeline for patches, 3) Public disclosure timeline, 4) Links to security advisories/CVE tracking.
• Low · Single Point of Contact for Security Reports — SECURITY.md. Security vulnerabilities are reported to a single email (erik@dubbelboer.com). If this account is compromised or unavailable, there's no fallback for critical security reports. Fix: Establish a security team with multiple contacts. Consider using a dedicated security email alias (security@valyala.com) that can be managed by multiple maintainers. Add PGP public key for encrypted communications.
• Low · No Security Headers Documentation — examples/ directory, documentation. As an HTTP library, fasthttp should provide guidance on implementing security headers. No documentation found regarding HSTS, CSP, X-Content-Type-Options, or other HTTP security headers in examples. Fix: Add security-focused examples demonstrating: 1) Proper HTTP security header implementation, 2) TLS/HTTPS configuration best practices, 3) Input validation and sanitization patterns.

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.