Ask Questions and Find Answers
Important:
Ask is now read-only. You can review any existing questions and answers, but not add anything new.
But - don't panic! While ask is no more, we've replaced it with discuss - the new Liferay Discussion Forum! Read more here here or just visit the site here:
discuss.liferay.com
Valamis + Liferay [HTML5 slides [SCORM based CBT] not working in Chrome
LMS [VALAMIS] HTML5 based CBT's designed in Captivate (10) runs perfectly in FireFox / IE / Edge but when comes to Chrome it plays just portion of first slide [like 9-10 seconds] and then halts.
Browser Console depicts following log:
src = https://abc/xyz/learn-portlet/SCORMData/data/1676/ar/2381591.mp3 error code = 4 n/w state = 3 CPM.js:370 Event {isTrusted: true, type: "error", target: audio, currentTarget: audio, eventPhase: 2, …}
src = https://abc/xyz/SCORMData/data/1676/ar/2538057.mp3 error code = 2 n/w state = 1 CPM.js:370
Event {isTrusted: true, type: "error", target: audio, currentTarget: audio, eventPhase: 2, …}
same CBT when run in other browsers work perfectly. on the server side we have Apache HTTPD [acting as web server + SSL applied] ---> Tomcat 7When I remove Apache from front and it goes to direct Tomcat 7 then
GET http://abc:8080/learn-portlet/SCORMData/data/1676/ar/2401874.mp3 net::ERR_CONTENT_LENGTH_MISMATCH 206 (Partial Content) :8080/learn-portlet/SCORMData/data/1676/ar/2538057.mp3:1
GET http://abc:8080/learn-portlet/SCORMData/data/1676/ar/2538057.mp3 net::ERR_CONTENT_LENGTH_MISMATCH 206 (Partial Content) :8080/learn-portlet/SCORMData/data/1676/ar/2401874.mp3:1
GET http://abc:8080/learn-portlet/SCORMData/data/1676/ar/2401874.mp3 net::ERR_CONTENT_LENGTH_MISMATCH 206 (Partial Content)
cannot find any related log on server side when this thing happen [neither in HTTPD nor in Tomcat] my worry is if its partial content [not completed somehow] then why FF / IE / Edge are doing it fine. suspect I feel is Chrome policies or restrictions. due to which I have added user interaction in start of CBT [so that audio gets permission to be played].
Browser Console depicts following log:
src = https://abc/xyz/learn-portlet/SCORMData/data/1676/ar/2381591.mp3 error code = 4 n/w state = 3 CPM.js:370 Event {isTrusted: true, type: "error", target: audio, currentTarget: audio, eventPhase: 2, …}
src = https://abc/xyz/SCORMData/data/1676/ar/2538057.mp3 error code = 2 n/w state = 1 CPM.js:370
Event {isTrusted: true, type: "error", target: audio, currentTarget: audio, eventPhase: 2, …}
same CBT when run in other browsers work perfectly. on the server side we have Apache HTTPD [acting as web server + SSL applied] ---> Tomcat 7When I remove Apache from front and it goes to direct Tomcat 7 then
- CBT plays 3 slides perfectly [around 1.5 minute runs ] and then halts.
- shows different Error in browser console
GET http://abc:8080/learn-portlet/SCORMData/data/1676/ar/2401874.mp3 net::ERR_CONTENT_LENGTH_MISMATCH 206 (Partial Content) :8080/learn-portlet/SCORMData/data/1676/ar/2538057.mp3:1
GET http://abc:8080/learn-portlet/SCORMData/data/1676/ar/2538057.mp3 net::ERR_CONTENT_LENGTH_MISMATCH 206 (Partial Content) :8080/learn-portlet/SCORMData/data/1676/ar/2401874.mp3:1
GET http://abc:8080/learn-portlet/SCORMData/data/1676/ar/2401874.mp3 net::ERR_CONTENT_LENGTH_MISMATCH 206 (Partial Content)
cannot find any related log on server side when this thing happen [neither in HTTPD nor in Tomcat] my worry is if its partial content [not completed somehow] then why FF / IE / Edge are doing it fine. suspect I feel is Chrome policies or restrictions. due to which I have added user interaction in start of CBT [so that audio gets permission to be played].
I can only guess here since I am not sure what you are doing. As far as I can tell:
1) You have developed your own portlet
2) You deliver mp3 files from that portlet.
The console error actually tells you what you are doing wrong:
ERR_CONTENT_LENGTH_MISMATCH 206 (Partial Content)
You send a HTTP 206 code to deliver the content in parts.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/206
When you do that, you have to set a
1) You have developed your own portlet
2) You deliver mp3 files from that portlet.
The console error actually tells you what you are doing wrong:
ERR_CONTENT_LENGTH_MISMATCH 206 (Partial Content)
You send a HTTP 206 code to deliver the content in parts.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/206
When you do that, you have to set a
"Content-Length:"
header. Obviously that header is incorrect. Firefox seems to be more lenient and ignores the problem, Chrome dislikes it. So, you need to fix your Content-Length header.
thanks for quick response,
1. its portlet provided by VALAMIS [uses Iframe to load CBT], that is why its hard for me to get into its details.
2. you are right its related to Content-Length mismatch but why I am on this forum because same Content-Length when provided to FireFox it not only accepts but runs complete audio without any failure. that means the audio [mp3] provided by LMS has no problems, even when I run same CBT on localhost [without LMS] it goes smooth in Chrome.
3. Further I am diving into this Content-Length and will update you, let me know if you get any further clue. thanks again.
1. its portlet provided by VALAMIS [uses Iframe to load CBT], that is why its hard for me to get into its details.
2. you are right its related to Content-Length mismatch but why I am on this forum because same Content-Length when provided to FireFox it not only accepts but runs complete audio without any failure. that means the audio [mp3] provided by LMS has no problems, even when I run same CBT on localhost [without LMS] it goes smooth in Chrome.
3. Further I am diving into this Content-Length and will update you, let me know if you get any further clue. thanks again.
Browsers react differently to invalid headers. Firefox is probably just more lenient and ignores an invalid entry.
Using the developer console you should be able to check the request/response headers. You could also try to use curl to request a range. The following request should return a content-length of 1024.
If the length is incorrect, you could try to unset the header in Apache. I am not sure, how browsers will react to that, but maybe it is better than the current behavior.
Using the developer console you should be able to check the request/response headers. You could also try to use curl to request a range. The following request should return a content-length of 1024.
curl -i -H "Range: bytes=0-1023"
http://abc:8080/learn-portlet/SCORMData/data/1676/ar/2538057.mp3If the length is incorrect, you could try to unset the header in Apache. I am not sure, how browsers will react to that, but maybe it is better than the current behavior.
Dear Christoph, i have done couple of things explained below but no success:
1. Disable compression of downloading files (mp3 & mp4) in Apache [no result same behavior]
2. unset the Content-Length in application (in code) [crashed even earlier than previous attempts]
3. then in Chrome console while looking into Network section --->
First Header (Response) ============ 200 Status Code describes Content Type
Second Header (Response) ========= 206 Status Code and Content-Length: 637894
Third Header (Response) ========= 206 Status Code and Content-Length: 1
Fourth Header (Response) ========= 206 Status Code and Content-Length: 1
and so on so many 1 length packets, till the voice stops (in the middle). kindly have a look and let me know what I am missing to figure out the problem.regards
1. Disable compression of downloading files (mp3 & mp4) in Apache [no result same behavior]
2. unset the Content-Length in application (in code) [crashed even earlier than previous attempts]
3. then in Chrome console while looking into Network section --->
First Header (Response) ============ 200 Status Code describes Content Type
Second Header (Response) ========= 206 Status Code and Content-Length: 637894
Third Header (Response) ========= 206 Status Code and Content-Length: 1
Fourth Header (Response) ========= 206 Status Code and Content-Length: 1
and so on so many 1 length packets, till the voice stops (in the middle). kindly have a look and let me know what I am missing to figure out the problem.regards
I just tried it myself and the headers actually look correct. Still, Chrome continues sending requests for a missing byte it already has received. Maybe somebody else has an idea, but I am stumped. My best guess is a bug in Chrome.
The browser requests:
Range: bytes=0-
The server sends:
Content-Length: 637894
Content-Range: bytes 0-637893/637894
The browser requests several times in a row:
Range: bytes=637893-
It simply shouldn't do that.
The browser requests:
Range: bytes=0-
The server sends:
Content-Length: 637894
Content-Range: bytes 0-637893/637894
The browser requests several times in a row:
Range: bytes=637893-
It simply shouldn't do that.
instead of Sending Status 206, send status 200 and updated the header to not include Content Length [as mentioned by Christoph] ------- this thing worked for me. resolved.
Thanks Christoph for your help.Idea got from this link
https://github.com/webpack/webpack-dev-server/issues/1044
Thanks Christoph for your help.Idea got from this link
https://github.com/webpack/webpack-dev-server/issues/1044
Copyright © 2025 Liferay, Inc
• Privacy Policy
Powered by Liferay™