>Weird... I think I *might* have tried to insert a weblink, or at least type something that might have looked like one, but I certainly wasn't dumb enough to format it like a full HTML anchor

It is triggered by "href", not full-blown anchor, in addition to common signs of URLs. For a time being, this is a necessary measure. Working two-stage posting with captcha into the current codebase would be damn painful and is just not worth it. However, we have smarter spam checks in mind, just not yet ready to give them a try.

>I guess the server can't really take the liberty of assuming (...) that it's even actually the same machine (...)

>Would there be any way to address it as a QoS issue or the like, though?

No. QoS is inapplicable. QoS and traffic shaping kick into action when the networking node is experiencing congestion. Without congestion, QoS is either off as it should be, or doing meaningless work rearranging packets for no reason. And even with a full-blown packet reordering firewall, we (1) cannot reliably associate several concurrent HTTP sessions with a single client as you've pointed out, and (2) even if we could (using nonces, for instance), it would in fact be mostly useless and just create a good deal of overhead on our part.

>the HTML is a fairly meaty 258kb, the collected JS and CSS another 20kb

The math is wrong, divide that by 4 or 5 due to gzip content encoding. To address the issue, I will try to tune TCP_CORK and output buffers of PHP to give out generated HTML as a single chunk, or several large ones, to try and feed text content to browsers in one take.

>Is there a way to get the aforementioned autosageing thread restored to normal life in that case, or does the post limit remain, with it simply saved from being deleted by falling off the bottom of the threadlist quite as early?

Sure there is. Generally, if you feel some thread is dying prematurely, drop a line here, and I'll check and possibly revive it.