Webship: Il server web più compatibile con le RFC al mondo

Il web è tenuto insieme da accordi precisi. Un campo Content-Length deve significare la stessa cosa a ogni passaggio. Una cache non deve riutilizzare una risposta che richiede la convalida. Una sezione di campo HTTP/3 malformata deve fallire all'ambito corretto. Un metodo sicuro deve rimanere sicuro dopo essere passato attraverso un proxy inverso.

Webship 1.3.1 è costruito attorno a una regola: la velocità conta solo quando i byte mantengono il loro significato.

Ecco perché descriviamo Webship come il server web general-purpose più conforme agli RFC al mondo. Si tratta di un'affermazione ingegneristica con un confine visibile, non di un'affermazione secondo cui ogni funzionalità opzionale in ogni RFC esista. La mappa sottostante nomina i 52 RFC che influenzano il comportamento attivo del server di Webship o le sue fondamenta di protocollo di proprietà. Gli standard attuali vengono prima. I documenti superati sono identificati come linea di compatibilità. Le specifiche in bozza non vengono rinominate come RFC.

La compatibilità è comportamento, non un distintivo

Webship applica standard nei punti in cui i server di produzione diventano più spesso ambigui:

• Il framing HTTP/1.1 rifiuta lunghezze contrastanti, codifiche di trasferimento non valide, destinazioni di richiesta sovradimensionate, chunk malformati e forme di request-smuggling.
• HTTP/2 e HTTP/3 rifiutano campi di connessione proibiti, convalidano i pseudo-campi, limitano le sezioni dei campi compressi e tengono separati gli errori di flusso dagli errori di connessione.
• I file statici preservano la semantica HEAD, i validatori, l'ordine delle precondizioni, gli intervalli di byte, i reindirizzamenti e i tipi di contenuto.
• Il reverse proxy preserva l'inquadramento, la cancellazione, i trailer, gli aggiornamenti, i retry sicuri e l'identità di inoltro mentre rimuove i campi hop-by-hop.
• La cache calcola regole di età, freschezza, rivalidazione, Vary, invalidazione e uso obsoleto piuttosto che trattare la memorizzazione nella cache come una scorciatoia chiave-valore.
• TLS, QUIC, ACME, dati anticipati e WebTransport utilizzano uno stato limitato e una politica di fallimento esplicita.

Le stesse regole si applicano sul percorso veloce. Webship non definisce un percorso “corretto” e un percorso di riferimento diverso.

Semantica HTTP, incorniciatura, caching e proxy

• RFC 3986 — Identificatore di Risorsa Uniforme (URI): Sintassi Generica. Webship normalizza i riferimenti relativi a Location e Content-Location, inclusi i segmenti punto, prima delle decisioni di invalidazione della cache.
• RFC 6455 — Il Protocollo WebSocket. Gli upgrade tramite reverse-proxy convalidano la chiave WebSocket, il valore di accettazione, il sottoprotocollo, le estensioni e la transizione del tunnel.
• RFC 6585 — Codici di stato HTTP aggiuntivi. I campi di richiesta sovradimensionati utilizzano la risposta 431 definita quando una risposta HTTP è ancora possibile.
• RFC 6797 — HTTP Strict Transport Security. Strict-Transport-Security viene emesso solo su trasporto sicuro e non perde mai da una voce di cache neutra rispetto al trasporto su HTTP in chiaro.
• RFC 7235 — Autenticazione HTTP/1.1. I token dello schema di autenticazione vengono analizzati senza distinzione tra maiuscole e minuscole, incluso il pannello di controllo protetto MCP. La sua semantica generale HTTP ora risiede in RFC 9110.
• RFC 7239 — Estensione HTTP Forwarded. Gli operatori possono selezionare un campo Forwarded basato sugli standard, campi X-Forwarded legacy, entrambi o nessuno; i campi di identità in ingresso non affidabili vengono rimossi per primi.
• RFC 7540 — HTTP/2. Questo è mantenuto come linea di compatibilità con HTTP/2; il contratto HTTP/2 attivo è il suo successore, RFC 9113.
• RFC 7541 — HPACK: Compressione degli Header per HTTP/2. Lo stack HTTP/2 di proprietà di Webship limita lo stato del decodificatore e le tabelle del codificatore mantenendo il formato wire HPACK e la codifica di Huffman.
• RFC 7838 — Servizi alternativi HTTP. Alt-Svc pubblicizza un endpoint HTTP/3 senza modificare l'origine rappresentata dall'URL.
• RFC 8441 — Avvio dei WebSocket con HTTP/2. Webship supporta la base di negoziazione extended-CONNECT a valle. Non pretende che un upstream HTTP/1.1 implementi HTTP/2 extended CONNECT; le combinazioni upstream non supportate falliscono esplicitamente.
• RFC 8470 — Utilizzo dei Dati Precoce in HTTP. Le richieste anticipate che Webship non elaborerà ricevono 425 Too Early invece di essere gestite con ipotesi di riproduzione non sicure.
• RFC 8941 — Valori dei Campi Strutturati per HTTP. I valori di priorità HTTP utilizzano il parsing del dizionario dei campi strutturati; i campi opzionali non validi vengono ignorati nel loro insieme.
• RFC 9110 — Semantica HTTP. Metodi, codici di stato, campi, validatori, precondizioni, reindirizzamenti, metadati dei contenuti, HEAD, CONNECT, OPTIONS e semantica degli intervalli condividono un contratto attuale unico tra le versioni del protocollo.
• RFC 9111 — Caching HTTP. Webship implementa età corretta, freschezza esplicita, Vary, only-if-cached, must-revalidate, proxy-revalidate, uso sicuro di stale e invalidazione degli URI effettivi e correlati.
• RFC 9112 — HTTP/1.1. Le regole relative a request-line, field, body-length, transfer-coding, chunk, trailer, persistenza e chiusura delimitata vengono applicate prima della distribuzione all'applicazione.
• RFC 9113 — HTTP/2. L'ordine dei pseudo-campi, l'autorità, i campi di connessione proibiti, le restrizioni TE, il ciclo di vita dello stream, il controllo del flusso, GOAWAY e l'ambito degli errori sono gestiti dal percorso H2 di proprietà di Webship.
• RFC 9114 — HTTP/3. Webship possiede le rotte di richiesta, controllo-stream, SETTINGS, critical-stream, cancellazione e errore stream-versus-connection utilizzate dal suo server HTTP/3.
• RFC 9204 — QPACK: Compressione dei campi per HTTP/3. La capacità della tabella dinamica è limitata dal limite pubblicizzato, i flussi di istruzioni rimangono analizzabili a capacità zero e lo stato non valido diventa l'errore QPACK richiesto.
• RFC 9218 — Schema di Prioritizzazione Estensibile per HTTP. Urgenza e consegna incrementale guidano la pianificazione di HTTP/3 mentre i parametri di priorità sconosciuti rimangono estensibili.
• RFC 9220 — Avvio dei WebSocket con HTTP/3. Webship implementa le impostazioni di base extended-CONNECT di HTTP/3 utilizzate dai moderni protocolli tunnel; ciò non implica che ogni possibile protocollo CONNECT sia accettato.
• RFC 9297 — Datagrammi HTTP e Protocollo Capsule. Le sessioni WebTransport utilizzano la decodifica a capsule limitata e l'associazione con i Datagrammi HTTP, con le capsule sconosciute gestite come punti di estensione anziché come errori del parser.
• RFC 9421 — HTTP Message Signatures. La tracciabilità opzionale della risposta Ed25519 può coprire l'identità della versione e della configurazione di Webship senza sostituire TLS o l'autenticazione dell'applicazione.
• RFC 10008 — Il Metodo HTTP QUERY. Webship tratta QUERY come sicuro e idempotente, preserva il suo corpo durante il proxying, include il corpo e i metadati della rappresentazione nell'identità della cache, proibisce la freschezza euristica, supporta comportamenti condizionali e a intervalli, e non invalida mai una cache semplicemente perché è stato utilizzato QUERY.

Trasporto QUIC e controllo della congestione

• RFC 3465 — Controllo della congestione TCP con conteggio appropriato dei byte. La logica del conteggio appropriato dei byte fa parte della linea di controllo della congestione NewReno utilizzata dall'implementazione QUIC di Webship.
• RFC 4303 — Payload di Sicurezza Incapsulata IP. Webship non implementa IPsec ESP; il deduplicatore di pacchetti QUIC utilizza la tecnica di anti-riproduzione a finestra scorrevole del RFC solo come linea di discendenza dell’implementazione.
• RFC 5681 — Controllo della congestione TCP. Le soglie di perdita e di riordinamento ereditano le restrizioni consolidate del controllo della congestione, dove QUIC si basa sulle pratiche del TCP.
• RFC 6298 — Calcolo del timer di ritrasmissione TCP. I calcoli del tempo di andata e ritorno mediato e della varianza contribuiscono al modello di recupero di QUIC.
• RFC 8312 — CUBIC per reti veloci a lunga distanza. Questa è la specifica CUBIC precedente mantenuta come genealogia dell'algoritmo; RFC 9438 è lo standard attuale.
• RFC 8899 — Scoperta del MTU del percorso a livello di pacchetto per i trasporti datagram. DPLPMTUD configurabile scopre la dimensione utilizzabile del datagram QUIC senza dipendere da segnali a livello di rete fragili.
• RFC 8999 — Proprietà Indipendenti dalla Versione di QUIC. Le intestazioni lunghe, gli ID di connessione, la negoziazione della versione e il parsing invariabile rimangono sicuri prima che venga eseguito un decoder specifico per la versione.
• RFC 9000 — QUIC: un trasporto multiplexed e sicuro basato su UDP. Gli ID di connessione, i flussi, il controllo del flusso, la migrazione, la convalida degli indirizzi, Retry, il reset senza stato, i parametri di trasporto e il comportamento di chiusura costituiscono la base del trasporto HTTP/3 di Webship.
• RFC 9001 — Utilizzo di TLS per proteggere QUIC. Segreti iniziali, protezione dei pacchetti, protezione dell'intestazione, integrità del Retry, fasi delle chiavi e integrazione TLS seguono le regole QUIC-TLS.
• RFC 9002 — Rilevamento delle perdite e controllo della congestione in QUIC. Gli spazi dei numeri di pacchetto, i riconoscimenti, il PTO, il rilevamento delle perdite, il recupero e la contabilizzazione della congestione guidano l'affidabilità del trasporto.
• RFC 9221 — Un'estensione di datagrammi non affidabile per QUIC. I frame DATAGRAM negoziati di QUIC trasportano traffico WebTransport non affidabile senza trasformarlo in contenuto di flusso.
• RFC 9287 — Lubrificazione del bit QUIC. La lubrificazione del bit QUIC riduce l'ossificazione pur preservando la sicurezza della negoziazione.
• RFC 9308 — Applicabilità del Protocollo di Trasporto QUIC. Impostazioni operative predefinite come il tempo di inattività limitato e le indicazioni per la distribuzione informano la politica di trasporto di produzione di Webship.
• RFC 9369 — QUIC Version 2. I tipi di pacchetto della Versione 2, le chiavi iniziali, l'integrità del Retry, gli aggiornamenti delle chiavi e la negoziazione della versione sono implementati insieme a QUIC v1.
• RFC 9438 — CUBIC per reti veloci e a lunga distanza. Lo standard CUBIC attuale regola il controller di congestione CUBIC di Webship; BBR e NewReno rimangono selezionabili quando il carico di lavoro lo richiede.

TLS, certificati e gestione automatica dei certificati

• RFC 3339 — Data e ora su Internet: timestamp. Le finestre di rinnovo ACME utilizzano timestamp Internet interoperabili.
• RFC 4648 — Codifiche dei dati Base16, Base32 e Base64. I valori ACME JOSE e il materiale per il handshake WebSocket utilizzano gli alfabeti Base64 e Base64url richiesti e le regole di padding.
• RFC 5280 — Profilo dei certificati PKI X.509 su Internet e CRL. L'analisi dei certificati e i certificati di sfida generati utilizzano le forme corrette di DNS e indirizzi IP binari per subjectAltName.
• RFC 5869 — Funzione di Derivazione di Chiavi HMAC-based Extract-and-Expand. La derivazione HKDF-SHA-256 e HKDF-SHA-384, compresi i limiti di output, supporta le chiavi TLS e QUIC.
• RFC 6066 — Estensioni TLS. SNI seleziona le identità DNS, mentre gli indirizzi IP letterali sono correttamente esclusi dalla forma ordinaria HostName.
• RFC 7301 — Negoziazione dei protocolli a livello di applicazione TLS. ALPN seleziona HTTP/1.1, HTTP/2, HTTP/3 e il protocollo di sfida ACME isolato al confine TLS.
• RFC 7638 — Impronta digitale della chiave JSON Web. Le impronte digitali delle chiavi dell'account ACME sono derivate nella forma canonica JWK.
• RFC 7807 — Dettagli dei problemi per le API HTTP. Webship utilizza il formato del documento dei problemi richiesto dai server ACME RFC 8555. La più recente specifica dei Dettagli dei problemi lo sostituisce per le nuove API generali, ma la dipendenza normativa di ACME rimane esplicita.
• RFC 8446 — TLS 1.3. Webship utilizza TLS 1.3 per TLS pubblico, inclusi ticket di sessione, aggiornamenti delle chiavi, avvisi, politica dei dati anticipati e derivazione delle chiavi QUIC.
• RFC 8555 — Ambiente di Gestione Automatica dei Certificati. I flussi di account, ordine, autorizzazione, sfida, finalizzazione, download del certificato e rinnovo sono automatizzati con gestione degli input limitata.
• RFC 8737 — Sfida ACME TLS-ALPN-01. Un percorso TLS solo per la sfida negozia solo acme-tls/1 e serve l'estensione di certificato critica acmeIdentifier richiesta.
• RFC 8738 — Estensione per la convalida dell'identificatore IP ACME. Webship supporta ordini di certificati IPv4 e IPv6, SAN IP binari e SNI con indirizzo inverso per la convalida IP TLS-ALPN-01.
• RFC 9525 — Identità del servizio in TLS. I nomi DNS e le identità IP vengono confrontati secondo le regole attuali dell'identità del servizio, senza scorciatoie di caratteri jolly o di nomi comuni per gli indirizzi IP.
• RFC 9773 — Estensione delle Informazioni sul Rinnovo ACME. Le finestre di rinnovo possono provenire dalla CA, permettendo a Webship di distribuire i rinnovi in modo sicuro invece di utilizzare un unico programma locale rigido.

WebTransport: preciso su ciò che è standardizzato

WebTransport su HTTP/3 non è considerato come cinquantaquattresimo RFC. A partire da Webship 1.3.1, la sua mappatura sul filo rimane draft-ietf-webtrans-http3-16. Webship implementa quel draft sopra l'HTTP/3 standardizzato, CONNECT esteso, QUIC DATAGRAM, HTTP Datagram e i livelli Capsule sopra menzionati. Implementa anche l'estensione RESET_STREAM_AT negoziata necessaria per preservare un prefisso identificativo di sessione affidabile quando un flusso WebTransport viene resettato.

Quella distinzione è importante. La compatibilità degli standard non viene migliorata chiamando un draft un RFC. Viene migliorata seguendo esplicitamente il draft, isolandolo dai percorsi HTTP ordinari, negoziando ogni estensione, limitando ogni risorsa di sessione e testando il comportamento in caso di cancellazione e guasto.

Perché questa ampiezza è importante nella produzione

Un bug di standard è raramente isolato. La gestione scorretta di HSTS può attraversare un confine di cache. Un'istruzione QPACK malformata può terminare richieste non correlate. Un'assunzione insicura sui dati iniziali può ripetere un'operazione. Una chiave di cache QUERY che omette il corpo della richiesta può restituire il risultato di una query diversa. Un proxy che rimuove i trailer o gestisce male la cancellazione può modificare silenziosamente un protocollo applicativo.

L'architettura di Webship tratta questi come problemi collegati. I limiti del parser, l'ispezione di sicurezza, la memorizzazione nella cache, il reverse proxy, lo stato del trasporto e l'instradamento condividono contratti espliciti. Il risultato è un server che può passare tra HTTP/1.1, HTTP/2, HTTP/3, consegna statica, reverse proxy, streaming e WebTransport senza dare a ciascuna modalità una definizione diversa di correttezza.

Verifica l'affermazione

Non accettare un superlativo sulla fiducia. Leggi la [documentazione di Webship 1.3.1](/docs/1.3.1), esamina la configurazione e i confini del protocollo, e riproduci il comportamento pubblicato. Poi [scarica Webship](/downloads) e testa i casi limite che contano per il tuo sistema.