[ACE-4248] Not able to preview 'webm' file in FireFox browser which is uploaded in the site document library Created: 21-Sep-15 Updated: 01-Dec-16 Resolved: 16-Oct-15
|Project:||Alfresco One Platform|
|Fix Version/s:||Community Edition 201510 EA, 5.1|
|Reporter:||Charulatha Ganesh [X] (Inactive)||Assignee:||Closed Issues|
|Remaining Estimate:||Not Specified|
|Time Spent:||Not Specified|
|Original Estimate:||Not Specified|
Alfresco Share v5.1-SNAPSHOT (r111453-b320, Aikau 1.0.33, Spring Surf 5.1-SNAPSHOT, Spring WebScripts 5.1.2, Freemarker 2.3.20-alfresco-patched, Yui 2.9.0-alfresco-20141223)
|Attachments:||Not able to play the webm file in FF browser for second time.png big_buck_bunny_480p.zip webm file preview error FF 40.png|
Steps to reproduce:
Test Browser : FireFox (40)
Ref : Screen shot attached
|Comment by Charulatha Ganesh [X] (Inactive) [ 22-Sep-15 ]|
Hi Corina, I updated the description after trying with FF (40) and still able to reproduce the issue.
|Comment by Ray Gauss [X] (Inactive) [ 14-Oct-15 ]|
This appears to be due to the Firefox video player sending an invalid range request asking for content beyond the actual length (why it does that, I'm not sure).
Let's say the content length is 1000, Firefox is sending a range header of:
which means "give me bytes 1005 to the end", but the content length is only 1000.
In the example above the repository currently sends a response with no content and a Content-Length header with a value of -5 (which is a violation of the range spec) and the Share webscript fails to process it.
The repository should instead return an HTTP status of 416 (Requested range not satisfiable) which presumably the Firefox player would handle better.
Note that this incorrect handling of the invalid range request is likely to exist in previous versions of Alfresco.
Robert Schembri, how far back should the fix go? 4.2? Should this be moved to an MNT issue?
|Comment by Robert Schembri [ 16-Oct-15 ]|
|Comment by Ray Gauss [X] (Inactive) [ 16-Oct-15 ]|
Committed the fix (and a new unit test) for the invalid range request and the appropriate HTTP status code of 416 is now returned.
In an initial call for the content:
and immediately clicking around in the timeline:
However, Firefox unfortunately doesn't handle this any better than our original webscript failure.
We're now returning the appropriate response so I believe this ends up being a Firefox issue, both in the request for an invalid range and in its handling of that response.
|Comment by Charulatha Ganesh [X] (Inactive) [ 20-Oct-15 ]|
Closing this issue. Since seems to be a Firefox issue and won't be fixed.