Improve parse_options_header performance when parsing long unterminated quoted value. fixes #2904
In #2614, I split up the giant regex that was previously used into a few smaller parts. However, the "(?:\\\\|\\"|.)*?" regex I came up with to parse quoted values was still susceptible to backtracking performance issues with strings like '"' + "\\" * 100.
This reduces the complexity of the regex even further. A regex is used to match token keys and values. If the value starts with a quote, a loop is used to scan characters, skipping escaped slashes and quotes, until a closing quote is found.
Previously, we were matching the invalid value a="c:\\" as c:\. I couldn't figure out a good reason for this, it seems like it was discussed in #1628 as a behavior in some old browsers which didn't happen anymore. Perhaps it just happened to work with the first refactor, and I left it in? If it does come up, the loop can be modified to handle it if there's still a good reason to.
Improve
parse_options_headerperformance when parsing long unterminated quoted value. fixes #2904In #2614, I split up the giant regex that was previously used into a few smaller parts. However, the
"(?:\\\\|\\"|.)*?"regex I came up with to parse quoted values was still susceptible to backtracking performance issues with strings like'"' + "\\" * 100.This reduces the complexity of the regex even further. A regex is used to match token keys and values. If the value starts with a quote, a loop is used to scan characters, skipping escaped slashes and quotes, until a closing quote is found.
Previously, we were matching the invalid value
a="c:\\"asc:\. I couldn't figure out a good reason for this, it seems like it was discussed in #1628 as a behavior in some old browsers which didn't happen anymore. Perhaps it just happened to work with the first refactor, and I left it in? If it does come up, the loop can be modified to handle it if there's still a good reason to.