Repository navigation
View text files inline in the pod filesystem browser #1581
Description
Problem
Radar’s Pod filesystem browser already lists and downloads files, but every file is forced to download. Operators cannot quickly inspect a small text configuration or log-like file in the UI.
Scope
Add an inline viewer for safe, size-bounded text files in the existing Pod filesystem browser. This is deliberately read-only; pod-file editing and upload are separate work.
Acceptance criteria
- A user can open a supported text file in an inline viewer instead of downloading it.
- Downloads remain available and unchanged.
- Binary, oversized, or unreadable files show a clear fallback/error state rather than attempting to render.
- The backend enforces a conservative size limit before buffering or returning content.
- Preserve the existing pod-exec RBAC/capability gate.
- Add focused backend and frontend tests for the supported, binary, oversized, and failure paths.
Pointers
- Existing backend browse/download implementation:
internal/server/copy.go - Existing UI:
web/src/components/resources/PodFilesystemModal.tsx - Pod exec/capability plumbing is already shared; reuse it rather than adding a new authorization path.
Please comment before starting so we can coordinate the file-type and size-limit UX.
Activity
changyonggang commentedon Sep 4, 2026
Interested in picking this up — coordinating on the two UX calls before writing code, as the issue asks.
My working assumptions (happy to adjust):
1. Size cap
io.LimitReader) before buffering.HEAD-equivalent stat first so oversized files short-circuit with an explicit error instead of a truncated preview.2. What counts as "text"
statshows size > cap.http.DetectContentType— accepttext/*,application/json,application/xml,application/x-yaml.nginx.confthat sniff asapplication/octet-stream): reject if any NUL byte appears in the first 8 KiB, otherwise accept astext/plain; charset=utf-8.3. Encoding
4. UX affordance
5. Backend shape
Do these numbers/decisions match what you had in mind, or should I adjust the cap, the sniff set, or the endpoint shape before starting? Happy to change any of it.
docs: add a Claiming an Issue section to CONTRIBUTING (#1635)
changyonggang commentedon Sep 8, 2026
Following up under the new
CONTRIBUTING.mdprocess — could I be assigned to this? Happy to proceed on the assumptions in my earlier comment (1 MiB cap, layered MIME + NUL-byte sniff, UTF-8 v1, Monaco read-only,GET /api/pods/{ns}/{name}/file), and equally happy to adjust any of them if you'd rather land somewhere different before I start.nadaverell commentedon Sep 8, 2026
yes, assigned - thanks!
suggestion sounds like a good start. try to test it in various scenarios to see that both the good and bad cases behave as intended (e.g. if you try to read a huge file, or a non-text file, or an empty file - that the UI makes sense, shows you errors that make it clear what happened - probably want curated error message rahter than only dumping raw error)
feat(pod-file-browser): inline preview for size-bounded text files (#…