Topic: CGI issue with returning large partial responses

[tickerguy]

I am attempting to build a media content server that runs under CGI and I suspect I've hit a wall that precludes what I'm trying to do.

Let's presume I send a URL formatted as thus:

https://site.domain/cgi/media-server?file.mp4&auth-key

Where "auth-key" is an authentication key from the calling location. The cgi program looks up the auth key, validates it, and if it likes it returns the requested file with the appropriate headers.

This works fine even for very large (e.g. 300Mb) files provided that I send the whole file back.

But if I implement 206 Partial Content responses, which you really want to do for content like this, then some browsers sort-of work with HTML5 players (e.g. Firefox) and others break instantly (e.g. Chrome.) Tracing what is going on they detect the "Range" capability, send an initial request and where it goes wrong in those that break is when the client breaks the connection during transmission -- which Chrome, in particular, does almost immediately after the first megabyte or two go out after it probes for this capability. For reasons that are not obvious Firefox also stops taking the original transfer mid-course but DOES come back with "gimme what's left" (with the correct offset) at the appropriate time if you're playing the file -- although if you seek beyond where it already grabbed it will only let you do so for a few minutes ahead -- while Chrome's HTML5 video element does not; it throws up instead and refuses to play the file at all. The cgi program both gets back a return for the short writew/appropriate error code and is getting a SIGTERM as well (expected) when the client end unceremoniously drops the link displaying a blank screen with no valid "play" button.

Thus it appears that partial content replies are a problem in this regard. I'm not using FastCGI in this test and I'm not sure it makes sense to do so (nor that it would help) because the number of potential concurrent users is very large and the "dwell time" is too, so the number of FastCGI instances I'd have to have running to deal with that could get rather ridiculous for little gain as overhead of open/lookup relative to returning 100MB files is relatively small on a percentage basis. I suspect, however, the same problem would likely apply to a FastCGI implementation.

If I just put the files in a directory they serve fine; Apache deals with the partial content requests as expected and the browser console shows it doing the right thing -- and the entire seek bar works on all the browsers I've checked.

The other possible way I could deal with this would be to let Apache serve the files from static locations, have the files all be in a common place, but tag the requests with a "?xxxxxx" on the end which is user-specific when the call is made to play them (e.g. in a "<video>" element on the calling page. The problem then is intercepting that URL and making a decision based on the parameter (and refusing if its missing, of course); I do not believe there is a "mod_" module that can take a URL, pass it to some sort of external arbiter (which is easy for me to write) complete with said parameter, and then return either zero/nz (auth good/denied.) This obviously requires that there be external ways to make the token difficult or impractical to filch (since it is trivially exposed in the browser's console) but having it be "good enough" is pretty easy.

Any ideas from the community in this regard?