Stato dello stack Web

seed fornisce un trasporto web minimo operativo più pacchetti policy/validation portati. Non esiste ancora un framework web completamente pulito: le facciate di servizio integrate (web, web_core runtime, web_runtime, webapp, websocket_server) rimangono archiviate fino a quando il ciclo persistente di connessione-risposta, la cancellazione e il drenaggio di spegnimento non vengono chiusi end-to-end.

Superficie operativa attuale

Package/capability	Superficie attuale
`web_core`	porzione di trasporto operativo: configurazione del listener con riutilizzo degli indirizzi, letture con blocco limitato, parser request-line/header a copia zero, routing method/path senza allocazione, generatore di risposte limitate, nuovi tentativi di scritture complete (`EINTR`)
`http_server`	solo sezione parser: parser di richiesta HTTP/1.1 limitato e senza allocazione (`http_server_available() == false`); nessuna proprietà della connessione, keep-alive, corpi suddivisi o TLS
`http_client`, `http_fetch`, `tls13`	lato client HTTP/1.1 su TCP grezzo o TLS 1,3 (G12/G14); reindirizzamenti limitati, timeout e framing
`std-web-request`, `std-web-response`	destinazione della forma di origine delimitata e convalida status/body-limit (G15, no I/O)
`std-web-security`	cookie sicuro, CSP e politica quadro (G15)
`std-web-static`	percorsi relativi con sicurezza di attraversamento (G15); il file service stesso è di proprietà dell'app
`std-web-template`	escaped/raw-mode policy con convalida del testo sicuro (G15)
`std-web-middleware`, `std-web-db`	priorità ordinate e convalida delle query indipendente dal backend (G15/G16)
`std-router`	solo convalida del modello di percorso; registration/dispatch sono i livelli futuri
`oauth` (`grove/libs/oauth`)	core del server di autorizzazione OAuth 2.0 incorporato su Ridge: registrazione, PKCE, scambio di codici, rotazione di aggiornamento, revoca della famiglia (test di flusso verde; integrazione del sito aperta)
`net`, `io`, `byte_buffer`, `text`, `parse`, `task`, `bytes`/`shared_bytes`, `str`/fette	basi: socket di proprietà, tipizzato I/O, buffer inizializzati, cursore token, analisi controllata, concorrenza strutturata, visualizzazioni binary/text con controllo della proprietà

Elementi ancora della roadmap (non operativi): TLS server, analisi del corpo della richiesta, trasferimento in blocchi, proprietà della connessione keep-alive, cancellation/drain e la pubblicazione WebSocket.

Prove distribuite

Ridge Admin (grove/apps/ridge-admin): app basata su browser servita da un locale seed processo in loopback: sessione autenticata, CSRF, origin/Host controlli, CSP, delimitato HTTP analisi, arresto grazioso. Questo è il modello di riferimento per servire un sito nello stack corrente.
tracciante web-core-bench: crea web_core tramite compilazione separata e serve una richiesta di loopback limitato sulla porta 8080 (fumo deterministico; un server benchmark multiworker persistente è una fase di ridimensionamento separata).

Grove corpus web

Le sorgenti di vecchia generazione rimangono sotto grove/libs/ (ad esempio web, web_request, web_response, web_runtime, web_middleware, web_security, web_static, web_template, web_db, web_metrics). Stanno portando input, non pacchetti puliti attuali: ad es.

./seed/seed check grove/libs/web/src/lib.sd

fallisce durante l'analisi perché l'origine utilizza nomi nominali legacy in maiuscolo e forme aggiuntive sostituite. Di conseguenza, esempi che restituiscono tipi come WebAppStable, WebContext, o WebResponse non devono essere presentati come puliti dal punto di vista operativo seed codice. Usa il std-* porti e web_core invece.

Requisiti per i nuovi pacchetti web

Un pacchetto Web Grove diventa attuale solo dopo aver soddisfatto tutti i seguenti requisiti:

Utilizza una sintassi pulita del serpente inferiore e supera l'operativo parser/type controllore.
Sostituisce le chiamate runtime legacy implicite con i pacchetti ordinari attuali o interfacce runtime controllate esplicite.
Utilizza bytes/shared_bytes di proprietà e porzioni prese in prestito per richieste binarie e organismi di risposta.
Rende visibili gli effetti di allocazione, blocco, panico, I/O, FFI e non sicuri.
Codifica la proprietà di socket, connessione, corpo della richiesta e buffer di risposta con pulizia esatta.
Conserva la provenienza input/receiver per intestazione, percorso, query e zero copie visioni del corpo.
Fornisce errori digitati per analisi, trasporto, TLS, timeout e applicazione fallimenti.
Produce e consuma le attuali interfacce .sdi senza fallback dell'origine.
Dichiara i requisiti platform/runtime e fornisce INSTALL.md per FFI.
Passa positivo, negativo, disinfettante, input in formato non valido, cancellazione e separate-compilation tests.

Affermazioni di produzione

Fino alla chiusura dei livelli di servizio archiviati, la documentazione seed non deve richiedere il supporto corrente per:

produzione (persistente, multilavoratore) HTTP servizio;
TLS funzionamento del server;
sessioni framework, CORS o stack middleware/WebSocket completi oltre a slice policy/validation con porte;
Prestazioni del prodotto compatibili con TechEmpower attraverso lo stack pulito;
uso diretto delle importazioni web legacy Grove (web, webapp, ...) da parte dell'attuale applicazioni.

Servizio limitato in loopback nel file Ridge Admin modello, il web_core fetta di trasporto, il G15/G16 porti politici e il oauth il flusso sono coperti dalle linee di base e dai test denominati e possono essere rivendicati esattamente come evidenziato.

I benchmark storici sul codice Grove potrebbero rimanere come prove storiche esplicitamente etichettate. Non stabiliscono un supporto operativo per la lingua attuale.

Fette successive

La sezione di trasporto richiesta dalla vecchia roadmap ora esiste (web_core). Le prossime fette credibili, in ordine, sono:

1. request-body parsing (bounded, Content-Length; then chunked)
2. persistent connection loop: keep-alive, cancellation, shutdown drain
3. TLS server
4. dispatch router + static-file serving on the verified loop
5. session/middleware composition on std-* policies + oauth

Routing, middleware, TLS, pooling, modelli e livelli applicativi superiori dovrebbero basarsi sulla sezione di trasporto verificata anziché preservare le API legacy esclusivamente per la compatibilità della sorgente.

Tieni traccia delle priorità dell'ecosistema in Library Roadmap. La corrente compiler/library il confine è documentato in Riferimento della libreria operativa, e Grove le regole di compatibilità sono in Grove Albero di compatibilità. Gate prova: G11 (crypto/session/jwt), G12/G14 (HTTP cliente), G15/G16 (porte dei criteri Web, servizio archiviato) in seed/compiler/llvm/tests/GROVE_G*.md.