Similar to how it is done in lines 337-341

This conditionif not line: isn't captured inparse_headers call.
Additional check of _MAXHEADERS is verified.
So, this isn't a strict 1:1 replacement.

We can add theif not line condition in _reader_headers method for equivalence.

However, given that _tunnel method already prints headers in line 960 inprint('header:', line.decode()), I am trying to understand, what additional benefit this patch brings

The discussion in#69152 seems adding additional states to the _tunnel method, and adding debug response to those states.

@orsenthil, thanks for the review!
Regarding conditionif not line. It seems to me that this is now a useless part of the code. Because the only variant of the line value in which this condition will be true, if I'm not mistaken, isline = b" (because the methodreadline can't returnNone or just an empty string). And for the equality of line to the value of b'', we check a little below.

I looked at the history, these lines wereadded when there was no equality check for the empty binary object below. That is, at some point they made sense, but after thiscommit, they ceased to be necessary.

But we can add this check to the _read_headers method as a precaution. Do you think it should be done?

2. As for the benefits of the changes being made. Firstly, headers are needed in the situations described in the commentAdd tunnel CONNECT response headers to httplib / http.client #69152 (comment). And secondly, now headers gets into the debug-logs only if we were able to go beyond this line:https://github.com/python/cpython/blob/main/Lib/http/client.py#L948.
   But if we did not pass the authorization headers we need, then we will get an OSError without information about what happened, we will not be able to find out what authentication data is required. With my PR, I would like to take the first step towards solving the problems described hereAdd support for digest authentication with an HTTP proxy psf/requests#2526,Allow custom authentication (in particular NTLM) to proxies psf/requests#1582,http proxy negotiate/gssapi authentication? requests/requests-kerberos#83

Maybe then it would be possible to start returning not OSError, but some custom error that can be catched in the library code (urllib3, requests) and automatically prepare data for authentication based on the information contained in _proxy_response_headers. Similar to how it is done inhttps://github.com/requests/requests-kerberos/pull/149/files.

Maybe you know ways to solve these problems in a different way, I will be glad of any ideas and suggestions.
How@vadmium's proposal will solve the problem of the lack of any information about what went wrong when creating the tunnel, I did not understand.

This always does complicated parsing of the data despite these headers not being used in 99.999% of use cases.

It'd be better to just call _read_headers(response.fp) and store that raw data privately, and add aget_proxy_response_headers() public method that triggers the parsing into data structures.

The debuglevel > 0 print loop should just loop over the raw unparsed headers.