Script Returns 200 but Will Not Run? Diagnose MIME Types Through a Proxy

A regional page downloads its JavaScript URL with HTTP 200, yet the browser refuses to run the script because of its MIME type. A successful transfer and a valid script response are different acceptance conditions. Before rotating the residential exit, compare the final response headers, actual representation and browser request destination. The procedure below is a controlled test design for owned sites, not a report of measured 98IP browser compatibility.

1. Identify the exact script request and its destination

Open the failing page's network and console tools. Record the initiating document, requested asset path, final URL after redirects, status, response Content-Type and the browser's diagnostic. Distinguish an ordinary classic script from a JavaScript module. A document navigation, a command-line download or a generic fetch is not the same loading context as a script element.

With X-Content-Type-Options: nosniff, script-destination responses must have a JavaScript MIME type to pass that MIME check. Browser JavaScript modules also use strict MIME checking; an accepted JavaScript type is required even when nosniff is absent. Do not describe every MIME failure as being caused by that header, or infer that removing it makes a module valid.

Use text/javascript for the controlled JavaScript fixture. A .js or .mjs filename does not set the actual HTTP response header. Conversely, a correct type does not prove that the returned bytes are the intended build or that evaluation succeeded. This guide concentrates on JavaScript asset responses, rather than request-body type errors or API content negotiation.

2. Compare the body with the deployment's asset contract

Inspect a small, non-sensitive sample of the actual response through the authorized diagnostic tools. Is it the expected script artifact, an HTML application shell, a sign-in page, a regional interstitial or a generated error page? Keep the redirect chain: a script URL can end at an HTML login response while the final status remains 200.

For an owned build, define the expected asset path, build ID, media type and a harmless execution marker independently of the fetched response. An HTML body with text/html may be correctly labelled HTML but still be the wrong resource for a script request. Do not repair that mismatch by relabelling the HTML as JavaScript.

If the body is the intended JavaScript but its response header is text/plain or a generic binary type, inspect the static-file or object metadata configuration. If both body and header are wrong, inspect routing and deployment first. A common test hypothesis is that a missing versioned asset falls through to a single-page application's HTML route; establish that from evidence rather than assuming every regional failure has this cause.

3. Build a small positive and negative matrix

1. Prepare an owned HTTPS test page and a tiny harmless JavaScript asset. Keep the fixture self-contained with no imports, external requests, account data or write operations. Give it a visible test-only completion marker that appears only when its code executes.
2. Serve the intended JavaScript with text/javascript. For the classic-script comparison, keep nosniff enabled. Load the real script element and require both the expected response and the execution marker; record browser and build versions.
3. In an isolated variant, keep the same harmless JavaScript bytes but deliberately send text/plain. Under the classic-script nosniff case, expect refusal at the MIME boundary and no execution marker. Use the console evidence, not merely a missing visual feature.
4. Test a separate module variant using the same type-correct versus type-wrong response design. Keep its lack of imports and side effects explicit. Record module MIME refusal without treating removal of nosniff as the recovery.
5. Add a routing-negative variant whose asset path returns an HTML shell with text/html. Confirm the check rejects the wrong representation even if the server reports 200. Restore the actual asset route and metadata, then rerun the valid and deliberately invalid cases.
6. Repeat the corrected variants through the required residential region with equivalent account state, browser settings, storage and release. Keep the session policy stable, record actual egress and compare the first differing response or loading decision.

These are expected outcomes until observed. Keep existing site protections in place. If CSP, authentication or another control prevents the fixture from reaching the MIME check, record that earlier boundary and use an owner-approved fixture configuration; do not disable production controls to force the experiment.

4. Separate route, cache and script-validation failures

• Final response is an HTML login or challenge: inspect the authorized route and account requirements. Do not automate bypassing the challenge or assume the proxy corrupted JavaScript.
• Old HTML references a removed hashed asset: inspect release ordering, retained assets and stale document delivery. Correct the deployment relationship rather than adding an unlimited retry loop.
• Origin metadata is correct but a delivered cached response differs: compare build identifiers and relevant cache evidence; repair or invalidate only the owner's affected test objects.
• Network tools show service-worker or local-cache delivery: isolate that source in an approved fresh test profile and compare. A command-line origin fetch alone does not establish what the browser consumed.
• MIME is now accepted but execution still fails: inspect syntax, imports and the next console error. Passing one gate does not prove the whole application is healthy.

An ordinary non-intercepting HTTPS proxy cannot rewrite encrypted origin Content-Type headers or the script body inside the tunnel. If the returned representation differs by region, examine the actual final route, CDN delivery, authorized account state and application configuration before assigning blame. If an approved interception layer exists, document it separately rather than treating it as a normal residential tunnel.

5. Keep other browser checks and evidence distinct

Content Security Policy can stop a script for policy reasons; the CSP resource diagnosis guide covers that boundary. Cross-origin modules also need the applicable CORS permissions, and integrity metadata can reject changed content. MIME correctness cannot substitute for those checks, nor should an integrity value be regenerated from a suspicious HTML response.

Do not add a request Content-Type header as a supposed fix for the response's media type. Keep response Content-Type, Content-Encoding and any Content-Disposition conceptually separate. A JavaScript-looking extension or a successful direct browser-tab display is insufficient evidence of correct script loading.

Retain the fixture/build ID, browser version, requested and final asset paths, redirect status sequence, response type, nosniff presence, loading context and execution-marker result. Use a digest or approved artifact reference where needed instead of saving private response bodies. Remove tokens from URLs and exclude cookies, credentials, account contents and authorization headers from shared evidence.

6. Use 98IP to compare a controlled regional delivery path

If authorized website QA needs a residential network perspective, consult the 98IP residential proxy product page and API configuration documentation, then use the method supported by your account. Compare the same fixture and release through each required region with bounded test traffic and actual usage records. A route can expose a regional delivery difference; it cannot turn HTML into executable JavaScript or guarantee browser behavior.

• The actual script request, redirect chain and loading context are identified.
• Returned bytes and response media type both match the intended build.
• Classic nosniff and module strict-MIME cases are not confused.
• Wrong-header and HTML-fallback negative cases remain detectable.
• Correct recovery changes asset delivery or metadata while retaining protections.
• Execution evidence, other browser gates and regional conditions are reported separately.

Does HTTP 200 prove the script loaded? No. Verify the representation, relevant browser checks and harmless execution marker.

Can we fix it by deleting nosniff? Keep the protection and correct delivery. Modules require an accepted JavaScript media type independently.

Should HTML returned for a script path be marked text/javascript? No. Restore the intended asset or route; changing a label does not change HTML into the correct program.