Skip to main content
August 31, 2010
Question

FMS, PHP and POST method forms...

  • August 31, 2010
  • 5 replies
  • 4120 views

Hi,

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,

    This topic has been closed for replies.

    5 replies

    Participant
    November 14, 2011

    does anyone know if this was fixed in FMS 4.5?

    Participant
    August 2, 2011

    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.

    November 3, 2010

    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:

    http://help.adobe.com/en_US/flashmediaserver/configadmin/WS02f7d8d4857   b167770a4686812a808b6918-8000.html

    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.

    httpd.conf

    Listen *:8080

    fms.ini:

    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?

    My Configuration:

    OS:

    CentOS Linux 5.4

    Webserver:

    Apache/2.2.3,   PHP 5.1.6

    Meadia Server

    Fms 4.0 x64

    Adobe Employee
    November 9, 2010

    Hi ViliusSutkus & up2080

    Adobe is aware of this issue and we are working on fixing this issue - thanks a lot for reporting the issue. We'll keep you updated.

    Participant
    June 15, 2011

    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).

    Many thanks.

    Participant
    October 20, 2010

    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

    Cache-Control: no-cache

    Connection: Keep-Alive

    Content-Length: 1

    Server: FlashCom/4.0.0

    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.

    Asa_-_FMS
    Adobe Employee
    Adobe Employee
    September 1, 2010

    HI LeHardy,

    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 - awhilloc@adobe.com

    Asa