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
- Inspect the interpolated status code in the message: 401/403 → recheck credentials; 429 → slow down / use a proxy; 5xx → wait and retry later.
- Clear the `iwara:token` cache entry so the route re-runs login with fresh credentials.
- Confirm `IWARA_USERNAME`/`IWARA_PASSWORD` are correct by logging in on iwara.tv in a browser.
- 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
- Clear the cached 'iwara:token' on 401/403 so the route re-runs login.
- Back off on 429 (rate limit). Log the status code for diagnosis.
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
- Iwara subscription RSS is disabled due to the lack of <a hre
- Bilibili browser mode returned unexpected video list API sta
- Bilibili browser mode returned non-JSON response with status
- Got error code ${data.code} while fetching in browser mode:
- Fortnite API responded with ${statusMessage} for ${apiUrl}
AI-assisted analysis of DIYgod/RSSHub@bed535e087 (2026-08-12).
Data as JSON: /api/errors/f718a94f813f984b.
Report an issue: GitHub.