Rapids Request Timeout Now Covers Streaming Responses

What's changed

• A container's request timeout (300 seconds by default, up to 3600, set as Request timeout (seconds) under Runtime on the container's Edit page) used to stop a request only while it had not started to answer. It now limits the whole request, including a response that is already streaming.
• A stream without a Content-Length, such as Server-Sent Events or other chunked output, ends at the timeout: the status stays the one your app sent and the body ends with the text request timeout, so nothing in HTTP marks the stream as incomplete.
• A download with a Content-Length closes before all the bytes arrive, so the client reports an incomplete transfer. A request still waiting for its first byte gets 504 Gateway Timeout as before, and WebSocket connections were already closed at the timeout.
• If your app streams or keeps connections open longer than its timeout, raise the request timeout on the Edit page (up to 3600 seconds) and have clients reconnect: a browser EventSource reconnects by itself, and WebSocket clients and download tools need their own retry.
• If a client must be able to tell a complete stream from a cut one, send your own end marker as the last event and check for it.