No way to cap how large a request body a route will accept

An upload endpoint with no size cap is a resource-exhaustion vector -- intentional (a hostile client deliberately sending a huge body to exhaust gateway or upstream memory/disk) or accidental (a buggy client retry-looping a multi-GB file). This gateway already proved, at some effort, that it can stream a 700MB response through without buffering it; a size limit implemented by buffering the request body would throw away exactly that property on the other side of the same connection.

RouteConfig.max_request_body_bytes exists as a field (default None = unlimited) so it can be set in routes.yaml or via the admin API, but nothing reads it. A client can stream an arbitrarily large request body into any route and the gateway will happily forward every byte upstream, no matter what.

1. pytest practice_tickets/tests/test_ticket_11_max_request_body_size.py -v.
2. Or manually: configure a route with max_request_body_bytes: 1000 and POST a 2000-byte body to it.
3. Observe: the full body is forwarded upstream regardless of size; no 413 is ever returned.

request.stream() is an async generator that Starlette drains lazily, one chunk at a time, straight from the client socket. A size limit has to be enforced by counting bytes as they pass through that generator -- raising as soon as the running total crosses the limit -- not by materializing the whole body first and checking its length afterward, which would defeat the gateway's core streaming guarantee for every request on a size-limited route.

send_upstream_request currently passes request.stream() directly as content=. Consider wrapping it in your own async generator that increments a running total per chunk and raises once the total exceeds route.max_request_body_bytes, then yields chunks through unchanged until then -- the wrapper is what actually gets passed to httpx instead of the raw stream. Look at how / are defined and caught in for the pattern to follow when turning your new exception into a 413 response.