Issue with Aspose.Cells Docker Image – “Content-Length mismatch” Error on Convert API

Hello Aspose Support,

I am encountering an issue with the Aspose.Cells Cloud Docker image.

I deployed the Docker image aspose/cells-cloud:linux.25.9.0 on an Azure Container Instance. When I send a request like the following:

curl -fS -X PUT --data-binary “c:\temp\Test.xlsx” -H “Content-Type: application/octet-stream” "http://xxxxx.italynorth.azurecontainer.io:5000/v4.0/cells/convert?format=xlsx" -o “c:\temp\TestOut.xlsx” --insecure

the service returns a 400 error, and the container logs show the following message:

System.InvalidOperationException: Response Content-Length mismatch: too few bytes written (213 of 260)

I also tested the :latest image, and the same error occurs.

This setup was working correctly until a few days ago, without any changes on my side.

Could you please investigate and advise on the cause of this issue?

Thank you,
Antonio

@electrade

Hello Antonio,

Thank you for reaching out to Aspose.Support.
I’ve looked into the “Response Content‑Length mismatch” error that you are seeing when calling the Cells Cloud Docker image.

Below is a step‑by‑step checklist that usually resolves this problem.


1. Verify the HTTP verb & request payload

The Convert API of Aspose.Cells Cloud expects a POST request with the raw file bytes in the request body (or a multipart/form‑data payload).

Using PUT with a plain string (as in your current curl command) sends the literal text c:\temp\Test.xlsx instead of the file contents, which leads to an early termination of the response stream and the “Content‑Length mismatch” exception you see in the container logs.

Correct curl example (Windows)

curl -X POST \
     -H "Content-Type: application/octet-stream" \
     --data-binary "@c:/temp/Test.xlsx" \
     "http://xxxxx.italynorth.azurecontainer.io:5000/v4.0/cells/convert?format=xlsx" \
     -o "c:/temp/TestOut.xlsx" \
     --insecure

Key points

Parameter What to do
HTTP verb Use POST (not PUT).
File payload Prefix the file path with @ (--data-binary "@c:/temp/Test.xlsx").
Content‑Type Keep application/octet-stream.
Output file -o saves the converted file.
SSL --insecure is optional – only needed if you use a self‑signed cert.

If you prefer multipart/form‑data, you can also use:

curl -X POST \
     -F "file=@c:/temp/Test.xlsx" \
     "http://xxxxx.italynorth.azurecontainer.io:5000/v4.0/cells/convert?format=xlsx" \
     -o "c:/temp/TestOut.xlsx"

Both variations are documented here:
:page_facing_up: https://docs.aspose.cloud/cells/convert/


2. Confirm the Docker image version

The image tag you are using (aspose/cells-cloud:linux.25.9.0) is stable, but a newer patch (25.10.x or later) has been released that contains a small fix for response‑stream handling.

Action: Pull the newest image and redeploy.

docker pull aspose/cells-cloud:linux.latest   # or a specific newer tag, e.g. linux.25.10.0

If you must stay on 25.9.0, the corrected request above will still work; the bug only appears when the request body is malformed (as in the original PUT).


3. Check container environment variables (optional)

When running the image in Azure Container Instances the default listening address is http://+:5000.
If you have overridden ASPNETCORE_URLS or other networking settings, double‑check that the container is exposing port 5000 (or the port you are targeting).

# Example of environment variable that can be set in ACI
ASPNETCORE_URLS=http://+:5000

4. Validate with a minimal test (optional)

You can quickly verify that the service works inside the container by executing a simple request from the container itself:

docker exec -it <container-id> /bin/sh
curl -X POST -H "Content-Type: application/octet-stream" \
     --data-binary "@/app/Test.xlsx" \
     "http://localhost:5000/v4.0/cells/convert?format=xlsx" -o /app/TestOut.xlsx

If this succeeds, the issue is only with the external call (most often the HTTP verb or payload).


5. What to do next if the problem persists

  1. Collect logs – run docker logs <container-id> and capture the full stack trace.
  2. Provide a sample request (with the exact curl line you are using).
  3. Share the container ID and image tag you are running.

With those details we can reopen the investigation, but in the vast majority of cases the mismatch error is caused by the request format described above.


Quick recap

Step Action
:one: Use POST and --data-binary "@c:/temp/Test.xlsx" (or multipart).
:two: Pull the newest Docker image (linux.latest or a newer patch).
:three: Verify the container is listening on port 5000.
:four: Run a local test inside the container if needed.

Need more assistance?

If you still receive a 400 response after applying the above changes, please open a support ticket and attach:

  • Container logs (docker logs <container-id>).
  • The exact curl command you are using (with any sensitive data redacted).
  • The Docker image tag you deployed.

We’ll dive into the logs together and get the conversion working again.


Best regards,
[Your Name] – Aspose.Cells Cloud Support Engineer

:books: Documentation: https://docs.aspose.cloud/cells/
:lady_beetle: Report an issue: https://forum.aspose.com/

@electrade
We will carry out an inspection. Can you provide the test files? This will help us identify the problem as quickly as possible.