mod/scorm/apiphp returns wrong content-type header when loaded as javascript. This breaks SCORM for some users with restrictive security settings

interesting - I've got a couple of ideas on how we could improve this. 2.0 has a new admin level setting that forces users to enable js - we might be able to move that code further into api.php (can't remember where I put it in the first place) - this would mean that IE users with this security setting would get a nice notification of the issue and prevented access until they resolve it.

Well, yes but.... I found the problem because of one of those all too frequent corporate users who simply set security to the max. They will not see this as a problem of their making, they see it as Moodle being broken. It's actually a blocker for them. They are also using IE6 (and 1.9.11) which I appreciate is not supported for Moodle 2 but that's an argument for another day (I hate myself for saying this but I think it was a mistake to exclude IE6 for Moodle 2 )

it would be interesting to know if adding:
header("Content-Type: application/x-javascript\n");

to the top of api.php before any output made any difference - if it does that's easy to add - is that something you can test?

We've already asked the client to try it. Just waiting for the results. I'll let you know.

Some updates... we tried this and it didn't make any difference. However, 'application/x-javascript' is wrong because that was never supported by IE6. We are now working though 'text/javascript' and 'application/javascript'.

Another point though... I think the workaround for zlib.compression for IE6 could be wrong. The documentation (http://www.php.net/manual/en/zlib.configuration.php#ini.zlib.output-compression) implies that the values are '0' and '1' rather than 'on' or 'off'. It certainly seems that IE6 is getting the page with compression on regardless. We are also trying forcing it off with a '0'. I'll let you know.

To confirm, the following three lines solve the issue for the IE6 user..

@apache_setenv('no-gzip', 1);
@ini_set('zlib.output_compression', 0);
header( 'Content-Type: application/javascript' );

there were placed immediately after the IE6 workaround.

thanks Howard,

I'm 80% sure that I put that IE 6 zlib fix in place and tested quite thoroughly at the time and found on/off worked fine
this page:
http://php.net/manual/en/zlib.configuration.php
suggests to me that "on/off" and 0/1 should work.

so... To cover all bases I'm thinking about replacing the IE6 check with this:

 
 //IE 6 Bug workaround
 if (strpos($_SERVER['HTTP_USER_AGENT'], 'MSIE 6') !== false) {
     @ini_set('zlib.output_compression', 'Off');
     @ini_set('zlib.output_compression', 0);
     @apache_setenv('no-gzip', 1);
     header( 'Content-Type: application/javascript' ); //this line only in the api.php IE 6 check.
 }

are you able to confirm that the user_agent check is still working for your client? - they haven't modified that to the point that it fails have they?

Howard - are you able to verify that user_agent check is ok?

Hi Dan - yes, just heard back from the client. That works fine. I don't know if it's the Off changed to 0 or the different content-type that did the trick. The client wouldn't do any more experimenting once it worked

Thanks Dan this has been integrated now.

Passing this based on comments from How, thanks!

And now this is part of the best Moodle weeklies ever, thanks!

Closing.

This bug fix seems to have caused a regression for one of our clients.

The line:

@apache_setenv('no-gzip', 1);

Causes a 500 error in CentOS and RedHat.
http://stackoverflow.com/questions/2664441/phps-apache-setenv-function-causes-500-internal-server-error

As one of the comments in the stackoverflow link suggests it might be an issue with PHP being setup as a CGI-extension.