Re-fix parsing of legacy url_rewrite_program responses

[rousskov]

Legacy helper responses start with a URL instead of OK rewrite_url=...
and such. 2016 commit ddc77a2 introduced two bugs when handling legacy
responses:

• Response parsing code triggered MemBuf assertions when 0-terminating
  the parsing buffer for certain URLs. The bug affected legacy helper
  responses with and without space characters.

• Squid code attempted to accept/use helper-returned URLs with embedded
  space character(s), despite a WARNING implying that the post-space
  characters are not going to become a part of the new URL.

---

This change resurrects recent commit bb854bb that was accidentally
reverted by commit ec328cf during pull request merging by Anubis.

[rousskov]

⚠️ Until the staging bug is fixed, please do not clear more than one concurrent PR for merging and do not clear any master PR that is based on a stale master branch (i.e. merge the latest master into PR branch before clearing that PR).

FWIW, I looked through master commits cbbe8d3..562f2ef and did not find any other problematic commits. Hopefully, @eduard-bagdasaryan's investigation confirms that this is a very recent problem.

[yadij]

This would not happen if we used a proper merge queue instead of a separate auto branch pushed over top of master by an external tool.

[yadij]

Also, please report to the board how this bug got into Anubis in the first place?
The entire purpose of the bot is to test changes on the relevant branch HEAD before a change is committed. That is a serial operation, it MUST NOT be parallelized, nor old HEAD allowed to be used as base.

[rousskov]

Amos: This would not happen if we used a proper merge queue

The above assertion is false -- it did happen. For example, according to Phil Vendola, on April 23, 2026 "GitHub's merge queue started silently reverting code on customers' main branches ... No error. No conflict. No warning. Just clean, green merges that happened to delete other people's work."

Phil's explanation of that alleged GitHub bug appears to be very similar to the effects recent GitHub changes had on Anubis. I would not be surprised if GitHub developers themselves were bitten by the same GitHub-injected problem that bit Anubis!

Also, please report to the board how this bug got into Anubis in the first place?

In short, GitHub silently stopped updating its PR merge branches, and Anubis did not have enough "GitHub PR merge branch is still valid" checks to catch that change in GitHub behavior. Eduard worked through the weekend and added the missing checks now. AFAICT, this bug predates Anubis. I apologize for missing it when importing code from another open source project in 2017. Technical details are available at measurement-factory/anubis@c2ded1e

With the staged commit safety concerns addressed, we are now investigating what it would take to entice GitHub to update its PR merge branches. I speculate that, with the increased (agentic) load, it is unlikely that GitHub is going to resume performing automatic updates in many relevant cases. Needless to say, we would prefer to trigger them automatically rather than rely on developers merging master into their PR branches.

[kinkie]

Amos: This would not happen if we used a proper merge queue

[...]

Phil's explanation of that alleged GitHub bug appears to be very similar to the effects recent GitHub changes had on Anubis. I would not be surprised if GitHub developers themselves were bitten by the same GitHub-injected problem that bit Anubis!

[...]
Thanks for the explanation. I'm sorry Eduard had to work overtime to figure out what had happened.
Hopefully Github will be more careful with introducing similar changes - or even still, not introducing them at all