Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error: Exceeded maxRedirects #159

Closed
chris-dura opened this issue Mar 1, 2021 · 3 comments
Closed

Error: Exceeded maxRedirects #159

chris-dura opened this issue Mar 1, 2021 · 3 comments
Assignees

Comments

@chris-dura
Copy link

I have some documentation that links out to the Android Developer docs, and they apparently have some hefty redirects going on (although, it doesn't take more than a second or two, and is definitely not "stuck in a redirect loop").

https://developer.android.com/reference/android/support/design/widget/TabItem.html

I don't want to ignore these, because I want to know if they're truly dead. But, the error seems to be in the guts of some dependencies.

[
  LinkCheckResult {
    link: 'https://developer.android.com/reference/android/support/design/widget/TabItem.html',
    statusCode: 0,
    err: Error: Exceeded maxRedirects. Probably stuck in a redirect loop https://developer.android.com/reference/android/support/design/widget/TabItem
        at Redirect.onResponse (/Users/CDura/code/kite-design-system/node_modules/request/lib/redirect.js:98:27)
        at Request.onRequestResponse (/Users/CDura/code/kite-design-system/node_modules/request/request.js:986:22)
        at ClientRequest.emit (events.js:315:20)
        at HTTPParser.parserOnIncomingClient [as onIncoming] (_http_client.js:641:27)
        at HTTPParser.parserOnHeadersComplete (_http_common.js:126:17)
        at TLSSocket.socketOnData (_http_client.js:509:22)
        at TLSSocket.emit (events.js:315:20)
        at addChunk (_stream_readable.js:309:12)
        at readableAddChunk (_stream_readable.js:284:9)
        at TLSSocket.Readable.push (_stream_readable.js:223:10),
    status: 'dead'
  }
]
@NicolasMassart NicolasMassart self-assigned this Mar 8, 2021
@NicolasMassart
Copy link
Contributor

It's very strange but it seems that this is due to the user_agent used in link-check. When I remove it or change it to empty, then it perfectly works. I don't Know why Google has issues with this agent, it may be linked to the authorisation process used for this android site (if you look at the redirects stack it goes through some auth). I don't know if it's standard behaviour or a something specific to this site. I'm a bit worried that the site behaves differently depending on user agent though as it's clearly not a good filter behaviour.
Anyway this is clearly an issue on the link-check dependency side and I will create the matching issue.
Thanks for raising this.

@chris-dura
Copy link
Author

@NicolasMassart -- It appears you may have fixed this in the link-check dependency, however, I'm still experiencing the problem using markdown-link-check... should I be using link-check directly?

@NicolasMassart
Copy link
Contributor

I only raised the ticket, @tcort fixed it by adding a customisable user-agent.
However the markdown-link-check latest release was done before this change in link-check so it's not part of the latest release. You can manually update link-check to https://github.com/tcort/link-check/releases/tag/v5.0.0 in your packages.json file I think it's going to be compatible with MLC until @tcort releases a new version.

lembergerth added a commit to sosy-lab/sv-benchmarks that referenced this issue Sep 27, 2021
markdown-link-check does not solve tcort/markdown-link-check#159,
which is a problem for us.

So we resort to the (less nice-looking) linkchecker.
We first convert markdown files to HTML through pandoc,
and then pass them to linkchecker.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants