Demian Brecht added the comment:
Sorry Alejandro, I should have clarified: The attached patch is for dev, so the
failure you're seeing when attempting to apply the patch against 3.3 is
expected. It effectively does the same thing as explicitly setting the port as
you have already attempted.
At this point, I'm relatively confident that the issue is due to the proxy
server in use. Using your latest code but a local squid proxy, I'm able to get
200 responses with the latest releases of 3.3 and 3.4 as well as against dev.
Do you absolutely need to tunnel? The most common use case for tunnelling is to
use SSL, which doesn't seem to be the case here. Does the following code work
for you? It still uses the proxy server, but without CONNECT.
import http.client, urllib.parse
data = urllib.parse.urlencode({'nombre': 'HERVAS INFANTE ALBERTO'})
headers = {"Content-type": "application/x-www-form-urlencoded"}
conn = http.client.HTTPConnection(proxy_url,8080, source_address=(ip_address,
0))
conn.request("POST", "http://www.telexplorer.es/?zone=namwp",data,headers)
response = conn.getresponse()
print("Test 1: TE - ", response.status, response.reason)
data = response.read()
conn.close()
If the above code doesn't fulfill your requirements, do you know the
vendor/version of the proxy that you're using?
Note to self: 3.3 doesn't respect _tunnel_port when setting the host header for
requests (this was added in 3.4), so CONNECT and subsequent host headers will
appear to be correct as long as the ports match up. The problem 3.4+ is that
rather than ensuring non-None value in set_tunnel, it's done in _tunnel as a
step just before CONNECT. That step is not replicated when the host header is
set in putrequest, which leads to the value of "None" being sent for the port
in the case where the port is not explicitly set in set_tunnel. To me, it makes
the most sense to use _set_hostport in set_tunnel as in the attached patch to
ensure any other use of _tunnel_port can be done without special handling of
None.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue22041>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
