weird behaviour of lib/requirejs.php

weird behaviour of lib/requirejs.php

by Valery Fremaux -
Number of replies: 1
Picture of Plugin developers

Hi guys, i was  experimenting for some weeks on several installs a strange error that could appear as a randomly occurring syntax error in the first.js amd code aggregator.

After some hours of digging, i found that the response of lib/requirejs.php/-1/core/first.js was actually a bit strange :

when firing several time the (uncached) js code, appears the first.js code not being always complete. It comes sometime truncated from the first part, and starts in middle of the JS, which ostensibly fails into understandable parsing error.

The weird part is that the content given to the js_send_uncached($content, $filename) of lib/jslib is regular and constant size (that is all the js is properly given to the sender.

Whats(s weird :

  * the js_send_uncached just put some headers out and echoes the content.

  * the cutoff points are in general random, but some patterns seems being happening several times at the same cutoff location, f.e :

I got in a short time the cutoff point :

 promises.
        if (exception !== null) {
            for (; i < requests.length; i++) {
                request = requests[i];
                request.deferred.reject(exception);
            }
        }
    };
in two separate tyout successively on FF and Chrome.

  * when arrives truncated in the browser, even the response headers have disappeared.

  * The truncation event sequence is not stable, but usually no more than two truncated requests successively.

  * local browser cache seem not having effect

Moodle is 31 and using a local Apache2 on windows 8 (for environment info)

Do someone know something about this phenomenon ?

Average of ratings: -
In reply to Valery Fremaux

Re: weird behaviour of lib/requirejs.php

by Valery Fremaux -
Picture of Plugin developers

Several additions to the description :

Issue comes also on other javascript aggregators such as yui_combo.php with following symptoma :

   * Script loads truncated with a leading hex code (e.g. 1abe9),, then the truncated part

Turned to nginx servicing with CGI php :

   * No change in behaviour (this eliminates web server desease)

Conclusion : no web agent implication, no server implication. What remains ?

I started rebuilding a new code base with last 3.1.7+ and launched upgrade. The upgrader noticed some of my tables were still in Antelope (no idea how i could miss the format conversion before !). After compressing tables, the script loading errors stopped. The amd typical design errors are much better reported).

Maybe this stops the topic...