使用Python请求的重定向错误过多

本文介绍了使用Python请求的重定向错误过多的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

HTTP请求在我的本地主机上运行良好，但是使用服务器上的python请求库运行相同的HTTP请求会返回"Too Many Redirects"错误

HTTP requests are working fine on my localhost, but running the same HTTP requests using the python requests library on my server returns a "Too Many Redirects" error

当我输入

localhost/terminal/jfk

在浏览器中，我得到了预期的json字典.

in a browser, I get a json dictionary as expected.

但是，当我使用服务器上的python请求库在python中运行以下命令时

However, when I run the following in python using the python requests library on my server

requests.get('splitmyri.de/terminal/jfk')

我从请求模块收到重定向过多"错误.

I receive a "Too Many Redirects" error from the requests module.

关于导致错误的原因有何想法?还是建议缩小潜在原因?

Any thoughts as to what's causing the error? Or recommendations for narrowing potential causes?

推荐答案

阿莎，

在您回答这确实是您的网站之后，我检查了为什么我得到了一个空的GoDaddy页面.问题是您的splitmyri.de的DNS条目返回了两个不同的A记录...

After you responded that this really is your site, I checked out why I was getting an empty GoDaddy page. The problem is that your DNS entry for splitmyri.de is returning two different A records...

使用107.10.141.119 分析结果:我的/etc/hosts 文件中的硬编码 107.10.141.119 splitmyri.de 使我可以查询107.10.141.119，该查询在中返回这是我的网站"> index.html (然后我检查了 splitmyri.de/terminal/并得到了一个空的json哈希，具有mime类型= [application/json]).检查此地址的反向条目将返回一个Amazon AWS主机(我期望用于真实网页的那种条目).现在您上面的代码可以按预期工作...

Analyzing results, using 107.10.141.119: Hard coding 107.10.141.119 splitmyri.de in my /etc/hosts file allowed me to make queries to 107.10.141.119, which returns "this is my site" in index.html (then I checked splitmyri.de/terminal/ and got an empty json hash, with a mime type=[application/json]). Checking the reverse entry for this address returns an Amazon AWS host (the kind of entry I expect for a real web page). Now your code above works as expected...

[mpenning@Bucksnort ~]$ python Python 2.5.2 (r252:60911, Jan 24 2010, 14:53:14) [GCC 4.3.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import requests >>> requests.get('splitmyri.de/terminal/') <Response [200]> >>> requests.get('splitmyri.de/terminal/').content u'{}' >>> # requests.get('splitmyri.de/terminal/jfk').content returns a huge json hash

使用68.178.232.100分析结果:对68.178.232.100的查询执行相同的钻取操作将获得一个空的GoDaddy页面.对这个地址进行反向映射会发现一个驻留域的典型条目.如您在尝试中看到的那样，在此处发送请求会返回 TooManyRedirects ...

[mpenning@Bucksnort ~]$ python Python 2.5.2 (r252:60911, Jan 24 2010, 14:53:14) [GCC 4.3.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import requests >>> foo = requests.get('splitmyri.de/terminal/jfk') Traceback (most recent call last): File "<stdin>", line 1, in <module> File "build/bdist.linux-i686/egg/requests/api.py", line 50, in get File "build/bdist.linux-i686/egg/requests/api.py", line 37, in request File "build/bdist.linux-i686/egg/requests/sessions.py", line 170, in request File "build/bdist.linux-i686/egg/requests/models.py", line 383, in send File "build/bdist.linux-i686/egg/requests/models.py", line 210, in _build_response requests.exceptions.TooManyRedirects >>>

解决方案:修复您的DNS，以splitmyri.de(删除68.178.232.100的A记录)，一切都会很好.

SOLUTION: Fix your DNS for splitmyri.de (removing the A record for 68.178.232.100) and all will be good.

包括以下DNS信息以供参考...

Including the DNS info below as an FYI...

[mpenning@Bucksnort ~]$ dig splitmyri.de ; <<>> DiG 9.6-ESV-R4 <<>> splitmyri.de ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54051 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 4 ;; QUESTION SECTION: ;splitmyri.de. IN A ;; ANSWER SECTION: splitmyri.de. 3193 IN A 68.178.232.100 splitmyri.de. 3193 IN A 107.20.141.119 ;; AUTHORITY SECTION: splitmyri.de. 3193 IN NS ns49.domaincontrol. splitmyri.de. 3193 IN NS ns50.domaincontrol. ;; ADDITIONAL SECTION: ns49.domaincontrol. 3193 IN A 216.69.185.25 ns49.domaincontrol. 3193 IN AAAA 2607:f208:206::19 ns50.domaincontrol. 3193 IN A 208.109.255.25 ns50.domaincontrol. 3193 IN AAAA 2607:f208:302::19 ;; Query time: 1 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Oct 26 05:14:51 2011 ;; MSG SIZE rcvd: 205 [mpenning@Bucksnort ~]$ [mpenning@Bucksnort ~]$ dig -x 107.20.141.119 ; <<>> DiG 9.6-ESV-R4 <<>> -x 107.20.141.119 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41049 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 6, ADDITIONAL: 6 ;; QUESTION SECTION: ;119.141.20.107.in-addr.arpa. IN PTR ;; ANSWER SECTION: 119.141.20.107.in-addr.arpa. 300 IN PTR ec2-107-20-141-119pute-1.amazonaws. ;; AUTHORITY SECTION: 141.20.107.in-addr.arpa. 900 IN NS pdns1.ultradns. 141.20.107.in-addr.arpa. 900 IN NS pdns2.ultradns. 141.20.107.in-addr.arpa. 900 IN NS pdns3.ultradns. 141.20.107.in-addr.arpa. 900 IN NS pdns5.ultradns.info. 141.20.107.in-addr.arpa. 900 IN NS pdns4.ultradns. 141.20.107.in-addr.arpa. 900 IN NS pdns6.ultradns.co.uk. ;; ADDITIONAL SECTION: pdns1.ultradns. 86400 IN A 204.74.108.1 pdns1.ultradns. 86400 IN AAAA 2001:502:f3ff::1 pdns2.ultradns. 86400 IN A 204.74.109.1 pdns3.ultradns. 86400 IN A 199.7.68.1 pdns4.ultradns. 86400 IN A 199.7.69.1 pdns4.ultradns. 86400 IN AAAA 2001:502:4612::1 ;; Query time: 306 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Oct 26 05:09:47 2011 ;; MSG SIZE rcvd: 392 [mpenning@Bucksnort ~]$ dig -x 68.178.232.100 ; <<>> DiG 9.6-ESV-R4 <<>> -x 68.178.232.100 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38578 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;100.232.178.68.in-addr.arpa. IN PTR ;; ANSWER SECTION: 100.232.178.68.in-addr.arpa. 3600 IN PTR parkwebwin-v01.prod.mesa1.secureserver. ;; AUTHORITY SECTION: 232.178.68.in-addr.arpa. 3600 IN NS cns1.secureserver. 232.178.68.in-addr.arpa. 3600 IN NS cns2.secureserver. ;; ADDITIONAL SECTION: cns1.secureserver. 3600 IN A 208.109.255.100 cns2.secureserver. 3600 IN A 216.69.185.100 ;; Query time: 173 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Oct 26 05:12:06 2011 ;; MSG SIZE rcvd: 171 [mpenning@Bucksnort ~]$