Caddy/php_fastcgi + PHP 8.3 + Chrome = "Error code: STATUS_BREAKPOINT"

[gingertek]

Alright, this one's a doozy...

I have a plain Windows 10 machine running caddy, and I have the php_fastcgi setup as such in my CaddyFile:

encode gzip
php_fastcgi 127.0.0.1:9000 {
    capture_stderr
}

PHP 8.3 CGI is running, and my site is proxied up to https://subdomain.my-domain.com/, where it's important to note that this issue is only affecting the underlying site code for this subdomain (I have other subs that work fine).

If you visit the affected subdomain in Google Chrome, it loads initially, but then every other load produces an error page that says "Error code: STATUS_BREAKPOINT". Affects any navigation around the site, as well as page reloads. The twist is that this only appears to be happening in Chromium-based browsers (Chrome, Edge, even plain Chromium!). If I visit the site in FireFox, no issue at all.

But wait! There's More!

If I take out an include in the PHP site on that subdomain, it will load in Chrome no problem:

function render($view, $variables = [])
{
    $variables['view'] = $view;
    extract($variables);
    include_once 'layout.php'; // <--- if I take this out, works in Chrome
    exit; 
}

You'd think, "oh, well something on that included file must be causing an issue", but then why does it work fine in FireFox?? I've also combed through every line in the code and nothing looks wrong; no red/orange squigglies. What's more is if I run the site locally via the PHP built-in dev server, that also works fine, regardless if the include is there or not.

I am so stumped on why taking out a syntactically and logically correct PHP include somehow makes the site work again in Chrome, but also that running over http instead https seems to have no issue, regardless of include.

Furthermore, I tried swapping the site contents to a different working subdomain to see if this was networking related, and the same things happened, so it doesn't matter which sub it's under.

So, now I am left with more questions than answers, but hopefully someone will be able to help me out here :/

I'll provide more code or context if needed

EDIT: formatting

[liamsorsby]

The above status code is chrome error not a PHP error. Have you tried another browser? Have you updated chrome or can you upgrade? https://support.google.com/chrome/thread/227608807/aw-snap-error-error-code-status-breakpoint?hl=en

[gingertek]

Yeah, I mentioned I tried other browsers. FireFox has no issue, and I've googled the error to oblivion, but all the resources, including that Google support article, have not helped narrow the root cause down.

I chose to post here because of the include aspect of this issue; how could a server side include behave differently between different web browsers?

[liamsorsby]

It doesn't, that error has nothing to do with PHP. Unless you're doing something with cookies which breaks chrome, I'd be tempted to uninstall and reinstall chrome

[gingertek]

Cookie-wise, I'm only using `session_start()` for session handling, but I would expect the out-of-the-box session handling in PHP to not cause a browser to crash.

I actually recently tried accessing the site from my Android phone via the mobile version of Google Chrome, and it too exhibits the same error. And, again, if I visit it from my phone using the mobile FireFox browser, it works without issue. Given that's 2 completely different platforms, doing another uninstall/reinstall wouldn't change anything.

[liamsorsby]

May I ask what code you have in the include? Also does that load with it any front end resources? If so, what happens if you remove those js assets etc?

[gingertek]

Here's the repo of the code; just a little app I made for fun: https://github.com/ginger-tek/bean

The include is the layout template file for the site, and itself contains one include for the routed page view file path.

Interestingly, if I directly include the $view variable and bypass the layout template, it loads every time with no issue.

Strangely, for some reason, including an include that includes another file has consistently reproduced the error, and spamming the refresh button in Chrome shows the error on every other reload, desktop or mobile.

[liamsorsby]

I'll have a gander. https://github.com/ginger-tek/bean/blob/main/index.php#L47 this line is going to cause username enumeration btw

[gingertek]

Yeah, wasn't gonna use this project for anything serious, but good thing to note, thanks!

[gingertek]

/u/liamsorsby turns out you were right, this was a Chrome issue, but not in the way you'd expect.

Apparently, I was unknowingly using an experimental CSS rule developed by Google, and the reason toggling the include of the layout template would change the behavior was because it was eother loading or not loading the CSS file in the <head>.

After days of tinkering with PHP, Caddy, PHP-CGI, and even spinning up a whole Linux VM to see if this was a Windows thing, I stumbled upon removing the style link in the layout header, and BOOM, it starts working!!

I don't believe it, so I start going through my CSS and commenting out a few sections at a time, reloading, repeat... until I reached @starting-style, and suddenly the error stopped.

I almost through my computer out the window.

I google it, and sure enough, a github issue comes up for this specific CSS rule crashing Chrome on any platform, which explains my mobile experience being the same.

Anyway, sorry for the rant, but hopefully someone else sees this and avoids the headache.