Confirmed on my Win7/x64 box with PHP 5.3.5 (XAMPP).

So this is a PHP bug? What can we do about it?

beta wrote:

My another Windows Server 2008 R2 with PHP 5.3.2 and older version of MediaWiki (r70253) is OK for long external link.

We certainly can do something about this, since we introduced it in r84022.

happy.melon.wiki wrote:

Is 313 characters a hard limit, or does it depend on the resources available to PHP?

This rev should probably be reverted until it's fixed, as it's a trivial DOS vector.

beta wrote:

The magic number "313" is what I observed from my Windows Server 2008 R2 + PHP 5.3.6 + MW 1.19alpha (r89086),
Maybe Max Semenik can prove or disprove this on his environment :)

beta wrote:

Thanks for your quick response in r89088.

Should we add a test case for long external link string to prevent this issue from regression?

(In reply to comment #7)

Should we add a test case for long external link string to prevent this issue
from regression?

I'm not sure a test case would help since this appears to be a problem that should be reported to PHP developers. In fact, I wonder if this might be caused by XAMMP instead of PHP since I'm running PHP 5.3.5-1ubuntu7.2 at MW r89000 and it works.

Also, trying with PHP 5.3.6 under Fedora with MW 89000 shows no problems.

Will now try WAMP and XAMP.

I don't think we can add a test case for it. It will probably pass in command
line.
These errors depend on the stack size of httpd.exe.

bugs.php.net would tell you to run link.exe to modify its header or to decrease
pcre.backtrack_limit and pcre.recursion_limit.

Mark, to make that fail in Linux you would need to restrict the stack size with ulimit.

Using (?:[^\]\[<>"\x00-\x20\x7F]+|\[\])+) instead of (?:[^\]\[<>"\x00-\x20\x7F]|\[\])+) is probably cheaper. Can you test?

The point where it errors for me with a 64bit php (and a test script) is with ulimit -s515 at doMagicLinks (the preg_split passes), where as with the old regex, it worked up to ulimit -s42.

With the modification proposed at comment 10, it runs again until -s44.

Note that these tests are specific to the provided url testcase, and that with the same borderline settings, it may sometimes works and sometimes fails.

happy.melon.wiki wrote:

That's still pretty close to recovering the original performance (-s isn't logarithmic or anything, is it?)

ulimit -s sets the stack size in kb.
The problem was in the regex which we made mucho more complex, and is itself included into another big regex.

happy.melon.wiki wrote:

Indeed; but you seem to have found an optimisation which produces the same functionality for ony a 5% memory footprint penalty, as opposed to the 1125% penalty in the original version. Is that good enough performance to put it back in?

Does this mean it's possible to crash *any* server with a long enough URL?

Bryan.TongMinh wrote:

Does not occur on IIS with PHP 5.3.4 (cgi-fcgi).

It is unlikely to occur with cgi/fastcgi, since in that case it uses the stack set in php binary.

10 years later, is this still an issue in more recent software versions of involved software pieces?