A feed address that serves a large file is read whole into memory #295
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
crates/feed/src/lib.rs:168 reads the whole response with resp.bytes(), with no cap on its size. Adding an episode's MP3 address as a feed by mistake, or a publisher serving something huge, makes ipx hold the whole file in memory, then fail with not_a_feed and retry at the next scan. The directory's refresher fetches feeds the same way. Tower has 4-7 GB free, so a few hundred MB of memory is noticeable. Found in a repo audit. Fix: read in chunks with a limit (say 50 MB), as the art route already does (web.rs:2181).
Fixed in
a214727: feed fetches, find_feed (adding a feed) and site_icon read the body through read_capped, 50 MB at most, refused at once when Content-Length says more. Tested with a 600 MB Content-Length in the redirect test. Deployed in ipx and ipx-directory.