[issue22233] http.client splits headers on non-\r\n characters

Martin Panter added the comment: Your modifications look sensible David; thanks for handling this. -- ___ Python tracker ___

[issue22233] http.client splits headers on non-\r\n characters

R. David Murray added the comment: I want to stack another patch on top of this, so I committed it. If you see anything I screwed up, Martin, please let me know. -- resolution: -> fixed stage: commit review -> resolved status: open -> closed ___

[issue22233] http.client splits headers on non-\r\n characters

Roundup Robot added the comment: New changeset 69900c5992c5 by R David Murray in branch '3.5': #22233: Only split headers on \r and/or \n, per email RFCs. https://hg.python.org/cpython/rev/69900c5992c5 New changeset 4d2369b901be by R David Murray in branch 'default': Merge: #22233: Only split

[issue22233] http.client splits headers on non-\r\n characters

Changes by R. David Murray : Removed file: http://bugs.python.org/file1/crlf-headers2.patch ___ Python tracker ___

[issue22233] http.client splits headers on non-\r\n characters

Changes by R. David Murray : Added file: http://bugs.python.org/file2/crlf-headers2.patch ___ Python tracker ___

[issue22233] http.client splits headers on non-\r\n characters

Changes by R. David Murray : -- stage: patch review -> commit review ___ Python tracker ___

[issue22233] http.client splits headers on non-\r\n characters

R. David Murray added the comment: This looks good to me. However, although it is by no means obvious, the tests in test_parser are supposed to be for the new policies. When I changed the test to test them another place that needed to fixed was revealed. I've updated the patch accordingly.

[issue22233] http.client splits headers on non-\r\n characters

R. David Murray added the comment: I'm hoping to take a look at all of these at the core sprint next week. -- ___ Python tracker ___

[issue22233] http.client splits headers on non-\r\n characters

Changes by Doug Hellmann : -- nosy: +doughellmann ___ Python tracker ___ ___

[issue22233] http.client splits headers on non-\r\n characters

Martin Panter added the comment: If someone reviews my patch and thinks it is fine, I might commit it. Maybe I can just re-review it myself, now that I have forgotten all the details :) If messing with the email package is a problem (performance, or compatibility), another option is to keep

[issue22233] http.client splits headers on non-\r\n characters

Clay Gerrard added the comment: BUMP. ;) This issue was recently raised as one blocker to OpenStack Object Storage (Swift) finishing our port to python3 (we're hoping to finish adding support >=3.5 by Spring '17 - /me crosses fingers). I wonder if someone might confirm or deny the attached

[issue22233] http.client splits headers on non-\r\n characters

R. David Murray added the comment: I agree. Can you update the email issue with this suggestion and/or a patch? The problem with this, of course is backward compatibility, but since it is more correct per the RFCs, our past policy has been to fix it anyway. --

[issue22233] http.client splits headers on non-\r\n characters

Martin Panter added the comment: David: what is the email issue you mentioned? In the mean time, I am uploading a patch to this issue. It seems using StringIO is a bit slower than str.splitlines(). I found a way to optimize building long lines, which compensated a lot of the loss, but this

[issue22233] http.client splits headers on non-\r\n characters

Martin Panter added the comment: For the record, this is a simplified version of the original scenario, showing the low-level HTTP protocol: >>> request = ( ... b"GET /%C4%85 HTTP/1.1\r\n" ... b"Host: graph.facebook.com\r\n" ... b"\r\n" ... ) >>> s =

[issue22233] http.client splits headers on non-\r\n characters

Gregory P. Smith added the comment: The obvious fix seems to be to not use splitlines but explicitly split on the allowed characters for ASCII based protocols and formats that only want \r and \n to be considered. I don't think we can rightfully change the unicode splitlines behavior.