Demian Brecht added the comment:
This doesn't seem to be an issue in 3.4+, the following headers are injected in
a call to urlopen():
GET / HTTP/1.1
Accept-Encoding: identity
Host: example.com
User-Agent: Python-urllib/3.4
Connection: close
However, this is not the same behaviour in 2.7:
GET
karl added the comment:
What was the content of http://support.github.com/discussions/site/1510
I can't find it. Is the issue still going on?
--
nosy: +karlcow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8732
Changes by Éric Araujo mer...@netwok.org:
--
nosy: +eric.araujo
versions: -Python 2.6
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8732
___
___
Dave Abrahams d...@boostpro.com added the comment:
How many tests did you run? My two tests were minutes apart. I have the
feeling that this has something to do with cacheing behavior on the server.
--
___
Python tracker rep...@bugs.python.org
Senthil Kumaran orsent...@gmail.com added the comment:
HTTP Ref says that Server can send any encoding, if client does not
specify Accept-Encoding header. But if 'identity' is one of the
encoding that server recognizes (?), then it should send it as
identity, which indicates untransformed
New submission from Dave Abrahams d...@boostpro.com:
According to the RFC, the server is allowed to send back any encoding it likes
when no Accept-Encoding header is supplied, but all the examples I can find of
urllib2.urlopen usage assume they're getting plain text back. I think it would
be
