Erroneous Content-Range in mythweb raw stream

[Tom Dexter <digitalaudiorock@…>]

When downloading raw streams in mythweb, the Content-Range header being sent is not quite correct. If I understand RFC2616 (14.16) correctly, the range is supposed to be the starting and ending byte position (ie the byte offset). So for example, the first 500 bytes should be 0-499 and not 0-500. Likewise, everything except the first 500 bytes of a 1000 byte file would be 500-999.

When downloading raw streams from mythweb with wget, which honors the Content-Range over the Content-Length, it endlessly retries requests to retrieve a single byte past the end of the file.

I've attached patches for both 0.21-fixes and for trunk, though I've only tested 0.21-fixes (as that's what I'm running).

[Tom Dexter <digitalaudiorock@…>]

I'm attaching a modified diff for trunk that contains these changes for both stream_mp4.pl and stream_raw.pl, as they both use content range. Again note that I've only been able to test the 0.21-fixes version of the change.

On a somewhat related note, I was also wondering what your thought might be on this suggestion: In the 0.21-fixes version that I'm running, in handler.pl, I've added the following condition around the loop that prints the raw content:

if ($ENV{'REQUEST_METHOD'} ne 'HEAD') { }

This allows for programs like wget that can use a separate head request to get the "pretty" file name from the content disposition header, for example:

wget --content-disposition ​http://mythback/mythweb/pl/stream/1131/1235181600

...which will save using the program title. Perhaps wget is the only program that uses this extra round trip head approach to doing that, but I find it to be a really nice feature. I like to use wget for grabbing files off of mythweb because I can limit the download speed, thus preventing the download from saturating the backend network connection.

[Rob Smith]

(In [20114]) Fixes #6189, fixes the raw streaming to be correct (ala the mp4 streaming). The head request idea would be accepted, so feel free to toss up another patch

[Tom Dexter <digitalaudiorock@…>]

The HEAD request change I made in my 0.21-fixes install was simply a matter of surrounding the code printing from the file handle (in handler.pl) with a condition.

It appears that in trunk, a similar change wouldn't work for the purposes of getting the nice file name as I described, because the "Content-disposition: attachment; filename=..." headers are no longer being sent, even in stream_raw.pl. Again I don't have trunk running to try anything, but I'd think that the "Direct Download" link wouldn't send the browser a nice file name anymore, unless there's something happening I'm missing. It's still creating the $name variable with the nice file name in stream_raw.pl and stream_mp4.pl but isn't using it.

Was that removed for some specific reason? I figured it might have something to do with the Content-disposition causing browsers to bring up a save dialog when that wasn't desired or the like. Should it be doing that at least for the Direct Download (raw)?

Thanks.

[Tom Dexter <digitalaudiorock@…>]

I've noticed that, since my last post, the Content-disposition headers in the stream_raw.pl have been added back. This makes it feasible to support the head command for the purpose of getting the nice file name for raw downloads as I discussed earlier. I'm attaching a patch that should work for trunk and 0.22-fixes.