`GET /files is redirected to DNSPod webblock while POST /files and process API work on custom sandbox domain`

[zhangningshitiancai-rgb]

Question

Environment

• CubeSandbox Python SDK: cubesandbox 0.2.1
• Deployment: self-hosted CubeSandbox on Tencent Cloud CVM
• Sandbox domain configured by CubeSandbox server:
  • CUBE_API_SANDBOX_DOMAIN=sandbox.usersandbox.online
• Control API:
  • http://43.137.46.230:3000
• Sandbox data-plane host format:
  • 49983-<sandbox_id>.sandbox.usersandbox.online

Problem

When using the Python SDK sandbox.files.read(path), the SDK sends:

GET http://49983-<sandbox_id>.sandbox.usersandbox.online/files?path=/workspace/test.txt&username=root

This request is redirected to DNSPod webblock:

HTTP/1.1 302
Location: https://dnspod.qcloud.com/static/webblock.html?d=49983-<sandbox_id>.sandbox.usersandbox.online

Because the SDK HTTP client follows redirects, sandbox.files.read() returns the DNSPod HTML page instead of the file content.

However, the following APIs work on the same host:

POST /files
POST /process.Process/Start

So DNS resolution and CubeProxy routing are not completely broken.

## Reproduction

from cubesandbox import Config, Sandbox
from cubesandbox._commands import ENVD_PORT

cfg = Config(
    api_url="http://43.137.46.230:3000",
    template_id="<template_id>",
    timeout=300,
)

sb = Sandbox.create(config=cfg, timeout=300)
host = sb.get_host(ENVD_PORT)

print("sandbox_id =", sb.sandbox_id)
print("domain =", sb.domain)
print("host =", host)

path = "/workspace/sdk-file-probe.txt"

# 1. SDK write works
sb.files.write(path, b"SDK_WRITE_OK")

# 2. Verify file was really written through process API
result = sb.commands.run("cat /workspace/sdk-file-probe.txt", cwd="/workspace", timeout=60)
print("command cat stdout =", repr(result.stdout))
# Output: 'SDK_WRITE_OK'

# 3. SDK read does not return the file content
text = sb.files.read(path)
print(text[:300])
# Actual: DNSPod webblock HTML

## Additional HTTP diagnostics

Using the same sandbox host:

GET  http://49983-<sandbox_id>.sandbox.usersandbox.online/
-> 302
-> Location: https://dnspod.qcloud.com/static/webblock.html?d=49983-<sandbox_id>.sandbox.usersandbox.online

GET  http://49983-<sandbox_id>.sandbox.usersandbox.online/files
-> 302
-> Location: https://dnspod.qcloud.com/static/webblock.html?d=49983-<sandbox_id>.sandbox.usersandbox.online

POST http://49983-<sandbox_id>.sandbox.usersandbox.online/files
-> 200
-> server: openresty
-> x-cube-retcode: 310200

POST http://49983-<sandbox_id>.sandbox.usersandbox.online/process.Process/Start
-> works

I also tested direct IP access with the sandbox Host header:

GET http://43.137.46.230/files
Host: 49983-<sandbox_id>.sandbox.usersandbox.online

It still redirects to DNSPod webblock.

## Expected Behavior

sandbox.files.read(path) should return the file content.

## Actual Behavior

sandbox.files.read(path) returns DNSPod webblock HTML because GET /files is redirected.

## Important Observation

sandbox.files.write(path, bytes) works for text, UTF-8 text, PNG image, and ZIP/binary files. I verified the written files through
commands.run() with matching sha256.

Examples:

unicode.txt: sha256 matched
pixel.png:   sha256 matched
sample.zip:  sha256 matched

So files.write() works, but files.read() fails because it uses GET /files.

## Questions

1. Is GET /files expected to work with a custom sandbox domain on Tencent Cloud CVM?
2. Is the DNSPod webblock redirect caused by ICP filing / domain compliance requirements?
3. Does CubeSandbox recommend a different configuration for custom sandbox domains to make GET /files work?
4. Could the SDK provide a fallback read implementation through the process API, or expose a POST/RPC-based file read endpoint to
   avoid GET-based webblock issues?

[tinklone]

Thanks for the detailed report and diagnostics.

We will make the following improvements and recommendations:

1. We will fix the follow_redirects=True behavior in the Python SDK.

   Currently, files.read() may silently follow a redirect to the DNSPod webblock page and return the HTML content as if it were the actual file content. This is misleading. We will update the SDK so that such redirects are detected properly and reported as clear errors instead of being treated as successful file reads.

2. Starting from CubeSandbox 0.3.0, CubeProxy supports path-based sandbox access:

   http://<cube-proxy-host>:<http-port>/sandbox/<sandbox-id>/<container-port>/<rest>?<query>
   

   For example:

   http://<cube-proxy-host>:80/sandbox/<sandbox-id>/49983/files?path=/workspace/test.txt&username=root
   

   This access mode does not rely on wildcard domain routing or sandbox virtual host routing such as:

   49983-<sandbox-id>.<sandbox-domain>
   

   CubeProxy will strip the /sandbox/<sandbox-id>/<container-port> prefix before forwarding the request to the sandbox service, so the upstream envd service still receives the original path, such as /files.

We will also add Python SDK support for this CubeProxy path-based access mode, so users can configure the SDK to access sandbox data-plane APIs through:

http://<cube-proxy-host>:<http-port>/sandbox/<sandbox-id>/<container-port>/<rest>?<query>