-
Notifications
You must be signed in to change notification settings - Fork 73
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
socket hang up #228
Comments
do you have any other server or may be Office 365 mailbox to test against? may be specific issue with exchange. |
Unfortunately no. May be you can take a look at these issues Error: socket hang up #2047 and http.Agent: idle sockets throw unhandled ECONNRESET. |
My customer is investigating a potential firewall issue. |
I am using different library. for investigation and testing you can modify ews-javascript-api/src/js/XHRDefaults.ts Line 17 in 6fa7050
ews-javascript-api/src/js/XHRDefaults.ts Line 64 in 6fa7050
|
Adding This is probably a backend firewall issue. |
xhroptions has no agentHttps property. in js file you want to do like this. const https = require('https');
const keepAliveAgent = new https.Agent({ keepAlive: true });
// .... other lines
agentHttps: keepAliveAgent, |
I've used an alternate method to set the header, still the same problem. I'll wait for an answer from my customer regarding their firewall. |
FYI, the equivalent .NET Code run on Windows does not suffer this problem. This is defintely tied to the context of my Customer because I'm running it without error against an Office 365 system. |
I've used fiddler to see what's going on underneath.
The .NET client tries again with another request that include the cookie header received from the first call:
This time it works. I have a response back.
Second one:
I'll try with Fiddler Mac to see what's going on exactly with the Javascript API. |
what is the authentication mode set on EWS Virtual Directory? |
I'll have to ask. |
you can test add cookie jar support used in fetch if cookies is a problem. this may have changed in latest Exchange Patch or so, had not seen this as issue unless you are running behind reverse proxy of some kind. |
Your right. My Customer tells me that there is an ISA server (reverse proxy) between us and the IIS Server. They'll try to let us through by modifying the configuration. |
what authentication is being used for ISA? if it is allowed to bypass login by ISA (usual case with latest exchange) you should use basic authentication (included in ews-javascript-api). if they have published EWS over Form based Authentication, You have to use cookieAuthXhrApi in ews-javascript-api-auth |
EWS seems to be published over Form based Authentication because we are indeed redirected to a login form when testing the EWS url in a browser. |
must use cookieAuthXhrApi |
I'll try that tonight, thanks. |
Unfortunately it does not work. I have the same error message. |
ping me on gitter |
issue is with cipher used in https/tls, could be specific to site you are using. |
I have to update cookie auth api with additional option, like for HttpAgent pass through to underlying api |
great news ! |
there is no need to update anything here, this is how it should be used import { XhrApi } from "@ewsjs/xhr"
const xhrApi = new XhrApi({ agentOptions: { ciphers: "DES-CBC3-SHA" } })
ewsService.xhrApi = xhrApi; // or ews.ConfigurationApi.ConfigureXHR(xhrApi)
|
Environment: EWS Exchange 2010
The following typescript code fails with "socket hang up" error:
Not sure which side is the problem located...
EWS logging:
Any help appreciated.
The text was updated successfully, but these errors were encountered: