Don’t do that without setting your machine up as with a developer environment. Just update soundlang as you normally would.
Some progress, after installing the updated module (thanks for that) I’m getting the following error:
“Internal Proxy Error
There was a problem with the data received from the web site you attempted to access.
Please try to reload / refresh the page. If the problem continues please contact your IT support staff.
Problem encountered: Expectation Failed, Expect Request Header is not supported”
The end user is a health site and they have a third party managed adsl/firewall box which I’m assuming is the source of the error message, I wasn’t aware there was a proxy server included with it.
I’m not sure what the Expect Request Header status is trying to do (I’ve googled it but am not really any the wiser), but it seems there is some particular set of protocol steps the Freepbx server is making in retrieving the sound language files which the onsite proxy is rejecting.
I’ve queried the box supplier to see if any changes have been made over the holiday period.
Is there anything else I can check/do to work around this?
Thanks,
The FreePBX machine requires unfiltered outbound access to the internet. This is the problem. You just need to get them to add the server to the whitelist of ‘don’t mess with traffic from this machine’ and everything will start working again.
You can also just add “en” as a custom language which will allow you to trick it into letting you use anything that requires a language like system recordings. I did this work in the last update for people who don’t have Internet access.
HIPAA restrictions are pretty crazy. But it allows our fax business to survive. 
It seems to be related to the way curl sends the Expect header. I created a php script using curl to retrieve http://mirror1.freepbx.org/modules/ and setting the Expect header to “Expect:” retrieved the page correctly, but if I set the header to “Expect: 100-continue” I get the same error as seen in the soundlang result. In fact I get that response for any url requested with the 100-continue header set.
I accept that this isn’t a Freepbx problem (and thanks for the help chasing it so far), but it looks like a single line of code to set the Expect header would resolve it for me. If you can point me to the file where the curl request is created (hopefully I’m not oversimplifying and you are actually using curl here) I can make the change myself (and accept that it may be overwritten on an update).
I will also pursue the firewall/proxy support vendor to try and get them to fix their part, although it seems this Expectation Failed problem is common where proxies are involved.
But fixing the header looks to be the quickest way to resolve.
thanks,
Did you submit a ticket in the “Issues” tab?
That’s how things get fixed, especially if you already know what the answer is.
I don’t know that that’s the answer, but I suspect that it may be. I’ll submit a ticket.
There’s no bug here. This shouldn’t be reported as a ticket.
Basically you are asking us to provide a work around for a one off issue. cURL is doing what it’s been coded to do. We do not add the header expect. The internal curl code adds it. The workaround is to set expect to nothing. Potentially breaking other people. Hence not a bug.
You can use sound languages just fine if you do what I said above.
More information here about why/how freepbx does not set this but the internal curl code does: https://pilif.github.io/2007/02/the-return-of-except-100-continue/
Ok, we can leave it at that then. I did submit a ticket but have now deleted it.
The article you link to does make mention of a need for curl to handle the situation where the expect header is not supported and gives a workaround. As I said earlier, it’s not a Freepbx problem and I was asking for a pointer as to where I could add the workaround myself.
I had a problem with the updated Soundlang module in that after the error message was displayed, the link to Custom Languages at the bottom of the page was modified in that the address of the Freepbx server had been replaced by the address of the site’s gateway (the firewall/proxy box). I tried manually entering the link with the correct server address but it took me back to the dashboard, so I couldn’t access the Custom Languages page. I’ve reverted to the previous soundlang module now.
If I want to add a custom “en” langauge, do I need to upload the sound files located in the existing “en” directory?
To close this off, the proxy/firewall vendor was able to disable the transparent proxy server, so everything is functioning correctly again.