I have a VB6 application that only runs under certain conditions. When it fails (on the send statement below), it generates a
Run-time error '-2147012867 (80072efd)': A connection with the server could not be established
The funny thing is that it always runs when Fiddler is running. On some machines it runs whether or not Fiddler is running, but on other machines it will only run when Fiddler is running. Fiddler doesn't even have to be capturing traffic for it to run.
The request is to an https site.
The code looks like this:
Set xhr = CreateObject("WinHttp.WinHttpRequest.5.1")
xhr.open "POST", sUrl, bAsync
xhr.setRequestHeader "Content-Type", "application/x-www-form-urlencoded"
xhr.setRequestHeader "Content-Length", Len(sBody)
xhr.send sBody
I've read the Telerik article, Help! Running Fiddler Fixes My App???, but none of the suggested solutions seems to work.
Can anyone provide me with any insight on what might be wrong or how I can solve this?
Could you check your WinHttpSettings registry key settings?
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet
Settings\Connections\WinHttpSettings
Default value (no proxy) is
I suppose that Fiddler modified this configuration in order to act as proxy.
If Fiddler is not running => no proxy => connection error.
In WinHttpRequest, if setProxy is not explicitly called => HTTPREQUEST_PROXYSETTING_DEFAULT => HTTPREQUEST_PROXYSETTING_PRECONFIG
HTTPREQUEST_PROXYSETTING_PRECONFIG
Indicates that the proxy settings should be obtained from the
registry.
Setting the Proxy to HTTPREQUEST_PROXYSETTING_DIRECT solved the problem.
' Important Note: The setProxy setting of 1 corresponds to HTTPREQUEST_PROXYSETTING_DIRECT
' (see https://msdn.microsoft.com/en-us/library/windows/desktop/aa384059(v=vs.85).aspx)
' Without this, the app would only work on the dev machine when Telerik Fiddler was also
' running. Oddly, the app would run correctly on all other machines.
Set xhr = getRequestObject()
xhr.setProxy 1
xhr.open "POST", sUrl, bAsync
xhr.setRequestHeader "Content-Type", "application/x-www-form-urlencoded"
xhr.setRequestHeader "Content-Length", Len(sBody)
The Microsoft article cited above gives three values for the constants that the Proxy can be set to. I don't understand why the "Direct" setting worked, but it did.
Thanks to Jeandey and anyone else that looked at this.
Related
I'm trying to get a Typo3 (6.2) instance running behind a (forwarding) proxy (squid). I have set
'HTTP' => array(
'adapter' => 'curl',
'proxy_host' => 'my.local.proxy.ip',
'proxy_port' => '8080',
)
as well as
'SYS' => array(
'curlProxyServer' => 'http://my.local.proxy.ip:8080',
'curlUse' => '1'
)
The proxy doesn't ask for credentials.
When I try to update the extension list, I get the error message
Update Extension List
Could not access remote resource http://repositories.typo3.org/mirrors.xml.gz.
If I try Get preconfigured distribution, it says
1342635425
Could not access remote resource http://repositories.typo3.org/mirrors.xml.gz.
According to the proxy log, the server doesn't even try to connect to the proxy.
I can easily download the file using wget on the command line.
Ok, I've investigated he issue a bit more and from what I can tell, the Typo3 doesn't even try to connect anywhere.
I used tcpdump and wireshark to analyze the network traffic. The site claims to have tried sending a http-Request to repositories.typo3.org so I'd expect to find either a proxy connection attempt or a DNS query followed by an attempt to connect to that IP. (Of course, the latter is known not to work.) However, none of this happens.
I've tried some slight changes in the variable curlProxyServer. The documentation clearly states
String: Proxyserver as http://proxy:port/. Deprecated since 4.6 - will be removed in TYPO3 CMS 7. See below for http options.
So I tried adding the trailing "/" and removing the "http://" - no change. I'm confident there's no problem whatsoever regarding the proxy as the proxy isn't even contacted and has been working perfectly fine for everything else for years.
The error message comes from \TYPO3\CMS\Extensionmanager\Utility\Repository\Helper::fetchFile(). This one uses \TYPO3\CMS\Core\Utility\GeneralUtility::getUrl() to get the actual file content.
According to your setting, it should use the first part of the function, because curlUse is set and the URL starts with http or https.
So what you would need to do now is to throw some debug lines in the code and check at what point the request goes wrong.
Look at the source code, three possibilities come to mind:
The curl proxy parameters does not support a scheme, thus it should be 'curlProxyServer' => 'my.local.proxy.ip:8080',.
Some redirect does not work.
Your proxy has problems with https, because the TYPO3 TER should be queried over https.
Got this error message:
Refused to set unsafe header "Origin"
Using this code:
function getResponse() {
document.getElementById("_receivedMsgLabel").innerHTML += "getResponse() called.<br/>";
if (receiveReq.readyState == 4 || receiveReq.readyState == 0) {
receiveReq.open("GET", "http://L45723:1802", true, "server", "server123"); //must use L45723:1802 at work.
receiveReq.onreadystatechange = handleReceiveMessage;
receiveReq.setRequestHeader("Origin", "http://localhost/");
receiveReq.setRequestHeader("Access-Control-Request-Origin", "http://localhost");
receiveReq.timeout = 0;
var currentDate = new Date();
var sendMessage = JSON.stringify({
SendTimestamp: currentDate,
Message: "Message 1",
Browser: navigator.appName
});
receiveReq.send(sendMessage);
}
}
What am I doing wrong? What am I missing in the header to make this CORS request work?
I tried removing the receiveReq.setRequestHeader("Origin", ...) call but then Google Chrome throws an access error on my receiveReq.open() call...
Why?
This is just a guess, as I use jquery for ajax requests, including CORS.
I think the browser is supposed to set the header, not you. If you were able to set the header, that would defeat the purpose of the security feature.
Try the request without setting those headers and see if the browser sets them for you.
In CORS the calling code doesn't have to do any special configuration. Everything should be handled by the browser. It's the server's job to decide if request should be allowed or not. So any time you are making a request which breaks SOP policy, the browser will try to make a CORS request for you (it will add Origin header automatically, and possibly make a preflight request if you are using some unsafe headers/methods/content types). If the server supports CORS it will respond properly and allow/disallow the request by providing CORS specific response headers like
Access-Control-Allow-Origin: *
Keep in mind that Chrome is very restrictive about 'localhost' host name. (At least it was when I was working with it). Instead use your computer name or assign it another alias in 'hosts' file. So for example don't access your site like:
http://localhost:port/myappname
Instead use:
http://mymachinename:port/myappname
or
http://mymachinealias:port/myappname
For more details please check specification.
Are you working cross-domain?
Try Brian S solution or try this:
instead of setting to localhost just pass anything... and see what happens.
receiveReq.setRequestHeader("Origin", "*");
I'm using jQuery (1.7.0) to make a json/ajax call to Spotify. The following code works fine in Chrome and Firefox, but causes an error (Error: Access is denied.) in IE.
$.ajax({
url: 'http://ws.spotify.com/lookup/1/.json',
type: 'GET',
dataType: 'json',
cache: true,
data: {
uri: "someartist",
extras: "album"
},
success: successfn,
error:function(xhr, status, errorThrown) {
alert("networking error: "+errorThrown+'\n'+status+'\n'+xhr.statusText);
}
});
The success function is called in Chrome and FF, but the error function is called in IE with the above message. I have set cors to true: jQuery.support.cors = true;.
It works on Chrome and FF both locally and on my server, it works in IE locally but not on the server. Changing cache: false causes problems at the spotify end - doesn't line additional parameters, so I get a "bad request" error.
Grateful for any pointers.
Thanks
Abo
You are relying on the spotify url to give a Access-Control-Allow-Origin:* in their header to allow cross domain requests from all domains. Internet explorer however doesn't support this, so it gives access denied.
access-control-allow-origin explained. (TLDR: Servers may allow cross domain ajax in their headers)
If you need this to work in IE, you could use spotify's JSONP API if they have one or make the AJAX request in flash, which works in all browsers and passes the requests response data to your javascript.
The above answer about using jsonp is correct; I want to add:
Don't set
jquery.support.cors = true;
I'm not sure why so many questions begin by stating they took that step. This property is meant to be read to find out if the browser supports CORS. You should only override it if you know differently, and in my experience it's accurate for all major browsers. Setting it to true doesn't enable the browser to use CORS, it just denies you the info that CORS is going to fail.
http://api.jquery.com/jQuery.support/
can you give an example of returned data?
at a /guess/, it either has something to do with the filename ".json", or the JSON returned has something weird about it.
I'm surprised this works on Chrome or Firefox. You shouldn't be able to run cross-domain JSON requests.
If Spotify API supports it, you should use JSONP in order to access resources from other domains.
Also see: No response from jQuery ajax call
I don't see this working in FF. You can't make cross-domain Ajax calls. So I'm not sure what's going on when you say that it works in FF. But I just tried the following in FF and I got the error. So all you can do is make the call on the server side and then include the results in your page.
http://jsfiddle.net/2XWGn/
I am using the Prototype JS framework to do Ajax calls. Here is my code:
new Ajax.Request( '/myurl.php', {method: 'post', postBody: 'id='+id+'&v='+foo, onSuccess: success, onFailure: failed} );
function success(ret) {
console.log("success",ret.readyState, ret.status);
}
function failed(ret) {
console.log("failed",ret.readyState, ret.status);
}
Most of the time, this works fine and the success function is called with a status code of 200. About 5% of the time on Safari the success function is called with a status code of 0. In this case, when I look in the Network tab of the web inspector, the ajax call is listed with a status of "canceled". I can confirm with server logs, that the request never hit the server. It's as if the ajax request was immediately canceled without even trying to connect to the server. I have not found any reliable way to reproduce this, it seems to be random. I do it 20 times and it happens once.
Does anyone know what would cause the ajax call to get canceled or return a status code of 0?
The cause may be the combination of http server and browser you are using. It doesn't seems like an error of the PrototypeJS library.
Multiple sources states that keep-alive parameter of the HTTP connection seems to be broken in Safari (see here, here or here). On Apache, they recommend adding this to the configuration:
BrowserMatch "Safari" nokeepalive
(Please check the appropriate syntax in your server documentation).
If Safari handles badly HTTP persistent connections with your server, it may explain what you experiences.
If it's not too complex for you, I would try another HTTP server, there are plenty available on every OS.
We lack a bit of information to answer fully your answer, though. The server issue is a lead but there may be others. It would be nice to know if it does the same thing in other browsers (Firefox with Firebug will display this kind of information, Chrome, Opera and IE have development builtin toolboxes). Another valid question would be how often you execute this AJAX request per second (if relevant).
I know this is an old topic, but I wanted to share a solution for Safari that might save others some time. The following line really solved all problems:
BrowserMatch "^(?=.*Safari)(?=.*Macintosh)(?!.*Chrom).*" nokeepalive gzip-only-text/html
The regex makes sure only Safari on Mac is detected, and not Mobile Safari and Chrome(ium) and such. Safari for Windows is also not matched, but the keepalive problem seems to be a Mac-Safari combination only. In addition, some Safari versions do not handle gzipped css/js well.
All our symptoms of our site crashing or CSS not completley loading in different versions of Safari which caused me to nearly pull my hair out (Safari really is the new IE) have been solved for us with this Apache 'configuration hack'.
I am making an ajax request using JQuery that looks like this:
var data = createXMLdata();
$.ajax({
url: 'http://localhost:8080/foo/bar',
type: "PUT",
data: data,
processData: false,
contentType: "application/text",
error: function(xhr, status, error) {
alert("Error: " + status);
},
success: function() {
alert("Success!");
}
});
When the code executes, I get the success alert, but the service is never executed on the server!
Here's some more data:
If I make the same request using a separate REST client, the service is executed correctly
If I shut down the server (nothing is running) so that hitting that URL gives me a 404, I still get a success message.
I have tried replacing the data with "foo". This works from the REST client, but gives the same result from the code.
Any ideas are greatly appreciated!
The documentation about .ajax()'s type attribute says:
The type of request to make ("POST" or "GET"), default is "GET". Note: Other HTTP request methods, such as PUT and DELETE, can also be used here, but they are not supported by all browsers.
So probably your browser does not support PUT and the data is sent via POST instead (and therefore not recognized by your service).
Use Firebug or similar to find out which method is used.
One idea to make it working:
Send the data using POST but add an additional field e.g. __http_method=PUT. On the server side, your service has to recognize this and perform the PUT functionality.
This might be not the nicest solution but it is also used by other frameworks I have encountered (e.g. symfony for PHP).
PUT isn't supported by all browsers
Nick Craver made a comment on my question:
Is the page you're running this in served from port 8080?
It turns out this led to me solving the problem. When both the app and the service were hosted on the same server (and port), the problem went away.
This post suggests that if I comment answers the question, and the commenter does not re-post as an answer, I am to post my own answer and accept it. Nick, if you return to post this as an answer, I will accept it over my own.