- expose DEFAULT_MAX_PAYLOAD_BYTES; an inbound frame over the cap now reports its
declared byte size, message type and the effective limit, recovered by walking
the buffered frame stream so the number is right when a chunk carries several
frames, the oversized header spans chunks, or control frames are interleaved;
when the walk cannot reach a verdict the error names the cap without a size
- truncate close reasons to the RFC 6455 control-frame room on a UTF-8 boundary
(an over-long reason previously produced an invalid control frame)
- add optional maxPayloadBytes (default 100 MiB unchanged) to the three adapters
that read WebSocket frames: wsServers, wsClients and httpServers with
enableWebSocket. httpClients rejects the field because it has no WebSocket
transport, and the value is part of the binding signature so a change rebinds
the transport instead of being saved without taking effect
- keep the existing 1009 log lines and append the actionable hint instead of
replacing the template
- WebUI field (including httpServers once the embedded listener is on) and README
docs for the 100 MiB => ~445 s (7:26) inline PCM consequence
Bound the two hardcoded limits of the shared HTTP media download engine
(`loadBinarySource` / `stageSourceToDisk`) with deployment-wide environment
settings, following the existing `positiveIntEnv` convention:
- SNOWLUMA_HTTP_DOWNLOAD_TIMEOUT_MS (default 60000): one download attempt.
- SNOWLUMA_MAX_BINARY_DOWNLOAD_BYTES (default 1073741824): the implicit cap on
a binary source buffered in memory.
Both defaults are unchanged, so an unconfigured deployment behaves exactly as
before, and unusable values are logged and ignored. Callers that pass their own
ceiling keep it: group/private files and flash transfer still use 4 GiB, inline
`base64://` / `data:` flash sources keep the 1 GiB buffered-load ceiling, and
video upload has its own limit. Documented in HIGHWAY_UPLOADS.md.
KazusaUwU