DIYgod/RSSHub · error · Error

HTTP error! status: ${res.status}

Error message

HTTP error! status: ${res.status}

What it means

Thrown inside the Iwara subscriptions route's in-page `fetch` wrapper: it evaluates a `fetch(...)` call inside the Playwright page context and, if `res.ok` is false, throws `Error('HTTP error! status: <code>')`. This surfaces the HTTP status of the Iwara API call (login, user info, or subscriptions) as seen by the browser page. Common statuses: 401 (bad/expired credentials), 403 (blocked/forbidden), 429 (rate limit), 5xx (Iwara outage).

Source

Thrown at lib/routes/iwara/subscriptions.ts:88

    const password = config.iwara.password;

    const { page, destroy } = await getPlaywrightPage(rootUrl, {
        gotoConfig: {
            waitUntil: 'domcontentloaded',
        },
    });

    try {
        const fetchApi = (url: string, options: any) =>
            page.evaluate(
                async (args) => {
                    const res = await fetch(args.url, {
                        method: args.options.method || 'GET',
                        headers: args.options.headers,
                        body: args.options.body ? JSON.stringify(args.options.body) : undefined,
                    });
                    if (!res.ok) {
                        throw new Error(`HTTP error! status: ${res.status}`);
                    }
                    return res.json();
                },
                { url, options }
            );

        // login and get refresh token
        const refreshHeaders = await cache.tryGet(
            'iwara:token',
            async () => {
                const result = await fetchApi(`${apiqRootUrl}/user/login`, {
                    method: 'POST',
                    headers: apiHeaders,
                    body: { email: username, password },
                });
                return { authorization: 'Bearer ' + result.token };
            },
            30 * 24 * 60 * 60,

View on GitHub (pinned to bed535e087)

Solutions

  1. Inspect the interpolated status code in the message: 401/403 → recheck credentials; 429 → slow down / use a proxy; 5xx → wait and retry later.
  2. Clear the `iwara:token` cache entry so the route re-runs login with fresh credentials.
  3. Confirm `IWARA_USERNAME`/`IWARA_PASSWORD` are correct by logging in on iwara.tv in a browser.
  4. If IP-blocked, route RSSHub egress through a proxy.

Example fix

// before: stale cached token causes 401 on subsequent calls
// after: clear the cached token and let the route re-login
cache.del('iwara:token'); // then retry the route
Defensive patterns

Strategy: try-catch

Validate before calling

// pre-flight: confirm creds before launching the browser
if (!config.iwara?.username || !config.iwara?.password) throw new ConfigNotFoundError('Iwara creds missing');

Type guard

const isOkStatus = (s: number) => s >= 200 && s < 300;

Try / catch

try {
  const data = await fetchApi(url, options);
} catch (e) {
  const status = (e as Error).message.match(/status: (\d+)/)?.[1];
  if (status === '401' || status === '403') { await cache.del('iwara:token'); /* force re-login */ }
  throw e;
}

Prevention

When it happens

Trigger: Any Iwara API call made via the page-context fetch returns a non-2xx status: `${apiqRootUrl}/user/login` fails (401/403 on bad credentials), subsequent endpoints fail due to expired/invalid refresh token (cached under `iwara:token`), or Iwara rate-limits/blocks the server IP.

Common situations: Wrong username/password (401); Iwara changed its API auth flow so the token exchange returns an error; cached `iwara:token` is stale but the route does not refresh it; datacenter IP rate-limited by Iwara (429); Iwara temporarily down (5xx).

Related errors


AI-assisted analysis of DIYgod/RSSHub@bed535e087 (2026-08-12). Data as JSON: /api/errors/f718a94f813f984b. Report an issue: GitHub.