OK, this was a subtle and unintended semantic change for parse_response_start_line. The regex used when parsing request start lines was anchored with ^$ so the change to fullmatch was a no-op, but response start lines were more lenient and allowed a trailing CRLF (and in fact more than that - they'd allow a trailing CR followed by any garbage).

The requirements of these functions were never documented precisely, but as used in Tornado the trailing CRLF is never included, and the one example in the docstring didn't have it.

In general, I'm trying to remove ambiguity in this code, moving away from parsing functions that optionally allow trailing CRLF to document and enforce that CRLFs are handled exactly once (in RFC 9112, the CRLF is not a part of the status-line production, it's a part of the higher-level HTTP-message production). So if we make a change here it would be temporary: restore backwards compatibility with 6.4 by allowing trailing CR or CRLF (I think it's safe to reject "CR+garbage"), but this is deprecated and will be removed again in 7.0.

Is such a temporary change worth it? I've not heard of anyone besides Salt depending on these functions outside of Tornado (I wasn't aware of Salt's usage before this PR). Unless there's something about the way Salt is deployed that makes it difficult to deploy the one-line patch of openSUSE/salt@0786d7a (while old versions of salt are still somehow exposed to new versions of Tornado), we could do this, but I think it might be better to handle it on the Salt side.

So if I understand you correctly, you believe that it's correct that _ABNF.status_line rejects headers with CRLF (since they are a higher-level concept and should be removed before they reach this funciton), and that fixing this here would get removed in 7.x anyway.

In general, personally, I don't mind breaking the backwards compatibility here (I'll be backporting the change to saltstack/salt so Salt should be fine).

Ideally though, this would be added to the release notes, so that others don't have to spend the time debugging why their code doesn't work. Perhaps we can document this in the docstring of the function as well.

Your understanding is correct. I'm fine with retroactively updating the release notes and docstring to make this explicit.