Webship: The Most RFC-Compatible Web Server in the World

The web is held together by exact agreements. A Content-Length field must mean the same thing at every hop. A cache must not reuse a response that requires validation. A malformed HTTP/3 field section must fail at the correct scope. A safe method must stay safe after it passes through a reverse proxy.

Webship 1.3.1 is built around one rule: speed counts only when the bytes keep their meaning.

That is why we describe Webship as the most RFC-compatible general-purpose web server in the world. This is an engineering claim with a visible boundary, not a claim that every optional feature in every RFC exists. The map below names the 52 RFCs that affect Webship’s active server behavior or its owned protocol foundations. Current standards come first. Superseded documents are identified as compatibility lineage. Draft specifications are not relabeled as RFCs.

Compatibility is behavior, not a badge

Webship applies standards at the places where production servers most often become ambiguous:

• HTTP/1.1 framing rejects conflicting lengths, invalid transfer codings, oversized request targets, malformed chunks, and request-smuggling shapes.
• HTTP/2 and HTTP/3 reject forbidden connection fields, validate pseudo-fields, bound compressed field sections, and keep stream errors separate from connection errors.
• Static files preserve HEAD semantics, validators, precondition order, byte ranges, redirects, and content types.
• The reverse proxy preserves framing, cancellation, trailers, upgrades, safe retries, and forwarding identity while stripping hop-by-hop fields.
• The cache calculates age, freshness, revalidation, Vary, invalidation, and stale-use rules rather than treating caching as a key-value shortcut.
• TLS, QUIC, ACME, early data, and WebTransport use bounded state and explicit failure policy.

The same rules apply on the fast path. Webship does not define one “correct” path and a different benchmark path.

HTTP semantics, framing, caching, and proxying

• RFC 3986 — Uniform Resource Identifier (URI): Generic Syntax. Webship normalizes relative Location and Content-Location references, including dot segments, before cache invalidation decisions.
• RFC 6455 — The WebSocket Protocol. Reverse-proxy upgrades validate the WebSocket key, accept value, subprotocol, extensions, and tunnel transition.
• RFC 6585 — Additional HTTP Status Codes. Oversized request fields use the defined 431 response where an HTTP response is still possible.
• RFC 6797 — HTTP Strict Transport Security. Strict-Transport-Security is emitted only over secure transport and never leaks from a transport-neutral cache entry onto cleartext HTTP.
• RFC 7235 — HTTP/1.1 Authentication. Authentication scheme tokens are parsed case-insensitively, including the protected MCP control surface. Its general HTTP semantics now live in RFC 9110.
• RFC 7239 — Forwarded HTTP Extension. Operators can select a standards-based Forwarded field, legacy X-Forwarded fields, both, or neither; untrusted inbound identity fields are removed first.
• RFC 7540 — HTTP/2. This is retained as HTTP/2 compatibility lineage; the active HTTP/2 contract is its successor, RFC 9113.
• RFC 7541 — HPACK: Header Compression for HTTP/2. Webship’s owned HTTP/2 stack bounds decoder state and encoder tables while preserving the HPACK wire format and Huffman coding.
• RFC 7838 — HTTP Alternative Services. Alt-Svc advertises an HTTP/3 endpoint without changing the origin represented by the URL.
• RFC 8441 — Bootstrapping WebSockets with HTTP/2. Webship supports the downstream extended-CONNECT negotiation foundation. It does not pretend that an HTTP/1.1 upstream implements HTTP/2 extended CONNECT; unsupported upstream combinations fail explicitly.
• RFC 8470 — Using Early Data in HTTP. Early requests that Webship will not process receive 425 Too Early instead of being handled with unsafe replay assumptions.
• RFC 8941 — Structured Field Values for HTTP. HTTP priority values use structured-field dictionary parsing; malformed optional fields are ignored as a whole.
• RFC 9110 — HTTP Semantics. Methods, status codes, fields, validators, preconditions, redirects, content metadata, HEAD, CONNECT, OPTIONS, and range semantics share one current contract across protocol versions.
• RFC 9111 — HTTP Caching. Webship implements corrected age, explicit freshness, Vary, only-if-cached, must-revalidate, proxy-revalidate, safe stale use, and invalidation of effective and related URIs.
• RFC 9112 — HTTP/1.1. Request-line, field, body-length, transfer-coding, chunk, trailer, persistence, and close-delimited rules are enforced before application dispatch.
• RFC 9113 — HTTP/2. Pseudo-field order, authority, forbidden connection fields, TE restrictions, stream lifecycle, flow control, GOAWAY, and error scope are handled by Webship’s owned H2 path.
• RFC 9114 — HTTP/3. Webship owns the request, control-stream, SETTINGS, critical-stream, cancellation, and stream-versus-connection error paths used by its HTTP/3 server.
• RFC 9204 — QPACK: Field Compression for HTTP/3. Dynamic-table capacity is bounded by the advertised limit, instruction streams remain parseable at zero capacity, and invalid state becomes the required QPACK error.
• RFC 9218 — Extensible Prioritization Scheme for HTTP. Urgency and incremental delivery guide HTTP/3 scheduling while unknown priority parameters remain extensible.
• RFC 9220 — Bootstrapping WebSockets with HTTP/3. Webship implements the HTTP/3 extended-CONNECT SETTINGS foundation used by modern tunneled protocols; that does not imply every possible CONNECT protocol is accepted.
• RFC 9297 — HTTP Datagrams and the Capsule Protocol. WebTransport sessions use bounded capsule decoding and HTTP Datagram association, with unknown capsules handled as extension points instead of parser failures.
• RFC 9421 — HTTP Message Signatures. Optional Ed25519 response provenance can cover Webship release and configuration identity without replacing TLS or application authentication.
• RFC 10008 — The HTTP QUERY Method. Webship treats QUERY as safe and idempotent, preserves its body through proxying, includes body and representation metadata in cache identity, forbids heuristic freshness, supports conditional and range behavior, and never invalidates a cache merely because QUERY was used.

QUIC transport and congestion control

• RFC 3465 — TCP Congestion Control with Appropriate Byte Counting. Appropriate-byte-counting logic is part of the NewReno congestion-control lineage used by Webship’s QUIC implementation.
• RFC 4303 — IP Encapsulating Security Payload. Webship does not implement IPsec ESP; its QUIC packet deduplicator uses the RFC’s sliding-window anti-replay technique as implementation lineage only.
• RFC 5681 — TCP Congestion Control. Loss and reordering thresholds inherit established congestion-control constraints where QUIC builds on TCP practice.
• RFC 6298 — Computing TCP’s Retransmission Timer. Smoothed round-trip time and variance calculations contribute to the QUIC recovery model.
• RFC 8312 — CUBIC for Fast Long-Distance Networks. This is the earlier CUBIC specification retained as algorithm lineage; RFC 9438 is the current standard.
• RFC 8899 — Packetization Layer Path MTU Discovery for Datagram Transports. Configurable DPLPMTUD discovers usable QUIC datagram size without depending on fragile network-layer signals.
• RFC 8999 — Version-Independent Properties of QUIC. Long headers, connection IDs, version negotiation, and invariant parsing remain safe before a version-specific decoder runs.
• RFC 9000 — QUIC: A UDP-Based Multiplexed and Secure Transport. Connection IDs, streams, flow control, migration, address validation, Retry, stateless reset, transport parameters, and close behavior form Webship’s HTTP/3 transport base.
• RFC 9001 — Using TLS to Secure QUIC. Initial secrets, packet protection, header protection, Retry integrity, key phases, and TLS integration follow QUIC-TLS rules.
• RFC 9002 — QUIC Loss Detection and Congestion Control. Packet-number spaces, acknowledgements, PTO, loss detection, recovery, and congestion accounting drive transport reliability.
• RFC 9221 — An Unreliable Datagram Extension to QUIC. Negotiated QUIC DATAGRAM frames carry unreliable WebTransport traffic without turning it into stream content.
• RFC 9287 — Greasing the QUIC Bit. QUIC-bit greasing reduces ossification while preserving negotiation safety.
• RFC 9308 — Applicability of the QUIC Transport Protocol. Operational defaults such as bounded idle time and deployment guidance inform Webship’s production transport policy.
• RFC 9369 — QUIC Version 2. Version 2 packet types, initial keys, Retry integrity, key updates, and version negotiation are implemented alongside QUIC v1.
• RFC 9438 — CUBIC for Fast and Long-Distance Networks. The current CUBIC standard governs Webship’s CUBIC congestion controller; BBR and NewReno remain selectable where the workload calls for them.

TLS, certificates, and automatic certificate management

• RFC 3339 — Date and Time on the Internet: Timestamps. ACME renewal windows use interoperable Internet timestamps.
• RFC 4648 — Base16, Base32, and Base64 Data Encodings. ACME JOSE values and WebSocket handshake material use the required Base64 and Base64url alphabets and padding rules.
• RFC 5280 — Internet X.509 PKI Certificate and CRL Profile. Certificate parsing and generated challenge certificates use correct DNS and binary IP subjectAltName forms.
• RFC 5869 — HMAC-based Extract-and-Expand Key Derivation Function. HKDF-SHA-256 and HKDF-SHA-384 derivation, including output bounds, underpins TLS and QUIC keys.
• RFC 6066 — TLS Extensions. SNI selects DNS identities, while literal IP addresses are correctly excluded from the ordinary HostName form.
• RFC 7301 — TLS Application-Layer Protocol Negotiation. ALPN selects HTTP/1.1, HTTP/2, HTTP/3, and the isolated ACME challenge protocol at the TLS boundary.
• RFC 7638 — JSON Web Key Thumbprint. ACME account key thumbprints are derived in the canonical JWK form.
• RFC 7807 — Problem Details for HTTP APIs. Webship consumes the problem-document format required by RFC 8555 ACME servers. The newer Problem Details specification supersedes it for new general-purpose APIs, but ACME’s normative dependency remains explicit.
• RFC 8446 — TLS 1.3. Webship uses TLS 1.3 for public TLS, including session tickets, key updates, alerts, early-data policy, and QUIC key derivation.
• RFC 8555 — Automatic Certificate Management Environment. Account, order, authorization, challenge, finalization, certificate download, and renewal flows are automated with bounded input handling.
• RFC 8737 — ACME TLS-ALPN-01 Challenge. A challenge-only TLS path negotiates only acme-tls/1 and serves the required critical acmeIdentifier certificate extension.
• RFC 8738 — ACME IP Identifier Validation Extension. Webship supports IPv4 and IPv6 certificate orders, binary IP SANs, and reverse-address SNI for IP TLS-ALPN-01 validation.
• RFC 9525 — Service Identity in TLS. DNS names and IP identities are matched under current service-identity rules, without wildcard or common-name shortcuts for IP addresses.
• RFC 9773 — ACME Renewal Information Extension. Renewal windows can come from the CA, allowing Webship to spread renewals safely instead of using one rigid local schedule.

WebTransport: precise about what is standardized

WebTransport over HTTP/3 is not counted as a fifty-third RFC. As of Webship 1.3.1, its wire mapping remains draft-ietf-webtrans-http3-16. Webship implements that draft on top of the standardized HTTP/3, extended CONNECT, QUIC DATAGRAM, HTTP Datagram, and Capsule layers named above. It also implements the negotiated RESET_STREAM_AT extension required to preserve a reliable session-identifying prefix when a WebTransport stream is reset.

That distinction matters. Standards compatibility is not improved by calling a draft an RFC. It is improved by tracking the draft explicitly, isolating it from ordinary HTTP paths, negotiating every extension, bounding every session resource, and testing cancellation and failure behavior.

Why this breadth matters in production

A standards bug is rarely isolated. Incorrect HSTS handling can cross a cache boundary. A malformed QPACK instruction can terminate unrelated requests. An unsafe early-data assumption can replay an operation. A QUERY cache key that omits the request body can return the result of a different query. A proxy that strips trailers or mishandles cancellation can silently change an application protocol.

Webship’s architecture treats these as connected concerns. Parser limits, security inspection, caching, reverse proxying, transport state, and instrumentation share explicit contracts. The result is one server that can move between HTTP/1.1, HTTP/2, HTTP/3, static delivery, reverse proxying, streaming, and WebTransport without giving each mode a different definition of correctness.

Verify the claim

Do not take a superlative on trust. Read the [Webship 1.3.1 documentation](/docs/1.3.1), inspect the configuration and protocol boundaries, and reproduce the published behavior. Then [download Webship](/downloads) and test the edge cases that matter to your system.