Shin Dong-won added the comment:
Yeah, this is server's fault and python does not have to deal with non-standard
cases. I'll close this issue. Thanks!
--
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bug
Shin Dong-won added the comment:
I had a mistake. That's not CRLF but just two '\n'.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Shin Dong-won added the comment:
I found that Python3 no more uses header format from rfc822, and the data
b'P3P : CP="ALL CURa ADMa DEVa TAIa OUR BUS IND PHY ONL UNI PUR FIN COM NAV INT
DEM CNT STA POL HEA PRE LOC OTC"\r\n'
not match with `headerRE = re.compile(r'^(From |[\041-\07
Shin Dong-won added the comment:
b'Date: Tue, 03 Nov 2015 10:05:42 GMT\nServer: Apache/2.2.20 (Unix)
mod_ssl/2.2.20 OpenSSL/0.9.8e-fips-rhel5 DAV/2\n PHP/5.2.16
mod_fastcgi/2.4.6\nX-Powered-By: PHP/5.2.16\nP3P: CP="NOI CURa ADMa DEVa TAIa
OUR DELa BUS IND PHY ONL UNI COM NAV INT DEM\n P
Shin Dong-won added the comment:
I think so but same http request works well in Python2
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Shin Dong-won added the comment:
I monkey patched the method `parse_headers` to print what the fp read and
finally arrived at that http.client is not a problem.
email.parser.Parser.parsestr adds two '\n' between two lines of "P3P: ~~".
end: b'POST /bbs/login_check.php HTTP/1
