tor-browser

commit 5f344ba28907a8387bf92aecddcd83bff5c582d6
parent e89393120292fce5fac53ad918229f3a178e1e7c
Author: Valentin Gosu <valentin.gosu@gmail.com>
Date:   Wed, 17 Dec 2025 10:01:35 +0000

Bug 2004689 - Fix wasm loader to use the content-type header r=smaug

Since D275443 changed FetchBody<Derived>::GetMimeType to parse the mime type
according to the fetch standard, the check for application/wasm would
unexpectedly pass. /wasm/webapi/contenttype.any.js expects the load to fail
for `application/wasm;`. We avoid this issue by using the raw content-type
header from the response.

Differential Revision: https://phabricator.services.mozilla.com/D276706

Diffstat:
M
dom/fetch/FetchUtil.cpp
 | 
8
++++++--

1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/dom/fetch/FetchUtil.cpp b/dom/fetch/FetchUtil.cpp
@@ -700,9 +700,13 @@ bool FetchUtil::StreamResponseToJS(JSContext* aCx, JS::Handle<JSObject*> aObj,
       break;
   }
 
+  // For WASM, the Content-Type must be exactly "application/wasm" with no
+  // parameters. Check the raw header value before parsing normalizes it.
+  ErrorResult result;
   nsAutoCString mimeType;
-  nsAutoCString mixedCaseMimeType;  // unused
-  response->GetMimeType(mimeType, mixedCaseMimeType);
+  response->GetInternalHeaders()->Get("Content-Type"_ns, mimeType, result);
+  MOZ_ALWAYS_TRUE(!result.Failed());
+  ToLowerCase(mimeType);
 
   if (!mimeType.EqualsASCII(requiredMimeType)) {
     JS_ReportErrorNumberASCII(aCx, js::GetErrorMessage, nullptr,