# Downloading issues

**URL:** <https://www.simscale.com/forum/t/downloading-issues/101397>\
**Category:** Using SimScale\
**Created:** [October 15, 2026, 2:16pm UTC](https://www.simscale.com/forum/t/downloading-issues/101397 "2026-10-15T14:16:04Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![chazijian](https://www.simscale.com/forum/letter_avatar/chazijian/32/5_5575768a8748004e209b776fc1b2916d.png) [@chazijian](https://www.simscale.com/forum/u/chazijian)\
**Post date:** [October 15, 2026, 2:16pm UTC](https://www.simscale.com/forum/t/downloading-issues/101397/1 "2026-10-15T14:16:04Z")

</div>

**Hi everyone,**

I’m running a steady-state incompressible case ( **SIMPLE** , **k-omega SST** , ~15.3 M cells, four `meanVelocityForce` momentum sources) and I’ve hit a wall with **downloading results** , so I’d appreciate any advice.

### **The problem**

The `SOLUTION_FIELDS` component for one run is reported as **34 GB** (a later, shorter run is ~17 GB). Downloading it is unreliable because **the transfer cannot be resumed** — if the connection drops once, it restarts from byte 0. In practice I could not complete the 34 GB package.

### **What the server returns**

http

```auto
GET /api/v2/load/projects/<projectId>/results/<resultUuid>/components/<componentUuid>/solutions?token=<redacted>&uid=<redacted>
Range: bytes=0-1023

```

http

```auto
HTTP/1.1 200 <-- expected 206 Partial Content
Content-Type: application/octet-stream
Content-Disposition: attachment; filename="result.zip"
Transfer-Encoding: chunked <-- no Content-Length
Via: 1.1 ...cloudfront.net (CloudFront)
X-Amz-Cf-Pop: FRA56-P10
Alt-Svc: h3=":443"; ma=86400

```

Observations:

- I sent `Range: bytes=0-1023` and got `200`, not `206`.
- There is **no** `Content-Range` header and **no** `Accept-Ranges` header.
- The response is `chunked` with **no** `Content-Length`.

My guess is that because the origin streams the archive, CloudFront cannot serve range requests for it — but I’d be glad to be corrected.

### **What I have already tried**

| Method | Result |
| --- | --- |
| `curl` (plain) | drops mid-transfer; no way to continue |
| `curl --retry-all-errors` | **worse** — it truncates the partial file and restarts from 0 |
| `curl -C -` (resume) | cannot work, since the server ignores `Range` |
| Windows **BITS** (`Start-BitsTransfer`) | fails immediately with a TLS error: _“A security channel could not be supported”_ |
| **Edge** browser download | also restarts from the beginning on a drop |

I’m located in **Shanghai** , and my requests appear to be served by the **Frankfurt PoP** (`X-Amz-Cf-Pop: FRA56-P10`), which may be part of why the connection is fragile.

### **My questions**

1. **Is resumable download of** `SOLUTION_FIELDS` **supported at all?** If there is a supported way to get `Range`/`206` behaviour, or to download the package in **multiple parts** , I’d love to know how.

2. **Can individual files inside the result package be retrieved without downloading the whole archive?** This is what would really solve my problem. I only need a handful of small files, for example:

3. If neither is possible, is there a **recommended way to transfer very large result packages reliably** (a CLI tool, a direct storage URL, an endpoint/region choice, or simply “download from a different network”)? A definitive “this is not supported” answer is also useful — then I can at least plan disk space and transfer windows.

### **Notes**

- The small companion components are fine — `RESIDUALS_PLOT`, `INLETS_PLOT`, `OUTLETS_PLOT`, `DOMAIN_PLOT`, `WALLS_PLOT` all download without trouble (they’re a few hundred KB). It’s only the large `SOLUTION_FIELDS` archive that is problematic. This is actually why I’m asking question 2 — those small components are served per-component, so I hoped the same might be possible for individual files.
- I’m happy to share the project / run / component UUIDs privately if a staff member wants to reproduce this.

Thanks in advance for any pointers — even a “not supported, here’s what people usually do” would help me plan.