Opened 15 years ago
Closed 15 years ago
Last modified 15 years ago
#6189 closed defect (fixed)
Erroneous Content-Range in mythweb raw stream
Reported by: | Owned by: | Rob Smith | |
---|---|---|---|
Priority: | minor | Milestone: | unknown |
Component: | Plugin - MythWeb | Version: | 0.21-fixes |
Severity: | medium | Keywords: | |
Cc: | Ticket locked: | no |
Description
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)
Change History (9)
Changed 15 years ago by
Attachment: | mythweb-0.21-content-range.patch added |
---|
Changed 15 years ago by
Attachment: | mythweb-trunk-content-range.patch added |
---|
comment:1 Changed 15 years ago by
Changed 15 years ago by
Attachment: | mythweb-trunk-content-range.2.patch added |
---|
comment:2 Changed 15 years ago by
Owner: | changed from xris to Rob Smith |
---|---|
Status: | new → accepted |
comment:3 Changed 15 years ago by
Resolution: | → fixed |
---|---|
Status: | accepted → closed |
comment:4 Changed 15 years ago by
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.
comment:5 Changed 15 years ago by
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.
Changed 15 years ago by
Attachment: | raw_stream_head_request.diff added |
---|
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.