jas wrote:I explicitly said I didn't want to use your tool.
The current manuals for mtmediasrv talk about nginx and not lighthttpd, so I was assuming you didn't want to switch from lighthttpd to nginx, which isn't a bad choice, but this fcgi daemon should also work under lighthttpd. I didn't know whether you knew this or not, so it seemed reasonable to point that out.
jas wrote:This is the line that kills me:
https://gist.github.com/sfan5/6351560#f ... tic-sh-L10
Code: Select all
# When settings this up be aware that the Minetest client
# will send a POST request to index.mth. You need to configure
# your web server to serve the file on POST requests for this to work.
What does this mean?! It is not trivial to set up an MT media server (not without using special tools). I searched and searched, and have no clue what serving files on POST requests is, and why I should have to in order to make an MT media server.
I'm just so super curious!
The method described above is broken. Only mtmediasrv properly implements the media server protocol. If you provide a static index.mth file then your media server will send useless data to clients and probably wrong data. On top of that, the manual method/scripts to setup a static media server are time intensive and you have no idea whether players actually get the media they need. All of these problems are solved by mtmediasrv, which even tells you for each client if they got the files they needed and how many they additionally needed directly from the minetest server.
If you're interested in understanding why the manual method is broken, I'd be happy to explain further.
To answer your question directly: a POST request means that the client sends the server some specifically formatted data. The HTTP server (lighthttpd/nginx/apache) has no way of interpreting this data. In order for the HTTP server to properly handle the POST data, it needs an fcgi daemon to handle it and tell it how to handle the client. Technically, POST-ing data to a static file should produce an HTTP error code, even, but most HTTP servers ignore it. To put it bluntly: in order to implement a proper remote media server, it must include a CGI daemon. Without a CGI daemon, it's a hack that doesn't do what it is supposed to.
Out of curiosity, why don't you want to run mtmediasrv? If there is a legitimate concern about it, I really would like to know.