Opened 12 years ago

Closed 12 years ago

Last modified 11 years ago

#6189 closed defect (fixed)

Erroneous Content-Range in mythweb raw stream

Reported by: Tom Dexter <digitalaudiorock@…> Owned by: Rob Smith
Priority: minor Milestone: unknown
Component: Plugin - MythWeb Version: 0.21-fixes
Severity: medium Keywords:
Cc: Ticket locked: no


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

Attachments (4)

mythweb-0.21-content-range.patch (783 bytes) - added by Tom Dexter <digitalaudiorock@…> 12 years ago.
mythweb-trunk-content-range.patch (787 bytes) - added by Tom Dexter <digitalaudiorock@…> 12 years ago.
mythweb-trunk-content-range.2.patch (1.7 KB) - added by Tom Dexter <digitalaudiorock@…> 12 years ago.
raw_stream_head_request.diff (924 bytes) - added by Tom Dexter <digitalaudiorock@…> 11 years ago.

Download all attachments as: .zip

Change History (9)

Changed 12 years ago by Tom Dexter <digitalaudiorock@…>

Changed 12 years ago by Tom Dexter <digitalaudiorock@…>

comment:1 Changed 12 years ago by Tom Dexter <digitalaudiorock@…>

I'm attaching a modified diff for trunk that contains these changes for both and, 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, 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.

Changed 12 years ago by Tom Dexter <digitalaudiorock@…>

comment:2 Changed 12 years ago by Rob Smith

Owner: changed from xris to Rob Smith
Status: newaccepted

comment:3 Changed 12 years ago by Rob Smith

Resolution: fixed
Status: acceptedclosed

(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

comment:4 Changed 12 years ago by 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 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 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 and 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)?


comment:5 Changed 11 years ago by Tom Dexter <digitalaudiorock@…>

I've noticed that, since my last post, the Content-disposition headers in the 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.

Changed 11 years ago by Tom Dexter <digitalaudiorock@…>

Note: See TracTickets for help on using tickets.