I have just installed a 2.3.0 Beta 2 system with Centos 4.4, Asterisk 1.4.10 and all seems to be working fine, however when we perform a Apply configuration changes, the changes do not get submitted to the system, and the following messages is displayed:
Error: Did not receive valid response from server
If i enter the URL /admin/config.php?handler=reload into the browser and submit, it performs a reload and all changes are submitted (some config text etc is displayed on screen and we simply re-navigate back to the admin page)
Anyone else experiencing this issue? I cannot see any errors in httpd/error_log or access_log or in /var/log/messages
I performed an online update of modules post install so all is latest versions at time of this post.
Ok, So have done some more testing and this issue appears to be browser related.
It seems to work fine in Safari, but not in Camino (the browser we use for managing all the systems!) I will have to see if there is an update for Camino. Have also tested it on Firefox (Version 2.0.0.6 which is up to date) and it is broken there as well, so seems to be a prob with the ajax code and mozilla browsers? Seems like we have done a backflip on the previous state where mozilla was all good and the incumbents were not well supported.
We develop on Firefox and it works fine on Firefox so the Firefox issue seems strange. Have never tested on Camino but if you are having the same problem with FF it seems there may be something different in your environment. Unfortunately there is not enough information to better diagnose what is going on. Have you gone into Firebug (since the issue is on Firefox) and seen if there are any errors coming up. Have you also tried to refresh your cache and make sure everything is up to date?
When the threads start filling with message exchanges like
-working -not working -working -not working
they get quite boring, it seems to me no one is willing to work
on the problem. So it is time to find a solution alone.
Any way I tracked the problem to the use of a proxy that
is handled quite differently between FF and IE.
I suggest the developers read the following discussion
http//forum.mootools.net/viewtopic.php?pid=20400
and maybe update the scripts not to have this proxying problem.
Otherwise they will face many other threads…I am afraid…
Anyway I am available for tests.
[quote=“paolo.prandini”]When the threads start filling with message exchanges like
-working -not working -working -not working
[/quote]
paolo - you are taking the context of my post wrong. We ask people for information and that information is often not always forth coming. What platform (I was pointing out browser on windows). What environmental issues (e.g. proxy-s as is the case here), etc.
I’m glad to see you step up to the plate and help track down the issue and the solution. That is what Open Source is about. When we get such information, we are able to take action and determine what needs to happen to rectify problems.
The next step that will help accelerate a solution is for you or someone else to take the information that you have found, apply a fix that seems to solve your problem, and then open a ticket with that suggested fix.
At a minimum, opening a bug on the issue, with the detailed steps and supporting data, will be immensely helpful. (Steps like “have to have Squid version xyz running in abc mode”, etc.). And then the link.
thanks for pulling that up and for getting the ticket open on this, it really is appreciated.
I have Firefox 2.0.0.6 (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.6) Gecko/20061201 Firefox/2.0.0.6 (Ubuntu-feisty)) and have a problem with Squid (and works fine without it).
I applied the mentioned above path to ‘freepbx_reload.php’ but it still fail to reload FreePBX when I connect via Squid.
for those of you who tried the patch, and some saw the error still and some did not - can you compare notes on the squid config? I don’t use squid at all, so don’t know what if anything is configurable that may make it different.
As far as php and time-outs, the Ajax code times out eventually and provides an error if it does not hear back, as implemented (IIRC) so I don’t think it would be related to that.
[quote=“razametal”]Yes… the problem is related with proxy.
I’ve the error when using squid as proxy, but if I do not use it the problem dissapears.
Regards,[/quote]
I’m going to have to go ahead and disagree there. Over here, I’ve got 2 machines, 1 Mac with OS X 10.4.10 running FF 2.0.0.6, and 1 PC with Ubuntu Feisty running FF 2.0.0.6. Neither machine is proxied, in fact, I have no proxy running on the network. Both are in the same subnet as the Asterisk system as well.
The problem occurs on both systems. The server is Ubuntu Dapper using lighttpd and PHP 5.1.2, which has always worked great.
If I go to the Mac and use Safari, it works fine, leading me to believe it’s a FF 2.0.0.6 incompatability.
Is there any sort of debugging I can flip on and provide?
PS - the patch supplied on Trac #2256 did not fix the issue for me.
can you take your failing system and get access to a FreePBX installation elsewhere that is using Apache? It would be valuable to see if lighthttpd has anything to do with it. Because Other installations running FF 2.0.0.6 on Linux based platforms seems to work in other situations?
can you take your failing system and get access to a FreePBX installation elsewhere that is using Apache? It would be valuable to see if lighthttpd has anything to do with it. Because Other installations running FF 2.0.0.6 on Linux based platforms seems to work in other situations?[/quote]
That’s a huge bummer, I liked using lighty… Changing from lighty to apache “fixed” the problem using FF 2.0.0.6 on both Linux & Mac for me.
Thanks for the help. Anything I can provide that might help with using lighty?
I would say to continue testing options to solve the ‘proxy’ problem against httpdlite because maybe there one of the fixes that will work against httpdlite. (Maybe changing the request form a POST to a GET?)
I did not know about it.