FMS and its “built-in” HTTP support: First Impressions

Flash Media Server version 3.5 sports some new HTTP features that, on the surface, are really sort of exciting. The idea that a single deployment might support Flash video over both RTMP and HTTP makes my inner geek smile.

FMS 3.5 came out a few months ago, but due to workload and lifeload, I just hadn’t had time to test out the HTTP goodies. Last week, one of my clients came to me with a challenge that required diving headlong into FMS’s HTTP support.

The trouble my client was having was that he couldn’t find how to enable HTTP support for FMS Vhosts. After a short investigation I found the cause of the trouble… there is no built-in support for consuming HTTP resources from a Vhost.

Out of the box HTTP support in FMS works like this:

  • Upon installation, FMS installs Apache 2.2, configured to bind to port 8134
  • A “webroot” folder is created in the FMS installation directory
  • FMS handles all requests for both RTMP and HTTP
  • When FMS encounters an HTTP request, it proxies that request to port 8134
  • Apache goes looking for a file in the default webroot directory

… that’s it. Once FMS hands off to Apache, FMS is out of the picture. It’s then up to Apache to do the rest of the job.

Now, if your FMS/Apache deployment uses all of the default configs, and if you don’t need to support HTTP for multiple Vhosts or support for serving files over HTTP from the same location from which you serve RTMP (a la HTTP’ing files from your FMS Vhost directory structure),  this arrangement works quite nicely. You dump your files into the preconfigured webroot (as well as into the director you’ll use for serving via RTMP), and you’re done.

In my client’s case (and in the case of just about everyone else I’ve built FMS apps for), multiple Vhosts and/or delivering media files from application directories (without duplicate files elsewhere) are requirements… and in this particular case, the only option was to enable Vhost support on the Apache FMS installed.

I like to think of myself as a fairly smart guy, and I’m reasonably quick when it comes to picking up on new things… but administering Apache is an area of broad scope. After two days of doc reading, forum searching, and some help from folks on the FMS Listserv , I found my way through to what needs to be done. The first half of the job involves setting up a corresponding Vhost on Apache for each FMS Vhost (or creating a wildcard Vhost on Apache… that’s the route I took) using mod_vhost_alias, and the second half is to create rewrite rules to translate HTTP URL’s to the application directory structure within the FMS Adaptor, using mod_rewite.

Right now, anyone who has previous experience with Apache is thinking something along the lines of “well duh Jay, I could have told you that”, but having never worked with Apache in the past, it was a challenge to get it done. That’s not a complaint, but it does raise a complaint…

Now that FMS is being advertised as having “HTTP delivery support” included, many of my clients are going to expect me to get it working regardless of the app structure (after all, Apache is now “part of FMS” so to speak). Non technical people (you know… the ones that are usually writing the $4500 check for FMS) are apt to assume that since the marketing speak used on the FMS product page simply says “HTTP delivery support” it means HTTP support is native to FMS and FMS can serve up all of your media over both HTTP and RTMP. That’s not really the case. What FMS can do is proxy requests to an httpd server… but unless you’re using the default httpd configuration and putting your files into the default webroot as set up by FMS, you’re on your own to configure Apache to handle the requests as you need them to.

My personal take on this is as follows; If Adobe is going to market FMS as supporting HTTP delivery, there ought to be some tighter integration between FMS and the httpd server. Of course, there’s no way the FMS engineers can provide automatic support in all situations, but it seems to me that the included httpd server (in this case, Apache) could be/should be pre-configured to handle what FMS developers have come to know as common configurations (i.e the typical application/streams/instance/file.xxx structure FMS creates when recording streams). Even better would be extending FMS to support making Apache configuration changes a task that would be handled through the FMS admin console (that would actually be pretty sweet… a bit of GUI that lets an FMS admin associate directories in the FMS adaptor structure with HTTP URL’s).

Barring that, I really think the point about HTTP support should be removed from the FMS product page, or at very least qualified with a description of what can and can’t be done before you need to get your hands dirty with Apache configuration changes.

One Response to “FMS and its “built-in” HTTP support: First Impressions”

  1. Ela Says:

    Hi,

    I am facing port problem as like this.

    i installed fms in my server, and already its running a apache for hp, so want to run this fms as a separate port in 8083

    While installing i gave port number as 8083,and now its shows in “fms.ini”

    ADAPTOR.HOSTPORT = 1935,8083

    I think it should listen any of these ports, but its not working while am acessing

    domain.com:8083 domain.com:1935

    Please tell me why its not working

    Thanks in advance

Leave a Reply