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