OSS Static Website Hosting Diagnosis

Diagnose Alibaba Cloud OSS static website hosting problems: "my static website opens as a download instead of rendering", "index.html is not rendered when I open the bucket URL", "did I configure the homepage and 404 page rules correctly", "can I use this bucket as a website without ICP filing", "why does my website page return 403 / stay blank".

Core approach: verify the caller identity, then read the bucket's hosting configuration (GetBucketWebsite), bucket metadata (GetBucketInfo: location / ACL) and bound custom domains (ListBucketCname). Attribute download-vs-render symptoms to concrete causes (hosting not configured, private ACL blocking anonymous access, default-domain browser download policy, missing custom domain), and conclude with evidence-based findings and manual guidance only; this skill never changes anything.

Absolute Rules

1. ABSOLUTE PROHIBITION (read-only enforcement): Under NO circumstances may you generate, write, or execute any command/script calling a mutating OSS API — e.g. PutBucketWebsite, DeleteBucketWebsite, PutBucketPolicy, PutBucketAcl, PutObject*, DeleteBucket*, or any ACL / domain-binding / hosting configuration change. This includes commands "for the user to run manually". If the user asks to enable static website hosting, set the homepage/404 rules, or bind a custom domain, only output manual console guidance and declare this skill is read-only.
2. MANDATORY entry-point enforcement: All OSS diagnostics MUST be performed by running the scripts under scripts/ (static_website_diagnosis.py as the entry, sts_token.py for identity). The Agent must not assemble its own ossutil / SDK / curl commands against the OSS control plane or bypass the scripts — the scripts embed timeout, error degradation, and observability guarantees that ad-hoc commands lack. Read the script output, interpret it, and compose the report; do not re-implement the queries.
3. ABSOLUTE PROHIBITION (credential handling): Never read, print, or pass AK/SK/STS tokens explicitly. The OSS SDK resolves credentials exclusively from the environment variables of the default credential chain; the identity check uses the aliyun CLI default credential chain; the default-domain probe is anonymous and credential-free. Never accept AK/SK from the user or from another script.
4. NO FABRICATION: Every conclusion must be grounded in data actually returned by GetBucketWebsite / GetBucketInfo / ListBucketCname / the anonymous probe / GetCallerIdentity. If a query fails or returns empty, record it and state the limitation — never invent hosting rules, domain bindings, or probe results. Empty / not-found is a valid and complete conclusion — if the bucket does not exist, has no hosting configuration, or all queries return empty, that IS the final answer: report it and STOP. Never react to empty / not-found results by attempting to create, verify, test, validate, or repair the resource, and never fall back to hand-written CLI calls. Stay within the read-only entry-script flow at all times.
5. EXECUTION RULE FOR ERRORS: On any API error, log [WARN] <category>: <message> to stderr, continue with the remaining steps, and still produce the final report with STATUS: DEGRADED and a NEXT_ACTION line — never silently skip or abort without a report. Note: NoSuchWebsiteConfiguration (404) from GetBucketWebsite is a legitimate FINDING ("hosting not configured"), not an error.
6. SCOPE BOUNDARY: This skill only answers static website hosting questions (hosting config verification, homepage/404 rule semantics, render-vs-download attribution, custom-domain / ICP filing requirements). It does NOT handle hotlink protection (Referer anti-hotlinking), the domain binding procedure itself, generic default-domain direct-access link problems, or object-level errors — for such requests, state the boundary and defer to alibabacloud-oss-direct-access-link-diagnosis with manual guidance only.

Official Doc Verification

MANDATORY: For configuration or usage questions, the entry script MUST be invoked with --question "". The script first matches embedded knowledge, then verifies against official OSS docs (doc_verification, llms-index). The final answer MUST cite the URLs from doc_verification.docs. If doc_verification.note starts with DEGRADED, state explicitly: "Unable to verify against online official docs (offline)." Never fabricate doc URLs; only URLs returned by the script may be cited.