Closed lrcarvalho closed 3 years ago
Thanks for the report. This is a good place to report issues with code.jquery.com.
The request works on my end:
$ curl -6 https://code.jquery.com/jquery-3.4.1.min.js -I
HTTP/1.1 200 OK
Date: Wed, 11 Sep 2019 15:10:09 GMT
Connection: Keep-Alive
Accept-Ranges: bytes
Content-Length: 88145
Content-Type: application/javascript; charset=utf-8
Last-Modified: Wed, 01 May 2019 21:14:27 GMT
Server: nginx
ETag: W/"5cca0c33-15851"
Cache-Control: max-age=315360000
Cache-Control: public
Access-Control-Allow-Origin: *
Vary: Accept-Encoding
X-HW: 1568214609.dop002.wa1.t,1568214609.cds002.wa1.shn,1568214609.cds002.wa1.c
What's your location?
I'm accessing it from south Brazil (Porto Alegre city), but I have a client having the same issue from EUA (NY).
For posterity, I'm accessing from Warsaw, Poland.
I sent an email to stackpath.com explaining the issue on September 11. No updates till now. It can be a huge impact from people that are using IPv6, since more sites that use the jQuery CDN probably are being impacted with this issue.
Waiting for some updates from stackpath.
Thanks guys.
:wave: just came across this issue and I find it quite surprising that it's been a year and still no news. This is going to heavily affect some big part part of jQuery users as clients start moving to ipv6.
@marcosnils Could you run these commands to help us understand the issue, and if you don't mind, which country are you connecting from?
curl -6 https://code.jquery.com/jquery-3.4.1.min.js -I -v
dig code.jquery.com
dig AAAA code.jquery.com
It works for me over IPv6-only connections from London, and from Tokyo. (see https://github.com/jquery/codeorigin.jquery.com/issues/51#issuecomment-658477449 for example).
* Trying 2001:4de0:ac19::1:b:2a:443...
* TCP_NODELAY set
* Connected to code.jquery.com (2001:4de0:ac19::1:b:2a) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [122 bytes data]
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
{ [27 bytes data]
* TLSv1.3 (IN), TLS handshake, Certificate (11):
{ [6105 bytes data]
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
{ [264 bytes data]
* TLSv1.3 (IN), TLS handshake, Finished (20):
{ [36 bytes data]
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.3 (OUT), TLS handshake, Finished (20):
} [36 bytes data]
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256
* ALPN, server accepted to use h2
* Server certificate:
* subject: CN=jquery.org
* start date: Oct 6 00:00:00 2020 GMT
* expire date: Oct 16 23:59:59 2021 GMT
* subjectAltName: host "code.jquery.com" matched cert's "code.jquery.com"
* issuer: C=GB; ST=Greater Manchester; L=Salford; O=Sectigo Limited; CN=Sectigo RSA Domain Validation Secure Server CA
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
} [5 bytes data]
* Using Stream ID: 1 (easy handle 0x5605241acdf0)
} [5 bytes data]
> HEAD /jquery-3.4.1.min.js HTTP/2
> Host: code.jquery.com
> user-agent: curl/7.68.0
> accept: */*
>
{ [5 bytes data]
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
{ [217 bytes data]
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
{ [217 bytes data]
* old SSL session ID is stale, removing
{ [5 bytes data]
* Connection state changed (MAX_CONCURRENT_STREAMS == 100)!
} [5 bytes data]
< HTTP/2 301
< date: Wed, 16 Dec 2020 00:42:56 GMT
< content-length: 178
< content-type: text/html
< accept-ranges: bytes
< server: nginx
< location: https://code.jquery.com/jquery-3.4.1.min.js
< cache-control: max-age=2592000
< cache-control: public
< access-control-allow-origin: *
< x-hw: 1608079376.dop210.ez1.t,1608079376.cds205.ez1.hn,1608079376.cds221.ez1.c
<
* Connection #0 to host code.jquery.com left intact
HTTP/2 301
date: Wed, 16 Dec 2020 00:42:56 GMT
content-length: 178
content-type: text/html
accept-ranges: bytes
server: nginx
location: https://code.jquery.com/jquery-3.4.1.min.js
cache-control: max-age=2592000
cache-control: public
access-control-allow-origin: *
x-hw: 1608079376.dop210.ez1.t,1608079376.cds205.ez1.hn,1608079376.cds221.ez1.c
; <<>> DiG 9.16.1-Ubuntu <<>> code.jquery.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36045
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;code.jquery.com. IN A
;; ANSWER SECTION:
code.jquery.com. 181 IN CNAME cds.s5x3j6q5.hwcdn.net.
cds.s5x3j6q5.hwcdn.net. 183 IN A 209.197.3.24
;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: mar dic 15 21:43:06 -03 2020
;; MSG SIZE rcvd: 96
; <<>> DiG 9.16.1-Ubuntu <<>> AAAA code.jquery.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18542
;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;code.jquery.com. IN AAAA
;; ANSWER SECTION:
code.jquery.com. 167 IN CNAME cds.s5x3j6q5.hwcdn.net.
cds.s5x3j6q5.hwcdn.net. 167 IN AAAA 2001:4de0:ac19::1:b:2a
cds.s5x3j6q5.hwcdn.net. 167 IN AAAA 2001:4de0:ac19::1:b:1a
cds.s5x3j6q5.hwcdn.net. 167 IN AAAA 2001:4de0:ac19::1:b:3b
cds.s5x3j6q5.hwcdn.net. 167 IN AAAA 2001:4de0:ac19::1:b:3a
cds.s5x3j6q5.hwcdn.net. 167 IN AAAA 2001:4de0:ac19::1:b:1b
cds.s5x3j6q5.hwcdn.net. 167 IN AAAA 2001:4de0:ac19::1:b:2b
;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: mar dic 15 21:43:20 -03 2020
;; MSG SIZE rcvd: 248
@marcosnils Thanks, that helps. It looks like IPv6 is all in order there. Your client finds the right DNS records with IPv6 addresses, establishes a good connection to it, and responds with the CDN and our serves all the way, and gets a valid response.
The problem is the redirect response, which is due to the address of this particular CDN node close to you being unknown to us. It can seem specific to IPv6 if the IPv4 address of your nearest CDN does happen to be known to us.
That issue is being worked on as we speak, and has been a bit of a whack-a-mole in recent weeks. We hope this will be solved soon in its entirety. Follow https://github.com/jquery/codeorigin.jquery.com/issues/67 for the latest updates on that issue.
Originally reported at https://github.com/jquery/codeorigin.jquery.com/issues/51 and jquery/jquery.com#51.
The jQuery CDN code.jquery.com lacks IPv6 addresses and thus resources from it can't be received using IPv6.
As @mgol said, I'm also sorry to post it here guys, but still there doesn't seem to be any place to report issues related to code.jquery.com.
Below some traceroutes and curl calls that may help to identify the real issue.