Read the mono workspace and vxdata-api/dashboard frontend guidance plus the histo knowledge indexes.
Traced s3:// HistoScan and HistoMap URLs through vxdata-api GET presigning into the dashboard geotiff browser reader.
Checked the viewer dependency’s request behavior: it sends GET requests with single byte ranges, requires 206 responses, and does not issue HEAD requests.
Found that object-store CORS is not configured in mono and the frontend itself records that the S3 endpoint sends no Access-Control-Allow-Origin; the dev-only proxy exists but the histology viewer does not use its URL rewrite helper.
Identified additional failure modes: hour-long presigned URLs are cached indefinitely; tile errors and overlay resolution errors are swallowed; and overlays ignore their resolved source type, so mixed local/S3 or TIFF/Zarr sources fail.
No product code was changed. No deployed Ceph credentials or safe deployed endpoint were available for a live probe.
Lessons Learned: Pitfalls
API CORS and object-store CORS are separate. vxdata-api CORS cannot help TIFF bytes because the browser fetches the presigned object URL directly.
Accept-Ranges is useful evidence but the viewer’s real contract is a readable cross-origin 206 response with Content-Range; a full-file 200 is explicitly rejected.
A presigned GET URL should not be assumed to support HEAD. The current viewer does not need HEAD.
Lessons Learned: Improvements
Add a durable histo serving SOP with the exact Ceph bucket CORS contract and a browser-level range probe.
Add an integration test that loads a real pyramidal TIFF from an S3-compatible service, pans/zooms, enables a map overlay, and checks request status and headers.
Document whether production presigns use a browser-reachable public gateway rather than an internal service hostname.
