I've installed free FMS developper version on a vista OS, using the embeded Apache server.
I added PHP 5.13 and everything seems to work except that :
when I try to manage HTML forms, using the 'post' method, the result is a prompt windows, asking me for downloading the php file (corresponding to that pointed in the 'action' attribute. It acts as if Apache did not recognize the type php.
My httpd.conf includes everyting to make php works fine. The clue is, when I change the form 'method' to 'GET', the php script works well !
My FMS is configured to tunnel the HTTP request, listening to ports 80 and 1935 ant proxying HTTP to port 8134 (defaults)
When I override this tunneling, by requesting the php file from my web browser directly to port 8134, it works fine too !
Now, I know that the problem comes from FMS and HTTP tunneling, but I have no idea how to solve it...
So....any tip or/and solution are very welcome !
Thanks for bringing this issue to light. Would you mind capturing the HTTP requests and responses for the case that worked and the case that failed. I'd like to take a look at the system with the request that you're making and see what might be up. The proxy should be nearly a raw byte proxy, but of course that's not entirely possible here. Anyway, perhaps it's a simple issue that can be fixed/worked around easily.
Feel free to contact me offlist with the information in lieu of posting for all, at your discretion - email@example.com
I'm experiencing the same problem, POST just refuses to work. Server is running on Win7HP.
At first I've thought that it's script fault, but after making this small test I've found out that it is fault of FMS proxy.
Test html, which sends POST request to itself:
<form action='' method='post'> <input type='Submit' name='Submit' /> </form>
Response (without the quotes):
"HTTP/1.1 200 OK
Content-Type: multipart/form-data; boundary=----------------------------9cf149a7623d
Is there any workaround for this? I find POST kinda useful, and I don't want to choose between POST and FMS.
I have the same problem.
My webserver is running, and I want to use rtmpt(80 port) to player a video. So I did as same as:
If you want Flash Media Server and your web server to share a port, set up Flash Media Server as the proxy, put your web server on an unused port, and change the fms.ini HTTPPROXY_HOST setting to point to that port.
ADAPTOR.HOSTPORT = :1935,80
HTTPPROXY.HOST = :8080
Everything is ok but when I sumit a form at web page.When I submit a form, the website send me a “application/x-fcs” type empty file let me download file.
What can I do to resolve this problem? Or how can I use the 80 port both my webserver and FMS?
CentOS Linux 5.4
Apache/2.2.3, PHP 5.1.6
Fms 4.0 x64
Is there any update on this bug? I am currently trying to install some PHP web apps on the same server as FMS and am having the very same issue as described above (PHP/MySQL pages work fine until data is POSTed, which results in a blank page being produced by the server - this blank page is either displayed or a download prompt is shown, depending on the browser).
I don't remember which version of FMS I was using when I post my first message.
I don't know if Adobe fixed this issue (according to the last post, obviously not).
I just want to share the solution I have applied (which is not really a solution, actually...).
I just didn't use the embedded Apache.
Download and install Apache as a independant package (as if you just need a web server).
Follow the guidelines in the FMS installation process enabeling the use of an external web server (which will manage the port 80) and let FMS does its job on the port 1935.
It still works for me.
Is there any updates on this issue? I am experiencing the same issue here, with Flash Media Streaming Server 4.0 on Linux CentOS.
In addition, also ajax calls, using post method, they all fail.
I hope there is a quick solution. Thanks.
I ran into this problem today too. GET requests work fine but POST fail to return properly and show an error of "Bad network data; terminating connection". The action the POST is trying to accomplish actually happens which means the script is getting the data but the response isn't getting back out the browser.