Complex javascript code breaks <pre> tags and Connection to server

[distante]

When using complex javascript code between <pre> tags, the connection to the server gets broken. Any attempt to save, previow or publish will end in a ERR_CONNECTION_RESET. Tested in a recently installed Wordpress 4.9

Steps to reproduce

1. Create a New Post
2. Go to TEXT tab.
3. Paste the next code:

Code to use

var __awaiter = (this && this.__awaiter) || function (thisArg, _arguments, P, generator) {
    return new (P || (P = Promise))(function (resolve, reject) {
        function fulfilled(value) { try { step(generator.next(value)); } catch (e) { reject(e); } }
        function rejected(value) { try { step(generator["throw"](value)); } catch (e) { reject(e); } }
        function step(result) { result.done ? resolve(result.value) : new P(function (resolve) { resolve(result.value); }).then(fulfilled, rejected); }
        step((generator = generator.apply(thisArg, _arguments || [])).next());
    });
};
var __generator = (this && this.__generator) || function (thisArg, body) {
    var _ = { label: 0, sent: function() { if (t[0] & 1) throw t[1]; return t[1]; }, trys: [], ops: [] }, f, y, t, g;
    return g = { next: verb(0), "throw": verb(1), "return": verb(2) }, typeof Symbol === "function" && (g[Symbol.iterator] = function() { return this; }), g;
    function verb(n) { return function (v) { return step([n, v]); }; }
    function step(op) {
        if (f) throw new TypeError("Generator is already executing.");
        while (_) try {
            if (f = 1, y && (t = y[op[0] & 2 ? "return" : op[0] ? "throw" : "next"]) && !(t = t.call(y, op[1])).done) return t;
            if (y = 0, t) op = [0, t.value];
            switch (op[0]) {
                case 0: case 1: t = op; break;
                case 4: _.label++; return { value: op[1], done: false };
                case 5: _.label++; y = op[1]; op = [0]; continue;
                case 7: op = _.ops.pop(); _.trys.pop(); continue;
                default:
                    if (!(t = _.trys, t = t.length > 0 && t[t.length - 1]) && (op[0] === 6 || op[0] === 2)) { _ = 0; continue; }
                    if (op[0] === 3 && (!t || (op[1] > t[0] && op[1] < t[3]))) { _.label = op[1]; break; }
                    if (op[0] === 6 && _.label < t[1]) { _.label = t[1]; t = op; break; }
                    if (t && _.label < t[2]) { _.label = t[2]; _.ops.push(op); break; }
                    if (t[2]) _.ops.pop();
                    _.trys.pop(); continue;
            }
            op = body.call(thisArg, _);
        } catch (e) { op = [6, e]; y = 0; } finally { f = t = 0; }
        if (op[0] & 5) throw op[1]; return { value: op[0] ? op[1] : void 0, done: true };
    }
};
var _this = this;
function supportsWebp() {
    return __awaiter(this, void 0, void 0, function () {
        var webpData, blob;
        return __generator(this, function (_a) {
            switch (_a.label) {
                case 0:
                    if (!self.createImageBitmap)
                        return [2 /*return*/, false];
                    webpData = 'data:image/webp;base64,UklGRh4AAABXRUJQVlA4TBEAAAAvAAAAAAfQ//73v/+BiOh/AAA=';
                    return [4 /*yield*/, fetch(webpData).then(function (r) { return r.blob(); })];
                case 1:
                    blob = _a.sent();
                    return [2 /*return*/, createImageBitmap(blob).then(function () { return true; }, function () { return false; })];
            }
        });
    });
}
(function () { return __awaiter(_this, void 0, void 0, function () {
    return __generator(this, function (_a) {
        switch (_a.label) {
            case 0: return [4 /*yield*/, supportsWebp()];
            case 1:
                if (_a.sent()) {
                    console.log('does support');
                }
                else {
                    console.log('does not support');
                }
                return [2 /*return*/];
        }
    });
}); })();

4. Press Save, Preview or Draft.

[dd32]

Hi @distante and welcome to Trac.

I've just tested this, and I'm not experiencing any issues. Getting ERR_CONNECTION_RESET suggests to me that there's a security module on your host in play - mod_security or similar which is blocking the request. Usually mod_security would trigger a 404/403 error, however some network-based blockers may simply drop the connection, which would cause that error message.

I'd suggest contacting your host or trying to reproduce it on another hosting environment to determine if it's host specific.

[distante]

Hi @dd32 thanks for response.

I went to my hosting support regarding this and after first turning off some mod_security options and finally the complete mod itself the error was still there.

I got this response in my final communication:

We have conducted a thorough investigation to find out that it is a WordPress related issue. Having switched off Mod_security, we have tested it to get the same error. Here is the Apache error log entry: Handler for (null) returned invalid result code 70007, referer: ​http://this-is-not-my-domain.com/wp- admin/post-new.php?wp-post-new-reload=true You can share this entry log in your WordPress ticket. It is a common error which cannot be fixed on our side, unfortunately. Also, you can look it up on the internet to find out a lot of similar cases which cannot be resolved. Our best guess is that the script cannot process the request because of some errors within the script itself.

What I do not understand is why did you not got an error in your test.

[Presskopp]

FYI:

Some users have reported that switching to a different MPM addressed the issue.

​https://forums.cpanel.net/threads/ah00524-handler-for-null-returned-invalid-result-code-change-error-log-format.502311/

[distante]

Replying to Presskopp:

FYI:

Some users have reported that switching to a different MPM addressed the issue.

​https://forums.cpanel.net/threads/ah00524-handler-for-null-returned-invalid-result-code-change-error-log-format.502311/

Regarding this. I asked my Host about it and they said:

thank you for getting back to us!

Indeed such error can be caused by the fact that Apache limit set on the server has been reached. That is why we have tried to increase the limit for testing purposes to see if that helps.

To our regret, that action didn't help as well. So, we would suggest double checking the script you are trying to use as most likely there is something wrong with it.

[dd32]

Thanks for asking your host @distante.

Unfortunately, their response doesn't help track down the issue, other than that it's indeed something specific to their hosting environment.

Handler for (null) returned invalid result code 70007

Knowing what the PHP Error was which caused apache to return that would've been more helpful, but I suspect their PHP logs will have not logged an error as it's probably a segfault or other internal PHP failure.

Would you be able to post the following PHP.ini settings from the host? You can either get this directly from the host, or by looking at the output from phpinfo();:

• PHP Version
• pcre.backtrack_limit
• pcre.recursion_limit

[distante]

Hi again @dd32, this is the info:

• PHP Version: 5.6.32
• pcre.backtrack_limit: 1000000 (local and master)
• pcre.recursion_limit: 100000 (local and master)

Thanks for your interest on this topic!

[dd32]

Thanks for that @distante - I was _really_ hoping those values would've been different :)

Unfortunately without further details as to what's causing it, there's not a lot we can do.

It seems highly likely it's related somehow to your hosts PHP installation - perhaps the version of PCRE installed or something else.

[azaozz]

Also tested this and don't see any problems posting the example on both a test install and a "real" site. Another test you can try is to post the example in a comment. Comments are processed slightly differently than posts when saving, it may show if this is "content filtering" related.

Closing as worksforme for now, feel free to reopen with more details that would help to reproduce the error.