The complex ops backend expects inner query strings to be URL encoded so that they may contain "unsafe" characters. If an inner query string contains any of the characters used by complex ops ()~|& and it is not URL encoded, then parsing on the backend could break.
The backend should already function as expected, but tests should be added to prevent a regression. Should test both expected/malformed examples.
Also, need to check if there are cases where encoding the inner query string is optional when safe. e.g., is (a=1&b=2) & (c=3&d=4) safe? The inner querystring uses operators that the regex parses, but given that they're wrapped by parens, it should be fine?
The complex ops backend expects inner query strings to be URL encoded so that they may contain "unsafe" characters. If an inner query string contains any of the characters used by complex ops
()~|&and it is not URL encoded, then parsing on the backend could break.Here's an "unsafe" example:
(a=b) | (c=d())Correct encoding would roughly look like:
(a=b) | (c=d())(raw)(a%3Db) | (c%3Dd%28%29)(inner encoded)%28a%253Db%29%20%7C%20%28c%253Dd%2528%2529%29(outer encoded)Improper encoding in a single step would look like:
(a=b) | (c=d())(raw)%28a%3Db%29%20%7C%20%28c%3Dd%28%29%29(outer encoded)The backend should already function as expected, but tests should be added to prevent a regression. Should test both expected/malformed examples.
Also, need to check if there are cases where encoding the inner query string is optional when safe. e.g., is
(a=1&b=2) & (c=3&d=4)safe? The inner querystring uses operators that the regex parses, but given that they're wrapped by parens, it should be fine?