Hi @ekaansh.zoom,
Thanks for checking and for your prompt reply.
I’d like to share more details about our implementation and how to reproduce the issue, as we are still encountering the file upload failure only on Safari (macOS and iOS). The same code works fine in other browsers such as Chrome (Windows/Android) and Edge (Windows).
Setup Details
Although our app does not use a Node.js environment or a package manager like npm at runtime, we did extract the following files from the npm package @zoom/videosdk-ui-toolkit:
videosdk-ui-toolkit.cssvideosdk-ui-toolkit.min.esm.js
These files are copied into our static asset directory and served as part of a traditional HTML+JS app (no frameworks).
Code Overview
HTML
<link rel="stylesheet" href="/css/zoom/videosdk-ui-toolkit.css" />
<script type="module">
import { startZoomSession } from '/js/zoom/zoom-session.js';
const zoomConfig = {
language: "ja",
videoSDKJWT: "[REDACTED]",
sessionName: "test session",
userName: "demo user",
featuresOptions:{
audio:{
enable:true
},
caption:{
enable:false
},
feedback:{
enable:false
},
header:{
enable:true
},
footer:{
enable:true
},
preview:{
enable:true,
isAllowModifyName:false
},
recording:{
enable:false
},
settings:{
enable:true
},
share:{
enable:true
},
subsession:{
enable:false
},
users:{
enable:true
},
video:{
enable:true
}
}
};
startZoomSession(zoomConfig);
</script>
JavaScript
export function startZoomSession(config) {
import("/js/zoom/videosdk-ui-toolkit.min.esm.js").then((uitoolkit) => {
const container = document.getElementById("sessionContainer");
uitoolkit.default.joinSession(container, config);
window.addEventListener("beforeunload", () => {
uitoolkit.default.leaveSession(container);
});
});
}
Issue (Safari only)
Steps to reproduce:
- Load the app in Safari on macOS or iOS
- Join the session
- Open the chat panel
- Attempt to upload a file (e.g. PNG)
Result:
- File upload fails
- Developer console shows:
WebKitBlobResource error 1- HTTP 400 Bad Request from
zoomfile/upload
- Origin header is set to
null in redirected request
Sample log:
Summary
URL: https://zoomap134224161250rwg.cloud.zoom.us/wc/fileupload?filename=sample.png&filesize=59686&rwg=[zoom-upload-host]&cid=[REDACTED]
URL: https://jp01file.zoom.us/zoomfile/upload?channel=4
Status: 400 Bad Request
Source: Network
Address: [Redacted IPv6 Address]:443
Initiator: videosdk-ui-toolkit.min.esm.js:37457
Request
POST /wc/fileupload
Accept: */*
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryXXXXXX
Origin: https://[client-app-domain]
Referer: https://[client-app-domain]/
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: cross-site
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/18.5 Safari/605.1.15
zmk: [REDACTED JWT TOKEN]
zoom-file-origin: redirect=support_auth
Redirected Response
307 Temporary Redirect
Location: https://jp01file.zoom.us/zoomfile/upload?channel=4
Access-Control-Allow-Origin: https://[client-app-domain]
Access-Control-Allow-Credentials: true
[...Other CORS Headers...]
Request (After Redirect)
POST /zoomfile/upload HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryXXXXXX
Origin: null
Referer: https://[client-app-domain]/
Transfer-Encoding: chunked
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/18.5 Safari/605.1.15
zmk: [REDACTED JWT TOKEN]
zoom-file-origin: redirect=support_auth
Response
HTTP/1.1 400 Bad Request
Access-Control-Allow-Origin: null
Access-Control-Allow-Credentials: true
Content-Type: application/json
x-unified-error: 2201
x-unified-error-id: FormReader_ReadBodyException
Zoom-File-DOMAIN: jp01file.zoom.us
[...Other Headers...]
Query String Parameters
channel: 4
Request Data
MIME Type: multipart/form-data
It seems that Safari (due to redirect behavior) strips the Origin header or sets it to null, which might be causing CORS validation to fail on Zoom’s upload endpoint.
If you have any suggestions on how to work around this behavior or if any update is planned to handle Safari’s redirect logic more gracefully, we’d greatly appreciate it.
Let me know if you’d like access to our test environment as well.
Thanks again for your help!
