No parsing of headers after malformed HTTP/1.1 header (e.g. space). It looks like this can only happen in HTTP/1.1?
See RFC 7230 page 23 and § 3.2.4 that field-name : value is not valid. Based on the related bugs, it seems at least possible to setup an invalid HTTP header in Microsoft IIS (2/3 cases are IIS).
@baknu noticed that :fox_face: Firefox won't show these invalid headers in the Network tab in the Response Headers, even in 'Raw' view.
The problem is an upstream :bug: bug in Python http.client which is used by Requests:
The last 5 lines will be shown in curl, but won't be available in Requests / http.client (of course the other issue here is in the CSP, default-scr should be default-src).
No parsing of headers after malformed HTTP/1.1 header (e.g. space). It looks like this can only happen in HTTP/1.1?
See RFC 7230 page 23 and § 3.2.4 that
field-name : value
is not valid. Based on the related bugs, it seems at least possible to setup an invalid HTTP header in Microsoft IIS (2/3 cases are IIS). @baknu noticed that :fox_face: Firefox won't show these invalid headers in the Network tab in the Response Headers, even in 'Raw' view.The problem is an upstream :bug: bug in Python http.client which is used by Requests:
Related Requests :bug: bugs:
Related issues:
1259
Example https-client.py (used with
$ python https-client.py target.host
):Example curl (with a similar TLS ClientHello):
Doing a diff (skipping the Response line with
| tail -n+2
) results in:The last 5 lines will be shown in curl, but won't be available in Requests / http.client (of course the other issue here is in the CSP, default-scr should be default-src).