I wonder if maintaining support for the builtin webserver is worthwhile -- I never use it, and I feel like I only see it referenced when users report bugs like this in the vein of "PHP builtin webserver has been completely broken for 13 years", which suggests it's probably not seeing very much use in the wild, either.

A possible argument in support of the builtin webserver is that Apache was very difficult to get working with PHP extensions about a year and a half ago (T13232). I'm not sure if this is still true or not.

Maybe a half-step in this direction would be to fix whatever the root issue is here, but also move the documentation somewhere deep into the "Advanced Developer Stuff" part of the documentation.

In the Discourse thread, the first user appears to be running on Windows, so I suspect their efforts will fail whether the webserver works or not:

D:\OutilsPHP\php\php-7.3.10-nts-Win32-VC15-x64\php.exe -S phabricator-dev.some-company.com:80 -t ...

The second user isn't on Windows, so their use case may be less ill-fated, but I'm still not sure if there's a good reason to choose the builtin server over Apache.

Both reference PHPStorm, so maybe there's some shared root cause like "PHPStorm's XYZ integration is easy with the builtin webserver and hard/nonexistent with Apache".

Yeah, it might make sense to drop it; I use it because it's easier to setup then Apache and the error log is right in my console, but setting up a real server isn't that much of a bother, except for Apple changing the rugs on you every other day (Soon with both x86 and ARM versions!)

For what it's worth, the only reason I was trying to figure out stuff with the built-in server was because at the time trying to get Phabricator running in Docker correctly was... not nearly as easy as I would have liked. Quickly skimming online suggests that's improved in the interim.

Guess I should probably add M1 to the remarkup blocklist now.

In T13575#254280, @epriestley wrote:

I added M1, etc., to the ignored list in D21507.

...and updated the config on secure, which customizes this list slightly.

I'm not completely thrilled about maintaining PHP builtin webserver support...

A major issue here is that the webserver has a single execution thread and can only handle one request at a time. This makes the self-request setup check hang until it hits a timeout and get skipped, and effectively breaks all clustering behavior (which relies on making Conduit requests to the server).

You can work around this (so far, at least) by running two copies of the webserver on different ports (for example, web on 80 and repo-web on 8000) and registering the second server in Almanac. But this is increasingly ridiculous, and only even worth considering because of the mess with Apache, PHP, code signing, Homebrew, and M1 on Big Sur, etc.