Hi Ben,
Regarding this point, we've discussed with Christopher and considered
that given that the chunk extensions are not supposed to be used, and
that if used, they're even less supposed to contain mismatched quotes,
the likelihood of breaking existing setups is ultra-low, so we agreed
to integrate the extra check in the next version (3.4). However, given
that this version will be an LTS one and we do not accept functional
regressions between a stable and the following LTS (in order to permit
seamless upgrades to LTS), we'll backport it to the current 3.3 stable.
As applications are basically inexistent, the risk of regression is
super low, and it will offer several months of exposure to users before
they finally upgrade to 3.4.
We think that this is the best trade-off, which allows to strengthen
existing setups (i.e. do our reasonable share of effort to protect
infrastructures involving possibly non-compliant parsers) while keeping
the risk of breakage as close as possible to zero.
The commit in question is: 35d63cc3c7 ("MEDIUM: h1: strictly verify
quoting in chunk extensions"). I've CCed you and Rajat in it so that
if any breakage were to be reported, we would all stay informed and
could analyze the situation.
I've done my best to also deal with CTLs on the line (including NUL
but not HT) and check for mismatched quotes and backslashes. While
refining it, I figured that the code starts to be complex, and that
I wouldn't be surprised if you found more non-compliant variants
that choke on NUL inside the extension (even inside quotes), or a
sequence such as backslash CR CR LF which some might interprete as a
backslashed CR followed by CRLF, and others as a double CR followed
by LF. Similarly we could imagine that <quote> backslash CR <quote>
CR LF could be mistaken for a double CRLF by implementations only
checking for the CR and skipping the next char assuming an LF while
here it would only be a quote. I'm just suggesting some ideas, as
I know that you love playing with that :-)
Cheers,
Willy
