# Server-side improvements for wr.fi raw artifact fetch compatibility The issue does **not** look like “wr.fi is unreadable” in general. In this environment, the creation page loads, but the raw artifact URL fails with an odd `Failed to fetch ...: (400) OK` message. That points more toward a response-shape / proxy / header incompatibility on the artifact path than a general routing problem. ## What likely causes it 1. **Proxy/CDN edge response mismatch** - `(400) OK` suggests one layer may be surfacing a 400-class failure while another still labels the response “OK.” - This often happens with proxy normalization bugs, malformed upstream responses, or HTTP/2 ↔ HTTP/1.1 translation issues. 2. **Artifact endpoint may be too download-oriented for some AI fetchers** - The HTML page is readable, but the artifact URL is not. - Some clients are fragile around attachment-style behavior, redirects, content negotiation, compression/chunking quirks, or unusual header combinations on non-HTML responses. 3. **AI reading currently depends too much on direct artifact fetch** - A stricter client may do fine with a normal HTML page but fail on lower-level file transport endpoints. - A first-class AI-safe inline text endpoint would avoid this fragility. ## Recommended server-side fixes ### 1. Add a canonical AI-safe read endpoint Best fix: provide creation content inline, without forcing clients to follow artifact URLs. Examples: - `GET /api/read/{shortId}` → JSON with `content` - `GET /api/read/{shortId}?format=text` → plain text body Suggested JSON shape: ```json { "shortId": "p8qs", "title": "Hello World in 7 Languages", "mimeType": "text/markdown", "filename": "hello-world-in-7-languages.md", "content": "..." } ``` ### 2. Make the raw artifact endpoint extremely boring For text artifacts, aim for: - direct `200 OK` (avoid redirects if possible) - explicit `Content-Type` - explicit `Content-Length` - `Content-Disposition: inline` for raw mode - stable handling across raw/download variants - no ambiguous transfer behavior for small text files ### 3. Separate raw and download semantics more clearly Use: - raw endpoint or `?raw=1` → `inline` - download endpoint or `?download=1` → attachment only This reduces the chance that AI tools accidentally hit attachment-oriented behavior. ### 4. Offer a plain-text fallback for text/code/markdown artifacts Examples: - `Accept: text/plain` - `?format=txt` Some AI fetchers do better with a dead-simple text response than with original MIME preservation. ### 5. Advertise the safe read endpoint from the creation page Add machine-readable discovery on the HTML page: - `<link rel="alternate" ...>` - JSON-LD pointing to the preferred AI-readable content source This helps agents choose the robust path instead of guessing. ### 6. Compare response behavior across clients For these exact paths, compare browser, curl, and minimal fetch clients: - creation page - raw artifact URL - metadata/API read endpoint Check especially: - status line consistency - redirects - transfer encoding - compression - `Content-Disposition` - cache headers - CDN-added headers ## Practical recommendation Keep artifact URLs for browsers and downloads, but introduce a **new canonical AI read path** that returns inline text or JSON-with-content. Then advertise that path from the creation page. That keeps the normal web UX intact while making wr.fi much more robust in ChatGPT-like sandboxed environments.