The previous fix only stopped passing range options for range-less
GETs, but current workerd reports a DEFINED full-span object.range even
for a plain get() with empty options — so every response still went out
206 + Content-Range and Firefox still refused to execute the editor
glue. Verified against local workerd (wrangler dev + seeded R2): the
206 branch must key off the REQUEST having asked for a range.
Plain GET now 200 with full body; Range requests still get proper 206s.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PmR6goSk7JC17h7fkgGvHG
env.BUCKET.get(key, { range: request.headers }) makes R2 report a
DEFINED object.range (full span) even when the request carried no Range
header, so every plain GET went out as 206 + Content-Range. Chrome
executes a 206 <script>; Firefox fires onload but refuses to EXECUTE
the script — on hosts with no masking edge cache (staging workers.dev)
the injected editor glue never ran: no [KICAD_STATUS] logs, heap 0MB,
'runtime did not initialize (no FS) in 90s' on every Firefox boot.
Prod's cdn.pcbjam.com zone cache normalizes cached hits to 200, which
is why only staging surfaced it; cold prod objects share the bug.
Pass the range option only when the request actually sent a Range.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PmR6goSk7JC17h7fkgGvHG
