baserow-schema-mcp : blocage SSE DSM resolu (HTTP 1.0 backend), connecteur pret

Nabil a identifie le fix cote formulaire DSM (HTTP 1.0 au lieu de 1.1 en
version backend du reverse-proxy). Reteste avec succes en conditions
reelles : SSE + les 4 outils bout-en-bout via l'URL publique.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

common/PROTOCOL-INFRA.md

@@ -428,6 +428,6 @@ Regle distincte de l'anti-invention benchmarks du 27/07/2026 (qui couvre la veil
 
 Le MCP natif de Baserow (image officielle, non patchable) ne couvre que les lignes (create_rows/delete_rows/list_tables/...), pas le schema (tables/champs). Nouveau service independant `baserow-schema-mcp` (port 3101, meme famille que le sidecar OAuth `baserow-oauth-stub`) proxyant 4 outils vers l'API REST native de Baserow. Trois pieges a retenir pour tout futur service MCP maison : (1) ces 4 routes de schema exigent un JWT utilisateur, le Database API Token ne fonctionne pas dessus (confirme via /api/redoc/) -- re-login proactif + retry sur 401 pour eviter de reproduire l'incident "rotation Baserow" deja vu sur dashboard-terrain et gsparc-mezzouna-api ; (2) l'API bas niveau `mcp.server.sse.SseServerTransport` a change entre la version figee par context-hub et `mcp==1.29.0` (methodes disparues) -- preferer l'API haut niveau `FastMCP` (`@mcp.tool()` + `mcp.sse_app()`), plus stable dans le temps ; (3) `mcp>=1.29` protege par defaut contre le DNS rebinding avec `allowed_hosts=[]`, ce qui rejette TOUT Host header tant qu'on ne le configure pas explicitement. Reste a faire (manuel, hors perimetre agent) : reverse-proxy DSM `baserow-schema.bolbol.tn` -> 3101, puis ajout du connecteur cote Claude.ai. Detail complet : common/baserow-schema-mcp.md.
 
-## FIX -- baserow-schema-mcp : flux SSE bloque en HTTP/2 via le reverse-proxy DSM (2026-08-17)
+## FIX -- baserow-schema-mcp : flux SSE bloque via le reverse-proxy DSM, resolu en HTTP 1.0 backend (2026-08-17, resolu)
 
-Une fois la regle DSM `baserow-schema.bolbol.tn` -> 3101 creee (cert Let's Encrypt auto-provisionne OK, TLS OK), le endpoint `/mcp/<token>/sse` restait silencieusement bloque quand le client negociait HTTP/2 via ALPN (comportement par defaut de curl et probablement des clients MCP standards) -- 0 octet recu avant timeout. En forcant HTTP/1.1 (`curl --http1.1`), la reponse SSE arrive immediatement et normalement (`event: endpoint` avec session_id). Cause probable : la couche DSM (TLS + reverse-proxy) ne relaie pas correctement un flux chunked/SSE en HTTP/2 sur cette regle precise, alors que `baserow.bolbol.tn` (meme pattern de sidecar nginx, connecteur Claude.ai deja en prod) fonctionne -- ecart de configuration DSM entre les deux regles, pas cote applicatif (nginx interne identique dans les deux cas). A verifier/fixer cote DSM (desactiver HTTP/2 sur cette regle, ou aligner sur la config de baserow.bolbol.tn) si le connecteur Claude.ai echoue silencieusement a l'inscription.
+Une fois la regle DSM `baserow-schema.bolbol.tn` -> 3101 creee (cert Let's Encrypt auto-provisionne OK, TLS OK), le endpoint `/mcp/<token>/sse` restait silencieusement bloque (0 octet recu avant timeout), reproduit avec plusieurs clients. **Resolu par Nabil : choisir HTTP 1.0 (pas 1.1) comme version backend dans le formulaire DSM du reverse-proxy.** Reteste apres coup avec succes sur curl (ALPN h2 par defaut) ET httpx pur HTTP/1.1 -- pas de regression cote client malgre le libelle "HTTP 1.0" trompeur (mode de proxying DSM->backend moins strict sur le chunked/keep-alive, pas une vraie retrogradation cote client). A appliquer directement sur toute future regle DSM devant un service SSE/MCP si le meme blocage silencieux apparait. Detail : common/baserow-schema-mcp.md.