Webship: De Meest RFC-Compatibele Webserver ter Wereld

Het web wordt bij elkaar gehouden door exacte afspraken. Een Content-Length-veld moet bij elke hop hetzelfde betekenen. Een cache mag een antwoord dat validatie vereist niet hergebruiken. Een verkeerd gevormde HTTP/3-veldsectie moet op de juiste scope falen. Een veilige methode moet veilig blijven nadat deze door een reverse proxy is gegaan.

Webship 1.3.1 is gebouwd rond één regel: snelheid telt alleen wanneer de bytes hun betekenis behouden.

Dat is de reden waarom we Webship beschrijven als de meest RFC-compatibele general-purpose webserver ter wereld. Dit is een engineeringclaim met een zichtbare grens, geen claim dat elk optioneel kenmerk in elke RFC bestaat. De kaart hieronder noemt de 52 RFC's die het actieve servergedrag van Webship of de eigen protocolfundamenten beïnvloeden. Huidige standaarden komen eerst. Overtreffende documenten worden geïdentificeerd als compatibiliteitslijn. Concept-specificaties worden niet opnieuw gelabeld als RFC's.

Compatibiliteit is gedrag, geen onderscheiding

Webship past normen toe op de plaatsen waar productieservers het vaakst ambigu worden:

• HTTP/1.1-framing wijst conflicterende lengtes, ongeldige overdrachtscoderingen, te grote verzoekdoelen, verkeerd gevormde blokken en vormen van verzoeksmokkel af.
• HTTP/2 en HTTP/3 wijzen verboden verbindingsvelden af, valideren pseudo-velden, begrenzen gecomprimeerde veldsecties en houden streamfouten gescheiden van verbindingsfouten.
• Statische bestanden behouden HEAD-semantiek, validators, volgorde van voorwaarden, bytebereiken, doorverwijzingen en inhoudstypen.
• De reverse proxy behoudt framing, annulering, trailers, upgrades, veilige herhalingen en doorstuuridentiteit terwijl hop-by-hop-velden worden verwijderd.
• De cache berekent leeftijd, versheid, hervalidatie, Vary, ongeldigmaking en regels voor het gebruik van verouderde gegevens in plaats van caching als een sleutel-waarde snelkoppeling te behandelen.
• TLS, QUIC, ACME, vroege gegevens en WebTransport gebruiken begrensde staat en expliciet foutbeleid.

Dezelfde regels gelden op het snelle pad. Webship definieert niet één “correct” pad en een verschillend referentiepad.

HTTP-semantiek, framing, caching en proxying

• RFC 3986 — Uniform Resource Identifier (URI): Generieke syntaxis. Webship normaliseert relatieve Location- en Content-Location-verwijzingen, inclusief puntsegmenten, voordat bepalingen voor cache-invalidering worden genomen.
• RFC 6455 — Het WebSocket-protocol. Reverse-proxy-upgrades verifiëren de WebSocket-sleutel, acceptatiewaarde, subprotocol, extensies en tunnelovergang.
• RFC 6585 — Aanvullende HTTP-statuscodes. Te grote aanvraagvelden gebruiken de gedefinieerde 431-respons wanneer een HTTP-respons nog steeds mogelijk is.
• RFC 6797 — HTTP Strict Transport Security. Strict-Transport-Security wordt alleen uitgezonden via een veilige overdracht en lekt nooit van een transportneutrale cache-invoer naar onbeveiligd HTTP.
• RFC 7235 — HTTP/1.1 Authenticatie. Authenticatieschema-tokens worden hoofdletterongevoelig geparseerd, inclusief het beschermde MCP-bedieningsoppervlak. De algemene HTTP-semantiek bevindt zich nu in RFC 9110.
• RFC 7239 — Forwarded HTTP-extensie. Operators kunnen een standaarden-gebaseerd Forwarded-veld, legacy X-Forwarded-velden, beide of geen van beide selecteren; niet-vertrouwde binnenkomende identiteitsvelden worden eerst verwijderd.
• RFC 7540 — HTTP/2. Dit wordt behouden als HTTP/2-compatibiliteitslijn; het actieve HTTP/2-contract is de opvolger, RFC 9113.
• RFC 7541 — HPACK: Headercompressie voor HTTP/2. Webship’s eigen HTTP/2-stapel beperkt de decoderstatus en encodertabellen terwijl het HPACK-wireformaat en Huffmancodering behouden blijven.
• RFC 7838 — HTTP Alternative Services. Alt-Svc adverteert een HTTP/3-eindpunt zonder de oorsprong die door de URL wordt weergegeven te veranderen.
• RFC 8441 — WebSockets opstarten met HTTP/2. Webship ondersteunt de downstream uitgebreide-CONNECT onderhandelingsbasis. Het doet niet alsof een HTTP/1.1 upstream HTTP/2 uitgebreide CONNECT implementeert; niet-ondersteunde upstream-combinaties falen expliciet.
• RFC 8470 — Het gebruik van vroege gegevens in HTTP. Vroege verzoeken die Webship niet zal verwerken, krijgen 425 Too Early in plaats van te worden afgehandeld met onveilige herhalingsveronderstellingen.
• RFC 8941 — Gestructureerde veldwaarden voor HTTP. HTTP-prioriteitswaarden gebruiken parsing van gestructureerde-veldwoordenboeken; onjuist gevormde optionele velden worden volledig genegeerd.
• RFC 9110 — HTTP-semantiek. Methoden, statuscodes, velden, validators, voorwaarden, omleidingen, inhoudsmetadata, HEAD, CONNECT, OPTIONS en bereiksemantiek delen één huidige overeenkomst over protocolversies.
• RFC 9111 — HTTP-caching. Webship implementeert gecorrigeerde leeftijd, expliciete versheid, Vary, only-if-cached, must-revalidate, proxy-revalidate, veilig gebruik van verouderde gegevens en ongeldigmaking van effectieve en gerelateerde URIs.
• RFC 9112 — HTTP/1.1. Regels voor request-lijn, veld, body-lengte, transfer-codering, chunk, trailer, persistentie en close-delimiting worden gehandhaafd voordat de toepassing wordt uitgevoerd.
• RFC 9113 — HTTP/2. Pseudo-veld volgorde, autoriteit, verboden verbindingsvelden, TE-beperkingen, stream levenscyclus, flow control, GOAWAY en foutbereik worden afgehandeld door het door Webship beheerde H2-pad.
• RFC 9114 — HTTP/3. Webship bezit de request-, control-stream-, SETTINGS-, critical-stream-, annulering- en stream-tegen-connection-foutpaden die door zijn HTTP/3-server worden gebruikt.
• RFC 9204 — QPACK: Veldcompressie voor HTTP/3. De capaciteit van de dynamische tabel wordt begrensd door de geadverteerde limiet, instructiestromen blijven ontleerbaar bij nul capaciteit, en een ongeldige toestand wordt de vereiste QPACK-fout.
• RFC 9218 — Uitbreidbaar Prioriteitsschema voor HTTP. Urgentie en incrementele levering sturen de HTTP/3-planning terwijl onbekende prioriteitsparameters uitbreidbaar blijven.
• RFC 9220 — WebSockets opstarten met HTTP/3. Webship implementeert de HTTP/3 extended-CONNECT SETTINGS basis die wordt gebruikt door moderne getunnelde protocollen; dat betekent niet dat elk mogelijk CONNECT-protocol wordt geaccepteerd.
• RFC 9297 — HTTP-datagrammen en het capsuleprotocol. WebTransport-sessies gebruiken begrensde capsule-decodering en HTTP-datagramassociatie, waarbij onbekende capsules worden behandeld als uitbreidingspunten in plaats van parserfouten.
• RFC 9421 — HTTP-berichthandtekeningen. Optionele Ed25519-responsherkomst kan de Webship-release en configuratie-identiteit dekken zonder TLS of applicatie-authenticatie te vervangen.
• RFC 10008 — De HTTP QUERY-methode. Webship beschouwt QUERY als veilig en idempotent, behoudt de body tijdens proxying, omvat body en representatiemetadata in cache-identiteit, verbiedt heuristische versheid, ondersteunt voorwaardelijk en bereikgedrag, en maakt een cache nooit ongeldig alleen omdat QUERY werd gebruikt.

QUIC transport en congestiebeheer

• RFC 3465 — TCP-congestiebeheersing met passende byte-telling. Passende-byte-tel-logica maakt deel uit van de NewReno-congestiebeheersingslijn die wordt gebruikt door Webship's QUIC-implementatie.
• RFC 4303 — IP Encapsulating Security Payload. Webship implementeert IPsec ESP niet; de QUIC-pakketdeduplicator ervan gebruikt de schuifvenster anti-replaytechniek van de RFC alleen als implementatielijn.
• RFC 5681 — TCP Congestiebeheer. Verlies- en herschikkingsdrempels erven de gevestigde beperkingen van congestiebeheer waar QUIC voortbouwt op de TCP-praktijk.
• RFC 6298 — Het berekenen van TCP's hertransmissietimer. Berekeningen van de gesmoothingde round-trip tijd en variantie dragen bij aan het herstelmodel van QUIC.
• RFC 8312 — CUBIC voor Snelle Lange-Afstandsnetwerken. Dit is de eerdere CUBIC-specificatie die behouden is als algoritmische afstamming; RFC 9438 is de huidige standaard.
• RFC 8899 — Packetization Layer Path MTU Discovery voor Datagramtransports. Configureerbare DPLPMTUD ontdekt de bruikbare QUIC-datagramgrootte zonder afhankelijk te zijn van kwetsbare signalen op netwerkniveau.
• RFC 8999 — Versie-onafhankelijke eigenschappen van QUIC. Lange headers, verbindings-ID's, versieonderhandeling en onveranderlijke parsing blijven veilig voordat een versiespecifieke decoder wordt uitgevoerd.
• RFC 9000 — QUIC: Een UDP-gebaseerd gemultiplexed en veilig transport. Verbindings-ID's, streams, verkeersbeheer, migratie, adresvalidatie, Retry, stateloze reset, transportparameters en afsluitgedrag vormen de HTTP/3-transportbasis van Webship.
• RFC 9001 — TLS gebruiken om QUIC te beveiligen. Begingeheimen, pakketbescherming, headerbescherming, Retry-integriteit, sleutel-fases en TLS-integratie volgen de QUIC-TLS-regels.
• RFC 9002 — QUIC Verliesdetectie en Congestiebeheersing. Pakket-nummer ruimtes, bevestigingen, PTO, verliesdetectie, herstel en congestieboeking bepalen de betrouwbaarheid van transport.
• RFC 9221 — Een onbetrouwbare datagramextensie voor QUIC. Onderhandelde QUIC DATAGRAM-frames dragen onbetrouwbaar WebTransport-verkeer zonder dit om te zetten in streaminhoud.
• RFC 9287 — Het insmeren van de QUIC-bit. Het insmeren van de QUIC-bit vermindert ossificatie terwijl de onderhandelingsveiligheid behouden blijft.
• RFC 9308 — Toepasbaarheid van het QUIC-transporteprotocol. Operationele standaardinstellingen zoals beperkte inactiviteitstijd en implementatierichtlijnen informeren het productie-transportebeleid van Webship.
• RFC 9369 — QUIC Versie 2. Pakkettypen van versie 2, initiële sleutels, Retry-integriteit, sleutelupdates en versienegociatie worden geïmplementeerd naast QUIC v1.
• RFC 9438 — CUBIC voor snelle en langeafstandnetwerken. De huidige CUBIC-standaard regelt Webship’s CUBIC-congestiecontroller; BBR en NewReno blijven selecteerbaar wanneer de werklast hierom vraagt.

TLS, certificaten en automatisch certificaatbeheer

• RFC 3339 — Datum en tijd op het internet: tijdstempels. ACME-vernieuwingsvensters gebruiken interoperabele internettijdstempels.
• RFC 4648 — Base16, Base32 en Base64-gegevenscoderingen. ACME JOSE-waarden en WebSocket-handshake-materiaal gebruiken de vereiste Base64- en Base64url-alfabetten en opvulregels.
• RFC 5280 — Internet X.509 PKI-certificaat- en CRL-profiel. Certificaatanalyse en gegenereerde challenge-certificaten gebruiken de juiste DNS- en binaire IP-subjectAltName-vormen.
• RFC 5869 — HMAC-gebaseerde Extract-and-Expand Sleutelafleidingsfunctie. HKDF-SHA-256 en HKDF-SHA-384 afleiding, inclusief uitvoergrenzen, ondersteunt TLS- en QUIC-sleutels.
• RFC 6066 — TLS-extensies. SNI selecteert DNS-identiteiten, terwijl letterlijke IP-adressen correct worden uitgesloten van de gewone HostName-vorm.
• RFC 7301 — TLS Application-Layer Protocol Negotiation. ALPN selecteert HTTP/1.1, HTTP/2, HTTP/3, en het geïsoleerde ACME-uitdagingprotocol aan de TLS-grens.
• RFC 7638 — JSON Web Key Thumbprint. ACME-account-sleutelvingerafdrukken worden afgeleid in de canonieke JWK-vorm.
• RFC 7807 — Probleemdetails voor HTTP-API's. Webship gebruikt het probleemdocumentformaat dat vereist is door RFC 8555 ACME-servers. De nieuwere specificatie voor Probleemdetails vervangt het voor nieuwe algemene API's, maar de normatieve afhankelijkheid van ACME blijft expliciet.
• RFC 8446 — TLS 1.3. Webship gebruikt TLS 1.3 voor publieke TLS, inclusief sessietickets, sleutelupdates, waarschuwingen, early-data beleid en QUIC-sleutelafleiding.
• RFC 8555 — Automatische Certificaathandlingsomgeving. Account-, order-, autorisatie-, uitdaging-, afrondings-, certificaatdownload- en vernieuwingsstromen worden geautomatiseerd met begrensde invoerverwerking.
• RFC 8737 — ACME TLS-ALPN-01-uitdaging. Een alleen-uitdaging TLS-pad onderhandelt alleen acme-tls/1 en levert de vereiste kritieke acmeIdentifier-certificaatextensie.
• RFC 8738 — ACME IP Identifier Validation Extension. Webship ondersteunt IPv4- en IPv6-certificaatbestellingen, binaire IP-SAN's en reverse-adres SNI voor IP TLS-ALPN-01 validatie.
• RFC 9525 — Service-Identiteit in TLS. DNS-namen en IP-identiteiten worden gematcht volgens de huidige service-identiteitsregels, zonder wildcard- of common-name-snelkoppelingen voor IP-adressen.
• RFC 9773 — ACME Verlenningsinformatieverlenging. Verlengingsvensters kunnen van de CA komen, waardoor Webship verlengingen veilig kan spreiden in plaats van één strak lokaal schema te gebruiken.

WebTransport: nauwkeurig over wat gestandaardiseerd is

WebTransport over HTTP/3 wordt niet geteld als een drieënvijftigste RFC. Vanaf Webship 1.3.1 blijft de wire mapping ervan draft-ietf-webtrans-http3-16. Webship implementeert die draft bovenop de gestandaardiseerde HTTP/3, uitgebreide CONNECT, QUIC DATAGRAM, HTTP Datagram, en Capsule-lagen die hierboven zijn genoemd. Het implementeert ook de onderhandelde RESET_STREAM_AT-extensie die nodig is om een betrouwbare, sessie-identificerende prefix te behouden wanneer een WebTransport-stream wordt gereset.

Die onderscheid is belangrijk. Compatibiliteit met standaarden wordt niet verbeterd door een concept-standaard een RFC te noemen. Het wordt verbeterd door het concept expliciet bij te houden, het te isoleren van gewone HTTP-paden, elke extensie te onderhandelen, elke sessieresource te begrenzen en het annulerings- en foutgedrag te testen.

Waarom deze breedte belangrijk is in de productie

Een standaardenfout is zelden geïsoleerd. Onjuiste HSTS-afhandeling kan een cachegrens overschrijden. Een verkeerd gevormde QPACK-instructie kan niet-gerelateerde verzoeken beëindigen. Een onveilige aannames over vroegtijdige gegevens kan een bewerking herhalen. Een QUERY-cache sleutel die het verzoeklichaam weglaat, kan het resultaat van een ander query teruggeven. Een proxy die trailers verwijdert of annulering verkeerd afhandelt, kan een applicatieprotocol stilletjes veranderen.

De architectuur van Webship behandelt deze als verbonden zaken. Parserlimieten, veiligheidsinspecties, caching, reverse proxying, transportstatus en instrumentatie delen expliciete contracten. Het resultaat is één server die kan schakelen tussen HTTP/1.1, HTTP/2, HTTP/3, statische levering, reverse proxying, streaming en WebTransport zonder dat elke modus een andere definitie van correctheid krijgt.

Controleer de claim

Neem een superlatief niet op vertrouwen. Lees de [Webship 1.3.1 documentatie](/docs/1.3.1), bekijk de configuratie en protocolgrenzen, en reproduceer het gepubliceerde gedrag. Download daarna [Webship](/downloads) en test de randgevallen die belangrijk zijn voor jouw systeem.