Re-fix parsing of legacy url_rewrite_program responses#2446
Conversation
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 commit resurrects recent commit bb854bb that was accidentally reverted by commit ec328cf during pull request merging by Anubis.
01ae3bb to
730e21c
Compare
|
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. |
|
This would not happen if we used a proper merge queue instead of a separate |
|
Also, please report to the board how this bug got into Anubis in the first place? |
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.