I'm using Fiddler2 to trace the https sharepoint calls. After starting the fiddler and browisng the https site it throws the error:
Access Denied (connect_method_denied):
....
This is typically caused by an HTTPS URL that uses a port other then the default of 443.
Any suggestion to resolve the issue will be very helpful.
Thanks,
Mac
That message is coming from your upstream proxy server. The question is why you're not seeing it in IE itself. Try disabling proxy chaining inside Tools > Fiddler Options > Connections and see if that helps.
Related
I'm setting up a WebSocket between a standard web page and a Tomcat v7.0.62 server. The connection works fine with Tomcat SSL turned on/off on Firefox, Edge and IE11. However, in Chrome (v66.03), the websocket only connects when I've turned on SSL on the server and connect via https. In Chrome, when I turn SSL off on the server and try to connect via http, it throws an error.
Here's the error Chrome throws when trying to connect via http with SSL turned off on Tomcat...
Error in connection establishment: net::ERR_PROXY_AUTH_REQUESTED_WITH_NO_CONNECTION
Here's my WebSocket connection code on the client...
var wss = "wss://";
if (document.location.protocol === "http:") {
wss = "ws://";
}
var wsURL = wss + document.location.host + "/status?sessionId=<%=session.getId()%>";
Is this something Chrome specific that needs special code on non-https websocket connections?
This is a Chrome specific behavior. Chrome doesn't allow unsecure websocket (ws) connections to localhost (only wss, so you should setup a TLS certificate for your local web/websocket server). But the same should work without any issues in Firefox and other browsers.
Please refer the Chrome bug report on Chromium regarding this issue. This particular problem is intentional, and they have made this change to make
Chrome more secure by preventing attacks against internal network devices and processes listening on localhost.
https://bugs.chromium.org/p/chromium/issues/detail?id=378566
Error in connection establishment: net::ERR_PROXY_AUTH_REQUESTED_WITH_NO_CONNECTION
It seems you might have a proxy with authentication in the middle, between the clients and the service. Depending on the proxy and clients configuration, it might let through SSL connections, but plain http will get filtered.
I can not confirm your issue. You can try the Echo Test here: http://www.websocket.org/echo.html
The website supports http and https, you can specify ws://echo.websocket.org and wss://echo.websocket.org. I have tried all combinations and they all worked for me.
My guess is that it is a configuration issue with your server or a problem with your browser extensions.
We have an application that posts some xml data to another application and traffic flows through apache web server (version 2.2.26) reverse proxy. we are observing some sporadic Proxy Error (http response code 500) - SSL handshake error with the remove server. The error message is shown in apache web server error logs.
Earlier we were using sunOne web server and we didn't notice this error.
i am suspecting that may be some missing configuration on apache web server that is causing this issue. this is just my guess.
Please advise if anyone has any experience around this issue.
I had a similar issue with Microsofts IIS, maybe it helps you.
There was a problem with the compression, the proxy did not support gzip so I forced the proxy to set the compression to none.
Afterwards (outboundrule), I changed the compression back to the original header sended from client.
This was very strange issue where Apache complained about SSL Handshaking but it turned out to be something else, finally the issue got resolved by placing the SetEnv proxy-sendchunked in rproxy.conf file.
I am consuming a web service in .NET application with WCF client.
The Endpoint's address of the service is over port 4338, and it is over HTTPS, secured with WS-Security standard.
So the address is something like :
https://[servername]:4338/[servicename]/
I was not able to communicate to the service with just running the application.
it gave me the following error :
Could not connect to [servername]:4338
TCP error code 10060: A connection
attempt failed because the connected
party did not properly respond after a
period of time, or established
connection failed because connected
host has failed to respond
[servername]:4338
But when I run Fiddler to investigate the http communication, the application start to work, and I will be able to communicate to the service.
As well, I want to add that I have a different service on the same web server that hosts the first service, and that second service's address is hosted on port 8080, and I am able to communicate with it with WCF client (without running Fiddler).
So, I googled and I found that it might be related to the proxy settings. Do you know what the problem is, and how can I solve it?
Thanks
Fiddler acts as an Internet proxy server. In general, any symptom of the form: "it works when I use Fiddler" means "it works when there's a (different) proxy server".
Check your proxy server settings. In particular, as empi suggested, try it in a browser. If it works there, it could be due to the fact that the browser has the proxy settings configured, and that you do not have them configured for WCF.
If you have proxy set in Internet Explorer, it may cause the problem. What happens when you open https://[servername]:4338/[servicename]/ in Internet Explorer?
Thanks empi for the reply.
I found the answer.
Actually in our company we have a proxy settings through "Automatic configuration script"
and depends on the web sites we are targeting internally, the script will point us to the proper proxy.
So, from the script I got the proper proxy address.
and in my .NET application I added this code
WebRequest.DefaultWebProxy = new WebProxy("http://xx.xx.xx.xx:8080");
and that fixed the problem
So WCF client was not detecting the setting of the automatic script.
and this is the reason it worked when I run Fiddler, because Fiddler listen to the http communication, and send it again through the settings.
I need to monitor HTTP traffic in my dev env which is PHP/Apache/Windows. But Apache seems to refuse the HTTP requests coming from fiddler which sits between the browser and Apache.
Error is No connection could be made because the target machine actively refused it
I suppose there should be some configuration on Apache which allows traffic via Fiddler. Can any one help me with it?
What windows version are you using?
What browser are you using?
Does the Apache reside on localhost?
Try disabling IP6 support (in the Fiddler options -> General -> uncheck "Enable IPv6 if available")
If apache is on localhost try http://machinename:port instead of http://127.0.0.1:port or http://localhost:port
Also check Fiddler know issues
I'm going to assume that your browser and Fiddler are installed on the same machine and the deve enviroment is remote. I would install Wireshark and capture the native browser requests, and the ones proxied through Fiddler. See what is different between them. I would seem they would be comming form the same src IP, so I would look at the various HTTP request headers, and see what is different.
I am working on Windows Server 2003 (IIS6), which has two asp.net sites running in seperate app pools. One of the sites has an ssl certificate installed and was running fine on https. The other site has no certificate and does not require https
The problem I have is that when I publish my app from vs2005 to the site with ssl the https urls stop working and I can only use http. The error I get is as follows
From Google Chrome: Error 104 (net::ERR_CONNECTION_FAILED): The attempt to connect to the server failed.
From IE7: Internet explorer cannot display the web page, could be unavailable, dns is not reachable etc
The strange thing is the first time this happened, https eventually became available but I don't know what triggered the availability but when I published an updated assembly to the bin folder of the site which does not require https, the OTHER site became unavailable on https again
Help much appreciated!
UPDATED: Thanks for the suggestions but it turns out that the firewall was not open on the ssl port
Check if the firewall port for SSL (443) wasn't accidentally closed 443. ;-)
If both webs use the same IP address, make sure, that only the web with the certificate uses the SSL port 443 (first property page). The input field should be empty for the insecure site.
If that is not the problem, you could try to debug stopping the web without certificate and restart the web server.