[MGNLRES-39] Chrome refuses to load FlowPlayer from resources workspace Created: 04/Jan/12  Updated: 29/Mar/22  Resolved: 05/Jan/12

Status: Closed
Project: Magnolia Resources Module
Component/s: None
Affects Version/s: 1.5
Fix Version/s: 1.5

Type: Bug Priority: Blocker
Reporter: Natascha Desmarais Assignee: Federico Grilli
Resolution: Fixed Votes: 0
Labels: binaries, contentlength, flowplayer, resources, response
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

CE 4.5 beta3, STK 2.0, resources 1.5-SNAPSHOT


Attachments: XML File config.modules.adminInterface.virtualURIMapping.debugSWF.xml     File flowplayer-3-2-7.swf    
Issue Links:
relation
is related to MAGNOLIA-3855 h.264 (mp4) video in a html 5 video t... Closed
is related to MGNLRES-38 Enable storing of binaries in resourc... Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:
Team: Nucleus

 Description   

As a spin-off from MAGNOLIA-3855:
The video player shipped with the new STK refused to play on Chrome, while it was working fine on Firefox (Safari uses its own built-in html5 player). The last set of tests revealed that if the SWF is being served from docroot instead of within resources, the player opens fine in Chrome. Here is the result and description of what I did:

***

Some more tests from Jan and me yesterday also did not work. We disabled the various filters (gzip, cache, range) and added a bypass for docroot from where we referenced the file to be played. We also set up a virtual URI mapping for the flowplayer itself so we could serve it from docroot. However, this did not work yesterday. This morning I removed the mgnlUserId and mgnlUserPSWD from the mov file link - yet another thing we had tried - and it started working! So I started taking back in all the filters that we had disabled and it still worked. Once I removed the virtual URI mapping for the flowplayer, it stopped working again.

So I conducted a few more tests:

  • If the SWF is served from docroot, the video player is loading without problem - even if the movie itself is being served through magnolia (I used a .mov for this test). All filters enabled. Bypass for docroot did not matter, tried it with or without and got the same result.
  • The above does not apply if the movie is a mp4 since Chrome will load its own player for that instead of the flowplayer.

Here are the response headers for both cases:

With the virtual URI mapping, working:
ndesmarais@Natascha-Desmarais-Mac:~ $ curl -u superuser:superuser -v http://localhost:8080/magnolia-empty-webapp/resources/templating-kit/js/mediaplayer/flowplayer-3-2-7.swf
* About to connect() to localhost port 8080 (#0)
*   Trying 127.0.0.1... connected
* Connected to localhost (127.0.0.1) port 8080 (#0)
* Server auth using Basic with user 'superuser'
> GET /magnolia-empty-webapp/resources/templating-kit/js/mediaplayer/flowplayer-3-2-7.swf HTTP/1.1
> Authorization: Basic c3VwZXJ1c2VyOnN1cGVydXNlcg==
> User-Agent: curl/7.19.7 (universal-apple-darwin10.0) libcurl/7.19.7 OpenSSL/0.9.8r zlib/1.2.3
> Host: localhost:8080
> Accept: */*
> 
< HTTP/1.1 200 OK
< Server: Apache-Coyote/1.1
< Set-Cookie: JSESSIONID=F354211ABB905DCE128F18D53C8C94D9; Path=/magnolia-empty-webapp
< Pragma: 
< Cache-Control: max-age=600, public
< Expires: Wed, 04 Jan 2012 09:14:36 GMT
< Accept-Ranges: bytes
< ETag: W/"120221-1323160324000"
< Last-Modified: Tue, 06 Dec 2011 08:32:04 GMT
< Content-Type: application/x-shockwave-flash;charset=UTF-8
< Content-Length: 120221
< Date: Wed, 04 Jan 2012 09:04:36 GMT
Without the virtual URI mapping, not working:
ndesmarais@Natascha-Desmarais-Mac:~ $ curl -u superuser:superuser -v http://localhost:8080/magnolia-empty-webapp/resources/templating-kit/js/mediaplayer/flowplayer-3-2-7.swf
* About to connect() to localhost port 8080 (#0)
*   Trying 127.0.0.1... connected
* Connected to localhost (127.0.0.1) port 8080 (#0)
* Server auth using Basic with user 'superuser'
> GET /magnolia-empty-webapp/resources/templating-kit/js/mediaplayer/flowplayer-3-2-7.swf HTTP/1.1
> Authorization: Basic c3VwZXJ1c2VyOnN1cGVydXNlcg==
> User-Agent: curl/7.19.7 (universal-apple-darwin10.0) libcurl/7.19.7 OpenSSL/0.9.8r zlib/1.2.3
> Host: localhost:8080
> Accept: */*
> 
< HTTP/1.1 200 OK
< Server: Apache-Coyote/1.1
< Set-Cookie: JSESSIONID=56ECA24619D30193F3A1866E1403DA85; Path=/magnolia-empty-webapp
< Pragma: 
< Cache-Control: max-age=600, public
< Expires: Wed, 04 Jan 2012 09:19:34 GMT
< Content-Type: application/x-shockwave-flash;charset=UTF-8
< Transfer-Encoding: chunked
< Date: Wed, 04 Jan 2012 09:09:34 GMT

***

This might be caused by the fact that the Content-Length is incorrectly set to 0 for the SWF being served from the resources workspace, so the onDOMReady event for loading the SWF simply stops there for Chrome. I'm attaching the virtual URI mapping and the flowplayer so you can try to reproduce this.



 Comments   
Comment by Federico Grilli [ 04/Jan/12 ]

Looks like it has nothing to do with serving from resources or content-length not specified. Here I found some hints http://flowplayer.org/forum/8/56798. I tried to load this sample page http://famousbooster.com/flowplayer/example/index.html and it does not work even though the Content-Length is set in the response. On the other hand, I tried what seems to be same example here http://flowplayer.org/demos/example/index.htm and it works! One thing I noticed:

  • in the working sample the type is application/octet-stream, in the not working sample is application/x-shockwave-flash
    and we serve flowplayer precisely with type application/x-shockwave-flash
Comment by Natascha Desmarais [ 05/Jan/12 ]

Thanks for your findings. I changed the mime type in the server setting and in what the js injects to reflect what you wrote, unfortunately it still didn't change the outcome. I will have a look around but have to come back to you with this most likely. The thing is that it works for Chrome in the static prototype and also if you serve the SWF from docroot with bypassing magnolia.

Comment by Federico Grilli [ 05/Jan/12 ]

"Looks like it has nothing to do with serving from resources or content-length not specified."

Last famous words: it HAS to do precisely with that. I tried to set the Content-Length header in the response and it works.

Comment by Eric Hechinger [ 13/Mar/12 ]

Tested --> ok.

Comment by Christian Balaguer [ 15/Mar/12 ]

I have the same issue with Magnolia 4.4.5. How can I work around this or set the Content-Length in the response header?

Generated at Mon Feb 12 06:46:46 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.