Exceeded maxRedirects with nytimes.com links #76
Comments
dannguyen commented Jul 12, 2016
(Just leaving this here, will investigate a bit later)
Given a New York Times URL such as this:
The request will fail with this error:
Note that nytimes.com has some convoluted server configuration and returns a HTTP code of 303.
. you’ll get the same redirection behavior with cURL:
More heavy HTTP clients, such as whatever wget uses by default, can deal with this, as can libraries such as Python’s Requests. I’m new to Node so I’m not sure what the best-practices route is.
The text was updated successfully, but these errors were encountered:
We are unable to convert the task to an issue at this time. Please try again.
The issue was successfully created but we are unable to update the comment at this time.
dannguyen commented Jul 12, 2016
Ah OK, now I remember what the hack for nytimes.com is: keep the cookies during the redirects. Not sure if setting this option to true is something that has implications for the general use case, so I leave it here FYI:
felipe-augusto commented Oct 10, 2016
+1 for this, having the same issue here
VigneshPT commented Mar 5, 2018
+1 had the same issue for urls of washingtonpost.com. Fixed by setting jar:true
swathik313 commented Mar 26, 2019
nfederico commented Jul 10, 2019
Hi guys I was giving a try to Cheerio trying to scrap some info from: http://www.bna.com.ar/Personas
My Code:
`const request = require(‘request’);
const cheerio = require(‘cheerio’);
But is giving me the following error.
PS C:\Users\Federico\source\repos\Ws> node index
(node:12196) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 pipe listeners added. Use emitter.setMaxListeners() to increase limit
Error: Exceeded maxRedirects. Probably stuck in a redirect loop http://www.bna.com.ar/Error?aspxerrorpath=/Error/ErrorPage
at Redirect.onResponse (C:\Users\Federico\source\repos\Ws\node_modules\request\lib\redirect.js:98:27)
at Request.onRequestResponse (C:\Users\Federico\source\repos\Ws\node_modules\request\request.js:993:22)
at ClientRequest.emit (events.js:198:13)
at HTTPParser.parserOnIncomingClient [as onIncoming] (_http_client.js:556:21)
at HTTPParser.parserOnHeadersComplete (_http_common.js:109:17)
at Socket.socketOnData (_http_client.js:442:20)
at Socket.emit (events.js:198:13)
at addChunk (_stream_readable.js:288:12)
at readableAddChunk (_stream_readable.js:269:11)
at Socket.Readable.push (_stream_readable.js:224:10)
I try adding jar:true but is not working any clue?
Решение ошибок в WordPress. Как устранить ошибку ‘This page redirect Loop’
Данный туториал покажет, как решить ошибку ‘This page redirect Loop ’ в WordPress.
Иногда необходимо перенаправить URL-адрес в одного сайта на другой. Подобные перенаправления URL-адресов (переадресации) могут вызвать 310 ошибку — слишком много переадресаций (Too Many Redirects). В таком случае в браузере вы увидите следующее сообщение – ‘This webpage has a redirect Loop ‘. Современные браузеры прерывают бесконечный цикл переадресаций, чтобы избежать зависания браузера, и из-за этого появляется данная ошибка на сайте:
Эта ошибка может быть вызвана кэшом/файлами cookie браузера или настройками сервера:
Если проблема возникает только на стороне клиента, ее можно решить, удалив файлы cookie браузера. Для этого необходимо очистить кэш и файлы cookie:
Google Chrome: перейдите в меню Настройки> Приватность> Настройки содержания страницы> Файлы cookie и другие данные с сайтов и плагинов (Setting> Privacy> Clear Browsing Data> Cookies and other browsing data) и очистите кэш и файлы cookie:
Mozilla Firefox: перейдите в меню Инструменты> История> Удалить недавнюю историю> Файлы cookie (Tools> History> Clear recent history> Cookies ) и очистите кэш и файлы cookie:
Закройте браузер и снова перезапустите его. Теперь ваша страница должна открываться без проблем.
Если вы до сих пор видите ошибку после очистки файлов cookie, тогда это проблема сервера. Как альтернативное решение, вы можете открыть URL-адрес вашей страницы через другой браузер. Сама проблема лежит в . htaccess файле, которой должен оставаться чистым и не содержать множества строк с переадресациями. Так или иначе, почистите этот файл. Вы также можете обратиться к вашему хостинг провайдеру и попросить проверить файлы, касательно проблемы переадресаций.
Cloudflare Help Center
Articles in this section
Connect with the Cloudflare Community
More on this topic: Discussions and Tips
Connect with the Cloudflare Community
Troubleshooting redirect loop errors
Resolve redirect loop (too many redirects) errors that prevent visitors from viewing your website.
Overview
The two typical causes of redirect loop errors are:
Browsers typically display error messages when redirect loop errors occur, such as:
Cloudflare SSL options incompatible with your origin web server
The most common cause of redirect loops is due to a combination of
Cause
The Flexible SSL encryption mode in the Cloudflare SSL/TLS app Overview tab encrypts traffic between the browser and the Cloudflare network over HTTPS. However, when the Flexible SSL option is enabled, Cloudflare sends requests to your origin web server unencrypted over HTTP. Redirect loops occur if your origin web server is configured to redirect all HTTP requests to HTTPS when using the Flexible SSL option.
Redirect loops may also occur when using the Full or Full(strict) SSL option. The only difference is that Cloudflare contacts your origin web server over HTTPS and the redirect loop occurs if your origin web server redirects HTTPS requests to HTTP.
Resolution
Resolve redirect loops via one of the following methods:
Page Rule misconfiguration
Cause
Redirect loops also occur if two conflicting Page Rules are configured with Forwarding URL settings. For example, one Page Rule redirects traffic for a.example.com to b.example.com and another page rule redirects traffic for b.example.com to a.example.com.
Resolution
Check the rules in Rules > Page Rules to confirm if you have two rules configured to forward traffic to each other.
Help! I’m Stuck in a Redirect Loop!
Or, it’s not IdentityServer, it’s you.
A common issue with when integrating with an OpenID Provider, such as IdentityServer4, is getting caught in an infinite redirect loop. Typically, this redirect loop will eventually crash your browser tab, or the browser itself.
In Chrome, you’d get the ERR_TOO_MANY_REDIRECTS error message. Or, if you’re issuing cookies to track nonce and states values with each redirect and not cleaning up after yourself (I’m looking at you OWIN/Katana), then you’ll probably get an a 400 Bad Request, with a message of something like “The size of the request headers is too long”.
If you’re using Firefox or Edge, then you’ll see something similar, albeit a bit more cryptic.
What is Causing the Loop?
This redirect loop is a common symptom to a few different errors, and before we look at some common issues and debug steps, let’s take a look at what this redirect loop actually is, and what is causing it.
The high-level process is:
So, if IdentityServer validated the request successfully (i.e., you didn’t get an error response such as unauthorized_client or invalid_request ), then the fault is not with IdentityServer, it’s within the client application. For whatever reason, it is struggling to use the tokens returned by IdentityServer and is getting upset with us.
Debug Steps
Check your Identity Token
The first thing to check is the identity token. Is the payload what you expect? For example, is the intended audience your client id? Is the issuer what you expected? Is the signature valid? Are the datetime values what you expect and valid in the eyes of the client app (check for clock skew)?
Basically, work through the validation steps that your client application is performing against the identity token and see if that’s the reason it is failing.
Is a Cookie Being Set?
Is your client application starting a session?
For example, look for the Set-Cookie response header being issued by your client application. If it’s there, check the next request to see if that same cookie is in the Cookie header.
In the past, I’ve seen applications signal that a session has been created, but then the response didn’t include the Set-Cookie header. So, a cookie was being created but not sent back to the browser. What’s the use in that?! If you’re using ASP.NET 4.x and OWIN/Katana, this was a common issue known as the System.Web Cookie Monster.
Another variation on this is if the Set-Cookie header is sent, but then on the next request, the browser does not set the Cookie header. This could be that the browser did not save the cookie, or if it cannot access the cookie on the next request. My recommendation here is to see if the behavior persists when using the browsers incognito/private mode with no browser extensions enabled. Another culprit can be something in your network stack.
If the cookie is being set and then used but is still not trusted, it might be that the cookie is being truncated. Or maybe you don’t have the correct tools to read the cookie (e.g., the wrong key to unencrypt it).
Or just blame this douchebag.
401 vs. 403
Is your client application returning a 401 Unauthorized instead of a 403 Forbidden? If the user is authenticated but is not allowed to perform the action they are requesting, then you should be returning a 403 forbidden.
If you are returning a 401 for this kind of action, it may be causing a handler in your application to redirect off to the identity provider.
Scheme Consistency
All of your OpenID Connect and OAuth participants should be using TLS (https), but in development, this might not be the case. If so, try and keep all of your dev instances on the same scheme. This includes redirect URIs (a very common issue in the IdentityServer4 community).
What About You?
Have you had bizarre redirect loop issues that you’d like to share? Do you want to scream your frustration into the void of an unmonitored comments section? Then feel free to let me know in the section below!
Getting Started with OAuth 2.0
Looking to get a solid understanding of OAuth 2.0 and how to use it? Check out my Pluralsight course: Getting Started with OAuth 2.0.
Возникает ошибка Request exceeded the limit of 10 internal redirects due to probable configuration error, что делать?
Добрый день!
Поисковый робот при обходе сайта выдает ошибку
[Sat Jun 20 20:51:19 2015] [error] [client 87.117.189.8] Request exceeded the limit of 10 internal redirects due to probable configuration error. Use ‘LimitInternalRecursion’ to increase the limit if necessary. Use ‘LogLevel debug’ to get a backtrace., referer: www.google.ru
Была проведена склейка доменов следующим кодом
Options +FollowSymLinks
RewriteEngine On
RewriteCond %
RewriteRule ^(.*)$ http://www.адрессайта.ru/$1 [R=301,L]
В гугл вебмастере указал главный домен сделал все что рекомендуют, ошибка все равно появляется.
Как от нее избавиться оставив домены склеиными?
весь файл
# BEGIN WordPress
# Склеивание доменов
Options +FollowSymLinks
RewriteEngine On
RewriteCond %
RewriteRule ^(.*)$ http://www.адрессайта.ru/$1 [R=301,L]
# Запрещаем GLOBALS и _REQUEST запросы
Options +FollowSymLinks
RewriteEngine On
RewriteCond %
RewriteCond %
RewriteCond %
RewriteRule ^(.*)$ index.php [F,L]
# Запрещаем доступ к wp-config
order allow,deny
deny from all
order allow,deny
deny from all
satisfy all
ExpiresActive On
ExpiresDefault «access plus 1 day»