Odd cURL timeout behaviour - php

I have a cURL functionality that has started to timeout suddenly when it tries to connect a third party service.
I am a bit lost what could be the issue as nothing has changed (what I know of). Here are what I have tried:
Run cURL on other two servers to rule out blacklisting. Those servers
have same settings, different IP and they have not done cURL calls to
the service before. Still timing out.
Check our other cURL functionalities to make sure it is not the cURL library. Those work ok so happy days.
Ran same code on local machine to make sure if the settings is the issue. That worked ok.
So from above I have concluded it is something in those three servers' settings that are not working correctly. However, my knowledge on cURL server settings stuff is a bit lacking which is why I am here.
BTW, the third party service does not require whitelisting so that cannot be that either.
I have also tried putting the cURL timeout to minutes and that did not work either.
The third party service provides SSL and non-SSL connection and I have tried connecting to both without success.
Any help is appreciated.

Related

PHP sockets - connection refused (unusual cause?)

I have a problem with a PHP script triggering a "connection refused" message. Im trying to execute file_get_contents('http://some_domain'). I have also tried fsockopen(), socket_create() and curl_exec() but they all result in "connection refused" on some specific sites that I want to reach. (i.e. its not a general problem).
The resources do exist and I can contact them via my browser.
If I run the PHP on my localhost server, it connects OK
The problem is only apparent if I run the code on either of my remote servers
The problem only occurs with some sites, not all sites
The code worked OK until a few weeks ago
A common factor is that the three sites Im trying to reach are all running web servers behind domestic broadband routers that I installed (but with different broadband providers). But - as I said above - I can access them all from my browser, and the code worked until a few weeks ago. As far as I can see its not a firewall issue in the routers.
Im not sure what all that means - could there be some firewall issue on some intervening machine? How could I tell?
The answer to this turned out to be nothing but a server firewall problem. A new rule set had been loaded into iptables. Hopefully this will be useful to future enquirers - check iptables and your server log and save yourself a lot of time!

Symfony2 long polling on SSL server

I have an Symfony2 application that has a long pooling mechanism implemented. The user logs in the application, and at a certain time a long pooling request is started to notify the user about some changes while he still works inside the application.
The php session is saved in the database so no session locking problems occur while opening other ajax requests during the long pooling duration.
After installing a SSL certificate the problems appeared and the long pooling seems to lock other requests while he is running, behaving like the normal php session. Although the php session is still saved/read from the database the application behaves like a locking mechanism is present and doesn't allow two request at the same time.
Is this a problem with configuring the SSL module or am I missing something about Symfony's behavior? If I disable the SSL everything works great and multiple requests at the same time are not a problem.
Late edit:
Apparently the problem was with the HTTP2 headers. If I use HTTP2 headers concurrent requests are queued and executed one after the other. Using HTTP1.1 everything is ok. This is really strange, because I checked the server config according to apache documentation and this should work with my SSL module. Anyone has experienced something like this?
Are doing it with jQuery or Angular, from the client ? If so, check JS console and debug network. Also, can you get an hand on the SSL apache conf of your server ? Some parameters may overload the default config of your server, and makes conflict with the working non-ssl config.

The weirdest issue with lamp+mediawiki ever experienced

Ok, so I have set up a installation of lamp and mediawiki on my machine with the path http://localhost/mw/. I then proceeded to install windows on a virtual machine so i could test mediawiki installation with Internet Explorer. So i set the appropriate $wgServer setting to my host IP addr which was reachable from the virtualbox client.
First i accessed http://x.x.x.x/ and got a directory listing, yay it works. right?.... NO..
I then proceeded to access http://x.x.x.x/mw/ (mediawiki path), and to my suprise, IE was just loading on recieve. Several hours went by, and still IE was loading the page... No connection timeout, no recieve timeout. just loading.. forever and ever...
When trying to investigate what was really going on here, i downloaded the cli utility cURL. and proceeded with the command: curl -v http://x.x.x.x/mw/index.php/Main_Page. I was able to retrieve the page, however the result was mind blowing!
First off, mediawiki reports that the page was rendered quite fast (as read from the recieved html source)
Served in 0.356 secs.
Curl on the other hand;
* 14542 bytes transfered in 764.580 seconds (19 bytes/sec).
This suggests to me that for some reason the path /mw/... has a very slow transfer rate. All the other sites works just fine, but not /mw/
And since i never got a connection timeout or receive timeout in IE im guessing that i'm recieving byte for byte at a very slow rate, and it does this for all the resources on the page im trying to get.
And to make things even more interesting, the host machine can access /mw/ without any problems at all. I also tried connecting with another computer on the network (not a virtual machine), and it also suffered the same issue with endless loading.
Any ideas on what is going on here?
The issue seems to be traced back to xdebug module when configured with auto connect back.
Removing xdebug.xdebug.remote_connect_back in xdebug config solved the issue.

PHP cURL error: Could not resolve proxy

I'm trying to send a cURL request from a Windows Server 2008 machine using PHP (version 5.3.12) and keep receiving the error Could not resolve proxy: http=127.0.0.1; Host not found. As far as I cal tell, I'm not using a proxy - CURLOPT_PROXY is not set, I've run netsh winhttp show proxy to make sure there's not a system-wide setting in place, I've even checked all the browsers on my machine to confirm none are configured to use a proxy (just in case this could possibly have an effect). I'm having trouble figuring out why cURL insists on telling me that 1) I'm using a proxy and 2) it can't connect to it.
I'm able to resolve the error by explicitly disabling the use of a proxy via curl_setopt($curl, CURLOPT_PROXY, '');, but this isn't the greatest solution - a lot of the places I use cURL are in libraries, and it'd be a pain (not to mention less than maintainable) to go around and hack this line into all of them. I'd rather find the root cause and fix it there.
If it helps, this has happened to me only with POST requests so far. Command-line cURL (from a Git bash prompt) works fine. These calls also work fine from our dev machine, so it seems to be something specific to my machine.
If I need to apply the above hack, I will, but I thought before I resorted to that I'd ask the good folks of SO - is there anywhere I'm missing that could be configuring the use of a proxy? Let me know if there's any additional helpful info I forgot to add.
cURL relies on environment variables for proxy settings. You can set these on Windows via "Advanced System Settings".
The variables you need to set and/or change for optimum control are "http_proxy", "HTTPS_PROXY", "FTP_PROXY", "ALL_PROXY", and "NO_PROXY".
However, if you just want to avoid using a proxy at all, you can probably get away with creating the system variable http_proxy and setting it to localhost and then additionally creating the system variable NO_PROXY and setting it to *, which will tell cURL to avoid using a proxy for any connection.
In any case, be sure to restart any command windows to force recognition of the change in system environment variables.
[source - cURL Manual]

Connecting to SQL Server very slow

I have a standard php app that uses SQL Server as the back-end database. There is a serious delay in response for each page I access. This is my development server, so its not an issue with the live setup, but it is really annoying for working on the system.
I have a 5 - 8 second delay on each page.
I am running SqlServer 2000 Developer Edition on a Virtual Machine (Virtual PC).
I have installed SqlServer on my development machine but get the same delay.
I have isolated the issue to the call to mssql_connect (calling mssql_pconnect has no effect)
It is a networking issue on how I have set up (or not set up, since I didn't really change default config) SQL server. It's not a strictly a programming issue but I thought I might get some valuable feedback here.
Can anyone tell me if there is a trick, specific set of protocols, registry setting, something that will kill this delay?
I was also experiencing a 5-10 second delay on every connect, using the official Microsoft SQL drivers for PHP (as suggested by #gaRex) - none of the answers posted here solved it for me.
As suggested by #ircmaxell, my problem was a DNS issue - and the solution was to edit the \windows\system32\drivers\etc\hosts file (your local local host file) and add the name of my own machine to it.
In the "system properties" dialog, find the "computer name" of your machine - then add a line like 127.0.0.1 my-computer to your local host file.
For me, the delay occurred once more, on the following attempt to load the page - after that, it was super fast, no delay at all.
Note that this problem may occur even on a physical machine, not only on a VM.
I came across network issues when running virtual pc, everything network related is slow, try adding this entry on your registry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Create new DWORD value named DisableTaskOffload and set its value to 1.
Restart the computer.
It worked for me, source.
Is it perhaps a DNS issue? I know that MySQL does a reverse DNS lookup on each login (not each connection). If you don't have a reverse dns record for your server (or your dns is slow) it can cause a major delay at login. There's an option in MySQL to disable that. I'm not sure about SQL Server, but I'd assume it may be doing something similar...
I remember the same problem, but forgot, how we have solve it.
To clarify please specify exact connect strings, your SQLserver versions and also try to start this old good utility c:\WINDOWS\system32\cliconfg.exe, which is also can bring some light.
Yes, I know, it's from 2k, but guys at m$ don't like to create client tools from scratch.
Also try to get "right" mssql client dlls for PHP.

Categories