Some packages work over http but not with ssl (https)
I found a public example that has the same behavior on our site: https://scorm.com/wp-content/assets/golf_examples/PIFS/RuntimeBasicCalls_SCORM12.zip
This does work at the Moodle Sandbox Demo with https, however, so there must be some setting in our Moodle site that causes this. Regular http on the same server works, https then not... Moodle 3.4.1+ vanilla, right out of the box. I'm pulling my hair here (only figuratively speaking, I mostly lost my hair in the late 90's).
Helen, thanks, could very well be this. But a dumb question: how do I check if the slash arguments is supported and on? The Moodle server environment doesn't report about this, php info doesn't show this. I'm on a shared host and can't look at the Apache conf. I'm currently not at the server console but can this be checked from within Moodle? Scorm packages load "something", but the files seem broken somehow.
Answering myself here: after some googling I figured that based on the info here (http://httpd.apache.org/docs/2.4/mod/core.html#acceptpathinfo) URLs like https://moodlesite/my/index.php/arguments should give a 404 if the AcceptPathInfo is not on. Our site accepts URLs in this format, so slash arguments should work. Digging more.
does your $CFG->wwwroot value in config.php use the "s" -> https:// not http://
Also pull up the developer console in your browser and take a look to see what errors appear in the console and network tabs.
Thanks Helen and Dan! The https is in the config file, and otherwise the site seems to work. I did check the dev console yesterday and it seems that in the ssl installation the pluginfile.php produces somehow broken .js files. I'm not familiar with the pluginfile.php so I don't know how and where it pulls the files, I will investigate when or if I have the time. Have to play around with the slash arguments also, hopefully something will turn out.
Then, looking at scormfunctions.js I notice that at the end of the file the file itself has been duplicated, the "pasted" copy starts from line 52, column 17, which is everything after "function getAPI(" so the duplication starts with
// start by looking for the API in the current window..."
which obviously can't be correct.
Can you try clearing your browser cache or a different browser? The spdy protocol error sounds like a possible browser issue.
Thanks Dan for following this issue. However, this happened consistently on different computers.
After much more time than I care to admit I was able to pinpoint the problem to the HTTP response header "content-length". By disabling this in filelib.php our Scorm packages work perfectly!
I don't know why this is but this gives a lot to google for. I also don't know all the downsides that come from disabling the content-length, but as a quick workaround I have this now.
I was able to reduce the issue to a couple of lines of code, so this is not Scorm related at all.
This piece of code:
fails on our shared server in Chrome and works in Firefox. Chrome gives the "ERR_SPDY_PROTOCOL_ERROR". This is because the content length header and the actual content length don't match. But why, it is read by the code, in similar fashion than Moodle does.
I'll ask in Stack Overflow or Quora, I couldn't answers from there yet...
Edit: We are running Apache 2.2.22 with PHP 7.0.27.
OK so the SPDY error comes from a mismatching content length and not related to HTTP/2.
What is the difference between expected and actual size?
What about curl-ing that file directly from the server?
There's no reason for that mismatching but an Apache module doing something wrong there or something breaking that size in between the end user and the server like a reverse proxy.
Thanks again. Right, I should try curl'ng the file directly, currently I was testing with files in the Moodle data folder so they have to be fetched with a script.
I don't know that actual size of sent http content, I tried putting in numbers that Chrome dev tools gave me but with no luck. The PHP is able to fetch the correct size but it is for the uncompressed one.
This could have a lot to do with chunked encoding and the fact that PHP doesn't (can't) see the compressed size, some discussion here.
Edit: Is somebody running Moodle with Apache + chunked encoding + SSL and if so, are Scorm packages working fine? (Some other mod plugin files might be affected also.)
please share here a curl -v http://hostname/path/to/your/test/script changing the sensitive info for privacy purposes: I'd like to see if there are more than one Content-Length in your response.
Your issue affects the way Moodle serves any file, if you're compressing - guessing via mod_deflate - file server side without removing or re-evaluating the length of the content being sent.
I'd try to increase DeflateBufferSize to avoid chunking at the price of memory; otherwise, drop the header still using Apache - e.g. via mod_headers.c, Header unset Content-Length - and the user will miss just the progress bar when downloading files (w/o changing the main stream code).
It's worth noting that Moodle uses an aggressive browser based caching mechanism i.e IMHO I'd disable the serve side compression.
I appreciate your help, thanks!
I'm on a Windows box, with PowerShell, so the curl output might not be verbose enough even with the -v (?), but here:
My test script just serves Moodle README.txt with the readfile PHP function.
I disabled gzip with
<ifmodule mod_env.c=""> SetEnv no-gzip dont-vary </ifmodule>
in .htaccess and this seems to help. However, I still would like to know the basic cause of this. It seems that the file loads half the times ok and gives the protocol error half the times, it is very frustrating. Also, even with the caching the gzipping would still be desirable.
Thanks for the Apache conf tips! Are they doable in .htaccess also, the header unset thing and the buffer increase?
I guess random here means the ability to compress the file once in the buffer or not, since if I'm able to compress it within the given buffer I can evaluate the actual size and the module will fix the original content length sent by Moodle Files API; otherwise, the final length of the compressed payload will be unknown and hence your issue.
DeflateBufferSize cannot be define in an .htaccess whilst mod_header can be configured via that file e.g.:
Header unset Content-Length
I figured something like this is going on. I went with disabling zipping altogether, thus still having the progress bars working. Our site is still small so I have to monitor the traffic. Large content like images and videos won't benefit from gzipping anyway.