fix(api): close request-size gaps in body and history caps

Two hardening gaps around the existing request bounds:

- The oversized-body middleware only checked Content-Length, so a
chunked request bypassed the cap entirely. Replace it with a pure
ASGI middleware that keeps the header fast-path 413 and counts the
bytes actually delivered on the receive channel.
- History turns extracted from the AI-SDK messages field were not held
to MAX_TURN_CHARS (only payload.history is, via its Field cap), so a
single message under MAX_MESSAGE_JSON_CHARS could carry a ~190k-char
turn into the model call. Truncate extracted turns to the same bound;
truncation rather than 422 because the oversized text already sits in
the client transcript and rejecting would wedge the conversation.

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

app/api.py

@@ -10,11 +10,12 @@ from typing import Any, AsyncIterator
 from uuid import uuid4
 
 import uvicorn
-from fastapi import FastAPI, HTTPException, Request
+from fastapi import FastAPI, HTTPException
 from fastapi.middleware.cors import CORSMiddleware
 from fastapi.responses import JSONResponse, StreamingResponse
 from fastapi.staticfiles import StaticFiles
 from pydantic import BaseModel, Field, field_validator
+from starlette.types import ASGIApp, Message, Receive, Scope, Send
 
 from .chat_service import (
     is_anthropic_model,
@@ -130,21 +131,60 @@ async def lifespan(_app: FastAPI) -> AsyncIterator[None]:
 app = FastAPI(title="AI Tutor API", lifespan=lifespan)
 
 
-@app.middleware("http")
-async def reject_oversized_bodies(request: Request, call_next):
+class BodySizeLimitMiddleware:
     """Refuse multi-megabyte bodies before parsing them. Pydantic caps bound
-    the fields, but only after the whole body is read and JSON-decoded."""
-    content_length = request.headers.get("content-length")
-    try:
-        too_large = content_length is not None and int(content_length) > MAX_BODY_BYTES
-    except ValueError:
-        too_large = False
-    if too_large:
-        return JSONResponse(
-            {"detail": "Request body too large"},
-            status_code=413,
-        )
-    return await call_next(request)
+    the fields, but only after the whole body is read and JSON-decoded.
+
+    The Content-Length check rejects honest oversized requests before any
+    body byte is read; the receive wrapper counts the bytes actually
+    delivered, so a chunked request (no Content-Length) can't bypass the cap.
+    The mid-body HTTPException surfaces inside FastAPI's body read, which
+    re-raises middleware HTTPExceptions unchanged, so the client still gets
+    a clean 413 instead of a generic parse error.
+    """
+
+    def __init__(self, app: ASGIApp, max_bytes: int) -> None:
+        self.app = app
+        self.max_bytes = max_bytes
+
+    async def __call__(self, scope: Scope, receive: Receive, send: Send) -> None:
+        if scope["type"] != "http":
+            await self.app(scope, receive, send)
+            return
+
+        for name, value in scope.get("headers") or ():
+            if name != b"content-length":
+                continue
+            try:
+                declared = int(value)
+            except ValueError:
+                break
+            if declared > self.max_bytes:
+                response = JSONResponse(
+                    {"detail": "Request body too large"},
+                    status_code=413,
+                )
+                await response(scope, receive, send)
+                return
+            break
+
+        received = 0
+
+        async def limited_receive() -> Message:
+            nonlocal received
+            message = await receive()
+            if message["type"] == "http.request":
+                received += len(message.get("body") or b"")
+                if received > self.max_bytes:
+                    raise HTTPException(
+                        status_code=413, detail="Request body too large"
+                    )
+            return message
+
+        await self.app(scope, limited_receive, send)
+
+
+app.add_middleware(BodySizeLimitMiddleware, max_bytes=MAX_BODY_BYTES)
 
 
 app.add_middleware(
@@ -205,6 +245,19 @@ def build_chat_request(payload: ApiChatRequest) -> ChatRequest:
             # the turn in history would make the model see it twice.
             if history[-1].role == "user" and history[-1].content.strip() == query:
                 history = history[:-1]
+        # The ApiChatTurn Field cap only bounds payload.history; turns
+        # extracted from the AI-SDK messages list must obey the same per-turn
+        # bound (MAX_MESSAGE_JSON_CHARS is far larger because a message can
+        # carry several tool outputs). Truncate rather than 422: only the
+        # rendered text is capped (tool outputs don't survive extraction),
+        # and the oversized text already sits in the client's transcript, so
+        # rejecting it would wedge the whole conversation.
+        history = tuple(
+            turn
+            if len(turn.content) <= MAX_TURN_CHARS
+            else ChatTurn(role=turn.role, content=turn.content[:MAX_TURN_CHARS])
+            for turn in history
+        )
 
     if not query:
         raise HTTPException(status_code=422, detail="query is required")

tests/test_api.py

@@ -631,6 +631,69 @@ class ApiTestCase(unittest.TestCase):
 
         self.assertEqual(response.status_code, 413)
 
+    def test_chat_rejects_oversized_chunked_body(self) -> None:
+        """A chunked request carries no Content-Length, so the header check
+        alone would admit an arbitrarily large body; the byte counter on the
+        receive channel must still refuse it."""
+        from app.api import MAX_BODY_BYTES
+
+        body = json.dumps({"query": "x" * (MAX_BODY_BYTES + 1)}).encode()
+
+        def chunks() -> Iterator[bytes]:
+            for start in range(0, len(body), 64 * 1024):
+                yield body[start : start + 64 * 1024]
+
+        with TestClient(app) as client:
+            response = client.post(
+                "/api/chat",
+                content=chunks(),
+                headers={"content-type": "application/json"},
+            )
+
+        self.assertEqual(response.status_code, 413)
+
+    def test_history_turns_from_messages_are_capped(self) -> None:
+        """payload.history is Field-capped at MAX_TURN_CHARS, but turns
+        extracted from the AI-SDK messages list weren't: a message under
+        MAX_MESSAGE_JSON_CHARS could smuggle a ~190k-char history turn.
+        Extracted turn text is truncated (not 422d: the text already sits in
+        the client transcript, and tool outputs don't survive extraction)."""
+        from app.api import MAX_TURN_CHARS, ApiChatRequest, build_chat_request
+
+        oversized = "y" * (MAX_TURN_CHARS + 1000)
+        request = build_chat_request(
+            ApiChatRequest(
+                query="What is RAG?",
+                messages=[
+                    {"role": "assistant", "content": oversized},
+                    {
+                        "role": "user",
+                        "parts": [{"type": "text", "text": "What is RAG?"}],
+                    },
+                ],
+            )
+        )
+
+        self.assertEqual(len(request.history), 1)
+        self.assertEqual(request.history[0].role, "assistant")
+        self.assertEqual(len(request.history[0].content), MAX_TURN_CHARS)
+
+        # The same cap holds when the query is extracted from the trailing
+        # message instead of being passed explicitly.
+        no_query = build_chat_request(
+            ApiChatRequest(
+                messages=[
+                    {"role": "assistant", "content": oversized},
+                    {
+                        "role": "user",
+                        "parts": [{"type": "text", "text": "What is RAG?"}],
+                    },
+                ]
+            )
+        )
+        self.assertEqual(no_query.query, "What is RAG?")
+        self.assertEqual(len(no_query.history[0].content), MAX_TURN_CHARS)
+
     def test_chat_stream_emits_heartbeat_during_quiet_gap(self) -> None:
         """A silent stretch between events must put SSE comment frames on the
         wire so reverse proxies don't idle the connection out."""