silverstripe-asset-admin
silverstripe-asset-admin copied to clipboard
silverstripe
Audio: no partial content: Accept-Ranges header missing (SS4)
Hi, I'm having an issue with audiofiles: I cannot use the range slider to move to another part of the file - partial content is not allowed. This happens on multiple installs, also by playing the file from within Asset Admin.
Playing back the SilverStripe-generated file url (link), the status code is set to 200 and the Accept-Ranges header is not set.
Playing back the 'raw url', the 206 status code is set and Accept-Ranges header is set to bytes. (server settings)
/assets/mydir/.protected/123123123/audio.mp3 <-- 206, works
/assets/mydir/123123123/audio.mp3 <-- doesn't work
If this is by design after all, then ok, but I hope it can be enabled somehow...
I think the reason for that is, that assets located in the protected filesystem are all routed through PHP (to check for permissions). So the things the webserver does by default (eg. supporting range-requests for seeking in streaming media) doesn't work.
Does publishing the file change anything?
Actually (sort of ashamed) it does!
I had been looking everywhere in my server settings until I found out that it had something to do with SilverStripe. Totally missed checking published.
Still I feel it should also work on pages tested before they get published..? If not why not? :)
It doesn't work because all requests to protected (unpublished) files are routed through PHP (ProtectedFileController to be exact). It seems like the actual response is then generated via FlysystemAssetStore -> HTTPStreamResponse, but these don't take range-request headers into consideration.
I guess it would be possible to implement in PHP, see this third-party lib for an example.
It's not in my power to decide whether or not this should be part of core though :) Seems more of an edge-case. Also, this issue should probably have been raised over at https://github.com/silverstripe/silverstripe-assets
OK, yeah, probably, once one knows where it originates :)
I did know the file-url is SilverStripe-generated, but didn't know where though. And your answer did help, because published audio does indeed accept ranges and gets that 206 status code.
Still not quite clear why unpublished audio shouldn't, is all. I wouldn't consider being able to browse audio/video or having it start at a certain position an edge case perse though.
Anyway, thanks :)
/assets/mydir/.protected/123123123/audio.mp3 <-- 206, works
/assets/mydir/123123123/audio.mp3 <-- doesn't work
Did you get that example the wrong way around? From later conversations, it sounds like /assets/mydir/.protected/123123123/audio.mp3 doesn't support range requests - which would make sense since it's routed through PHP. I don't think we'll implement this in core, since it's quite a fringe use case. But if you're missing any core APIs to apply a solution like the third party lib that was mentioned above, then please let us know and we'll add it.
From later conversations, it sounds like /assets/mydir/.protected/123123123/audio.mp3 doesn't support range requests - which would make sense since it's routed through PHP.
Nope, it's the reverse. The above example is as it is described; Accessing the folder directly (assuming the folder protection was removed) should force the file to be served via apache, hence support for file streaming.
/assets/mydir/123123123/audio.mp3 is the file served through the protected file controller, which to be honest, SHOULD support accept-range. It would not be hard for us to build this into the HTTPStreamResponse object; We simply hadn't made the attempt.
@chillu, sorry for the late response! @tractorcow, yes, that's absolutely what I meant :)
Would be nice if this could be solved :) Thanks!!!
Just had a chat with Jakub about this in a different context. This is actually an annoyance for a client who's on a proxy that download files before serving them to their local network.
I'm thinking implementing this might not be that difficult looking at this example. https://stackoverflow.com/questions/157318/resumable-downloads-when-using-php-to-send-the-file
One consideration might be that we need to check if the stream is seekable and return a different Accept-Range if it isn't.
Most of the magic would probably need to be implemented here: https://github.com/silverstripe/silverstripe-assets/blob/fc17276f93c6a5110fbe91e0796d4f0051c1c482/src/Flysystem/FlysystemAssetStore.php#L1510
