github-action-markdown-link-check
github-action-markdown-link-check copied to clipboard
Status: 403 Forbidden for link in markdown link check github actions, and 200 Ok locally
While using GitHub actions I get the error.
ERROR: 1 dead links found!
[✖] https://siiami.pl/ → Status: 403
The complete log is here https://github.com/iamtodor/jdg/runs/7010592789?check_suite_focus=true
However, if I run the same command locally find . -name '*.md' -not -path './node_modules/*' -exec markdown-link-check '{}' --config .github/workflows/markdown_link_check_config.json -v ';'
The result is 200:
[✓] https://siiami.pl/ → Status: 200
Here are some curl outputs
>>> curl -I https://siiami.pl
HTTP/2 301
server: nginx
date: Wed, 22 Jun 2022 19:00:01 GMT
content-type: text/html; charset=UTF-8
content-length: 0
location: https://www.siiami.pl/
x-sucuri-id: 14015
x-xss-protection: 1; mode=block
x-frame-options: SAMEORIGIN
x-content-type-options: nosniff
content-security-policy: upgrade-insecure-requests;
x-redirect-by: WordPress
vary: Accept-Encoding
x-sucuri-cache: HIT
>>> curl -v https://siiami.pl -o /dev/null
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying 192.124.249.65:443...
* Connected to siiami.pl (192.124.249.65) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/cert.pem
* CApath: none
* (304) (OUT), TLS handshake, Client hello (1):
} [314 bytes data]
* (304) (IN), TLS handshake, Server hello (2):
{ [122 bytes data]
* (304) (IN), TLS handshake, Unknown (8):
{ [19 bytes data]
* (304) (IN), TLS handshake, Certificate (11):
{ [2929 bytes data]
* (304) (IN), TLS handshake, CERT verify (15):
{ [264 bytes data]
* (304) (IN), TLS handshake, Finished (20):
{ [52 bytes data]
* (304) (OUT), TLS handshake, Finished (20):
} [52 bytes data]
* SSL connection using TLSv1.3 / AEAD-AES256-GCM-SHA384
* ALPN, server accepted to use h2
* Server certificate:
* subject: CN=siiami.pl
* start date: Apr 1 15:40:32 2022 GMT
* expire date: Apr 1 15:40:32 2023 GMT
* subjectAltName: host "siiami.pl" matched cert's "siiami.pl"
* issuer: C=US; ST=Arizona; L=Scottsdale; O=GoDaddy.com, Inc.; OU=http://certs.godaddy.com/repository/; CN=Go Daddy Secure Certificate Authority - G2
* SSL certificate verify ok.
* Using HTTP2, server supports multiplexing
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7fc86c80b600)
> GET / HTTP/2
> Host: siiami.pl
> user-agent: curl/7.79.1
> accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
< HTTP/2 301
< server: nginx
< date: Wed, 22 Jun 2022 19:00:43 GMT
< content-type: text/html; charset=UTF-8
< content-length: 0
< location: https://www.siiami.pl/
< x-sucuri-id: 14015
< x-xss-protection: 1; mode=block
< x-frame-options: SAMEORIGIN
< x-content-type-options: nosniff
< content-security-policy: upgrade-insecure-requests;
< x-redirect-by: WordPress
< vary: Accept-Encoding
< x-sucuri-cache: HIT
<
{ [0 bytes data]
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
* Connection #0 to host siiami.pl left intact
What can be the cause of such behavior? And how can it be fixed to getting 200 Ok by markdown link check from that link?
Seeing exactly the same issue, but in my case @github is throwing the 403 on https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request
@WyriHaximus I had the same issue with GitHub, but it is locally and in GitHub actions. Take a look at this solution https://github.com/tcort/markdown-link-check/issues/201#issuecomment-1110242146
But with site https://siiami.pl/, the link check works fine locally
@gaurav-nelson same applies to the link https://aplikacja.ceidg.gov.pl/ceidg/ceidg.public.ui/search.aspx locally - no issues, on GitHub actions - link is dead
[✖] https://aplikacja.ceidg.gov.pl/ceidg/ceidg.public.ui/search.aspx → Status: 0 Error: ESOCKETTIMEDOUT
at ClientRequest.<anonymous> (/usr/local/lib/node_modules/markdown-link-check/node_modules/request/request.js:816:19)
at Object.onceWrapper (node:events:641:28)
at ClientRequest.emit (node:events:527:28)
at TLSSocket.emitRequestTimeout (node:_http_client:771:9)
at Object.onceWrapper (node:events:641:28)
at TLSSocket.emit (node:events:539:35)
at TLSSocket.Socket._onTimeout (node:net:516:8)
at listOnTimeout (node:internal/timers:559:17)
at processTimers (node:internal/timers:502:7) {
code: 'ESOCKETTIMEDOUT',
connect: false
}
@WyriHaximus I had the same issue with GitHub, but it is locally and in GitHub actions. Take a look at this solution tcort/markdown-link-check#201 (comment) But with site
https://siiami.pl/, the link check works fine locally
@iamtodor That works perfectly, think you!
@gaurav-nelson same applies to the link https://aplikacja.ceidg.gov.pl/ceidg/ceidg.public.ui/search.aspx locally - no issues, on GitHub actions - link is dead
[✖] https://aplikacja.ceidg.gov.pl/ceidg/ceidg.public.ui/search.aspx → Status: 0 Error: ESOCKETTIMEDOUT at ClientRequest.<anonymous> (/usr/local/lib/node_modules/markdown-link-check/node_modules/request/request.js:816:19) at Object.onceWrapper (node:events:641:28) at ClientRequest.emit (node:events:527:28) at TLSSocket.emitRequestTimeout (node:_http_client:771:9) at Object.onceWrapper (node:events:641:28) at TLSSocket.emit (node:events:539:35) at TLSSocket.Socket._onTimeout (node:net:516:8) at listOnTimeout (node:internal/timers:559:17) at processTimers (node:internal/timers:502:7) { code: 'ESOCKETTIMEDOUT', connect: false }
Is it just that URL, or also other pages on that subdomain? ESOCKETTIMEOUT seems to bit low-level to me to not be firewall or WAP related
I am running into the same issue for a link to github docs

Having the same issue with anything on https://docs.github.com/, there's a related issue at https://github.com/github/docs/issues/17358. The internal investigation seems to be ongoing 🤷. However, given the reports here for other URLs, I'm hazarding a guess that this isn't necessarily a GitHub Docs issue, but perhaps an issue here?