HTTP request within OnSend function in Classic Outlook Desktop got a extremely large header that likely fail to pass firewall, different with web Outlook and New Outlook Desktop

[DanielHo4]

I am new to OfficeJS, and I just developed an Outlook plugin with an OnSend feature.

I found that the header of the HTTP request in the OnSend function in the classic desktop Outlook seems different from the web version of Outlook. The header sent by classic desktop Outlook is much larger than the web version causing the request to fail. Is there any explanation and fix for the API call from Outlook Desktop Classic?

Your Environment

• Platform [PC desktop, Mac, iOS, Office on the web]: PC desktop Classic, Web
• Host [Excel, Word, PowerPoint, etc.]: Outlook
• Office version number: [17425.20176], [17328.20184], [17231.20236], [17126.20132]
• Operating System: Win 10
• Browser (if using Office on the web): Chrome (version around 124)

Expected behavior

All HTTP requests from Outlook desktop and web is similar

Current behavior

HTTP requests for the OnSend feature in Outlook Classic seem to have a different HTTP request header when compared with the OnSend feature in the new Outlook desktop and web. It is also different from the HTTP request not inside the OnSend function in Classic Outlook Desktop.

Steps to reproduce

1. Create a OnSend function in the plugin
2. Add a fetch() function inside the Onsend function
3. Add event.completed after the fetch response is received
4. Trigger the OnSend feature
5. The event.completed is never reach in Classic Outlook Desktop, but can reach normally in web Outlook

Context

The OnSend function is never complete in Classic Outlook and stops every email sent from the user. The Outlook never received the response due to the packet was likely dropped due the strange request header sent from Classic Outlook Desktop.

Useful logs

It is a header I received after disable the firewall (but it is not feasible to request other API server to disable it) { "x-forwarded-for": "[IP A]", "x-forwarded-proto": "http", "x-forwarded-port": "80", "host": "[My host website]", "x-amzn-trace-id": "Self=1-663c9542-5b608675082d73b812bad87a;Root=1-663c9542-4292a6b252a3371b07001ce0", "content-length": "46665", "user-agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36 Edg/124.0.0.0", "content-type": "application/json", "x-amz-cf-id": "NFLaYOKCe2OagTPEJSZHgd11CG9wpcP9hyBVP43TKjIXjZfgV1RMWQ==", "via": "HTTP/1.1 AmazonAPIGateway", "accept-language": "en-US,en;q=0.9", "accept": "application/json", "referer": "https://localhost:3000/", "accept-encoding": "gzip, deflate, br, zstd", "sec-ch-ua": "\"Chromium\";v=\"124\", \"Microsoft Edge\";v=\"124\", \"Not-A.Brand\";v=\"99\", \"Microsoft Edge WebView2\";v=\"124\"", "sec-ch-ua-mobile": "?0", "sec-ch-ua-platform": "\"Windows\"", "origin": "https://localhost:3000", "sec-fetch-site": "cross-site", "sec-fetch-mode": "cors", "sec-fetch-dest": "empty", "priority": "u=1, i", "forwarded": "for=[IP B],for=[IP C];host=[My host website];proto=https" }

[Oleg-O]

@DanielHo4 apologies for delay in responding. Are you still able to reproduce this issue?

[DanielHo4]

@Oleg-O sorry, I am unable to test the plugin.