FMS 3.5 Server with non included Apache 2.2 Webserver

Thanks for your answers. This really is a majour issue in FMS if you don't have 2 separate IPs.
Hope the FMS Engenieers fix this quick.

Lots of separate questions in this thread, so I'll try to get to all of them.

quote:

---

Originally posted by: JayCharles
IMO... trying to get FMS to proxy all of your HTTP traffic is going to be more headaches that it's worth. I would just run FMS and the HTTPD server separately on separate IP's, and let FMS pass HTTP requests for video files off to the existing HTTPD server.

---

I agree, anyone who can get twice as many IP addresses and/or NICs really is better off running FMS and the webserver on separate addresses, unless they have some good reason not to (e.g., some crazy corporate firewalls will only let RTMPT through if it comes from the same address and port as an earlier "real" HTTP response). It's simpler, it's more efficient, you don't have to worry about namespace collision (e.g., if you have a web directory called "/open"), and you only have to deal with one product's bugs at a time.

And you don't need to get FMS to pass PD requests off to the other IP; make the Player app go straight to that other IP in the first place, and you can completely disable the HTTP proxying on FMS.

Also, if you don't need tunneling or port-80 RTMP (e.g., absolutely none of your viewers are behind firewalls), you can share an IP address, and just let FMS take port 1935 and the webserver take port 80.

If you can't do that (only have one IP, have to deal with those crazy firewalls, etc.), then you are going to have to share port 80, and that means setting FMS up as a proxy. If you're using the included apache, that's set up out of the box; otherwise, you have to change your webserver to listen to some other port (and maybe to localhost only--although leaving it open is nice for testing), and configure FMS to proxy to that port.

quote:

---

Originally posted by: JayCharles
Sounds to me that FMS isn't set up to handle POST data, and therefore cannot pass it along to Apache. Perhaps someone from the FMS engineering team can confirm that or correct me.

---

Well, we have definitely tested it with POST requests in the past. And I can hit a test CGI locally with a POST request and have it parse and log the values. So it's obviously not completely broken. (That doesn't mean there can't be any bugs, of course. We surprisingly have had almost no feedback from anyone outside who's using CGI or PHP that takes POST inputs, so I don't know how extensively it's really been exercised.)

quote:

---

Originally posted by: gkoo.ansis
As far as i've understood by reading the FMS's configuration files only the first connection is treated like an unknown http request.

---

I'm not sure I understand what you mean, but I can try to explain how it works, and hopefully that will relieve some confusion.

With HTTP (including tunneling), each connection can have as many requests as the client wants to send, and each request is interpreted individually. You can send a "GET /swfs/my.swf HTTP/1.1" request followed by a "POST /open/12345678 HTTP/1.1" request, in which case the first one will be proxied to the webserver, the second will open a RTMPT tunneling session (or, more likely, give you an error because I got the syntax wrong, but you get the idea). You can also send a "POST /scripts/foo.php HTTP/1.1" after that, and it'll be proxied to the webserver. (Technically, you shouldn't be pipelining anything after a non-idempotent request, but we're not going to check that and reject it, and webserver won't even see the POST in between.)

The very first request on any connection is special, in that if it starts with a byte from 0-31, we assume it isn't an HTTP/tunneling connection at all, but a binary RTMP connection.

However, there should be no difference between the first connection and another connection. If you use an old HTTP/1.0 browser (or just wait long enough between clicks), every request will go over a new connection. FMS doesn't even know that it has other connections from you; each one is treated independently (even in the case of tunneling--it's only after we map the HTTP requests back to tunneling sessions that we might have to demultiplex things).

quote:

---

Originally posted by: gkoo.ansis
When having a second connection ( eg. sending the post to the php file ) FMS reports the following:

2009-03-27 20:07:20 10178 (e)2611029 Bad network data; terminating connection : bad chunk version 117 on input stream
2009-03-27 20:07:20 10178 (e)2631029 Bad network data; terminating connection : (Adaptor: _defaultRoot_, VHost: Unknown, IP: , App:, Protocol: tunnel)

---

It looks like FMS is interpreting this as a tunneling request.

This could be a bug in the code. Or I could be misremembering what we log for "Protocol". But is it possible that your PHP script's location starts with one of the special names listed somewhere in the documentation (off the top of my head, "/open", "/close", "/idle", "/send", "/fms", "/fcs")? If so, that's not going to work; the way tunneling works is by stealing part of the URI namespace, and only proxying requests outside that namespace.

If that's not the problem, then something that both might be worth testing (to help us fix it) and might also be usable as a workaround: If you can change the form to send the equivalent GET request (with the variables encoded in the query string instead of in the body), and that works, then it _is_ probably something wrong with our POST handling (or, more likely, with handling request bodies).

Beyond that, if you can record all of the HTTP traffic between your client and server (e.g., with the Firefox LiveHeaders addon, or even Wireshark if you want to go nuts), and bundle that up with the FMS logs and the webserver logs, that would help to figure out what's going on.

Or you could just post a quick summary here. Something like this: "I sent a GET /index.html followed by a POST /play/select.php; the edge log saw the first one correctly but the second one gave exactly that bad network data message mentioned above; apache saw the GET and got a new connection for the POST but then timed out 60 seconds later."

Hi again. I've left behind the idea of using my own apache server and i've installed the one provided in FMS.
I thought i've misconfigured something in my Apache. After adding PHP support to the apache provided by FMS i still get the error listed earlier.
To be more specific i have a html containing a form that submits data through POST to a php script. The HTTP Request containing the POST is submited to the FMS Edge listening on port 80 which instead of forwarding it to the http daemon ( running on port 8134) to parse it using php, it just drops the connection giving the error stated earlier.
Am i doing something wrong ? Can anybody explain this situation ?

Hi Jody,

sorry for the delayed feedback.

At the moment I cannot work cotinuously on that. It is my own project and I had to do third party work meanwhile. I'll work with Jay's solution and bind Apache and FMS to different IP adresses. Thanks for the valuable config data at your comment.

I'll keep you updated soon.

Ruediger (my real Name is Ruediger, but that was occupied already for the username)

Hi Jody,

thanks for the fast answer. Yes I use my own installation of Apache. Everything works fine when I first start Apache and after that FMS. No error messages. I just wanted to be sure that I could proceed this way. Thanks again for your advise.

Rootplaner