The issue you're experiencing with Databricks SQL Serverless REST API in EXTERNAL_LINKS modeโwhere the external_link URL (http://storage-proxy.databricks.com/...) does not work, but you can access chunks directly via the /api/2.0/sql/statements/{statement_id}/result/chunks/{chunk_index} endpointโis reported by other users as well. This external_link is supposed to let you download result files directly, but in some environments, especially with strict firewall/proxy rules or misconfigured network access, these links can be inaccessible.โ
Key Insights
-
The external_link URLs usually point to Databricks' storage-proxy, which must be reachable from your network. If it is not, often due to proxy/firewall restrictions, you get the "site canโt be reached" error.โ
-
You are correct in using the chunk API directly (/api/2.0/sql/statements/{statement_id}/result/chunks/{chunk_index}) as a workaround. Databricks documentation supports this approach, especially for environments where external_link URLs are not accessible.โ
-
When using EXTERNAL_LINKS disposition, Databricks may not always return a next_chunk_index as expected, which seems to be a quirk or a bug in some cases. However, as you've found, iterating over the manifest's chunk indexes manually still works.โ
-
You do not need to use the external_link if the internal chunk API endpoints are working; these should be reliable as long as you have appropriate API authentication and permissions.โ
Recommendations
-
Continue using /api/2.0/sql/statements/{statement_id}/result/chunks/{chunk_index} to reliably fetch your results, especially if the external_link is not reachable from your network.โ
-
If you need to make external_link URLs work, check with your network/security admin to ensure traffic to *.databricks.com and specifically storage-proxy.databricks.com is allowlisted, and confirm no corporate proxies or firewalls are blocking access.โ
-
Monitor the Databricks release notes and known issues for updates, as this is a recurring concern and may be addressed in future platform revisions.
Your workaround is valid and in line with current documented and community-recommended practices for working around the external_link accessibility issue
