hls2euwest.blob.core.windows.net has no CORS configuration — inconsistent with other public data containers (sentinel2l2a01, landsateuwest)

[hgs-mfien]

Summary

The blob container hls2euwest.blob.core.windows.net, which serves HLS v2 assets
for the hls2-l30 and hls2-s30 collections, has no CORS rules configured.
Every browser-based fetch of HLS COG assets fails at preflight with an
Azure-generated CorsPreflightFailure error. Other Planetary Computer public
data containers (sentinel2l2a01.blob.core.windows.net,
landsateuwest.blob.core.windows.net) return permissive CORS headers and work
correctly for any origin. Looks like the HLS2 container was provisioned without
the CORS rule set that the other public data containers received.

Reproduction

Preflight OPTIONS against the HLS2 container:

curl -X OPTIONS

'https://hls2euwest.blob.core.windows.net/hls2/L30/12/S/UB/2020/12/14/HLS.L30.T12SUB.2020349T180421.v2.0/HLS.L30.T12SUB.2020349T180421.v2.0.B01.tif'

-H 'Origin: https://example.com/'

-H 'Access-Control-Request-Method: GET'

-H 'Access-Control-Request-Headers: range'

-i

Response:

HTTP/1.1 403 CORS not enabled or no matching rule found for this request.
x-ms-request-id: 1e7abf3a-b01e-006a-65fa-366336000000
x-ms-version: 2015-02-21

CorsPreflightFailure CORS not enabled or no matching rule found for this request. No CORS rules matches this request ```

Same request against sentinel2l2a01.blob.core.windows.net (works):

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: GET
Access-Control-Allow-Headers: range
Access-Control-Max-Age: 3600
Access-Control-Allow-Credentials: true
Same request against landsateuwest.blob.core.windows.net (works):

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: GET
Access-Control-Allow-Headers: range
Access-Control-Max-Age: 3600
Access-Control-Allow-Credentials: true

Expected
hls2euwest.blob.core.windows.net should return the same permissive CORS
headers as sentinel2l2a01 and landsateuwest, allowing browser-based
consumers to fetch HLS COG assets with Range requests (required for
partial COG reads that avoid downloading whole files).

Actual
Every browser-initiated fetch of an HLS asset from this container is blocked
at CORS preflight. Server-to-server fetches with a valid SAS URL succeed —
the failure is exclusively browser-side, exactly matching a "no CORS rules
on this storage account" configuration.

Impact
All browser-based consumers of HLS v2 data via PC (map viewers, dashboards, Jupyter notebooks doing browser rendering, any Web app using HLS) cannot fetch assets directly. They must implement a server-side proxy to work around it.
The inconsistency with the sibling public data containers strongly suggests a container-provisioning oversight rather than an intentional access restriction — HLS is presumably meant to be publicly consumable like S2 and Landsat.
HLS v2 launched with a specific mission to be a harmonized, easily-consumable cross-sensor product; the current CORS state defeats the "easily-consumable from the browser" half of that value proposition.

Environment
Container observed: hls2euwest.blob.core.windows.net
Collections affected: hls2-l30, hls2-s30 (both back to this container)
SAS URL provider: PC data-access API (https://planetarycomputer.microsoft.com/api/sas/v1/token/...)
Working comparison containers: sentinel2l2a01.blob.core.windows.net, landsateuwest.blob.core.windows.net
Failing preflight x-ms-request-id: 1e7abf3a-b01e-006a-65fa-366336000000 (2026-08-28T14:33:51Z — useful for looking up the specific request in your logs if helpful)
Browsers reproduced in: Chromium 151 (also standard browser CORS behavior — Chrome, Firefox, Safari should all block identically)