Still having issues with code.jquery.com (lacks IPv6 support)

[lrcarvalho]

Originally reported at #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.

lrcarvalho@kalabria-2:~$ curl -6 https://code.jquery.com/jquery-3.4.1.min.js -I
HTTP/1.1 403 Forbidden
Date: Wed, 11 Sep 2019 12:31:10 GMT
Connection: close
Accept-Ranges: bytes
Cache-Control: max-age=10
Content-Length: 0
X-HW: 1568205070.dop054.sp3.t,1568205070.cds036.sp3.shn,1568205070.cds036.sp3.c

lrcarvalho@kalabria-2:~$ curl -6 https://code.jquery.com -v --trace-time
09:33:04.316010 * Rebuilt URL to: https://code.jquery.com/
09:33:04.320430 *   Trying 2001:4de0:ac18::1:a:1a...
09:33:04.320462 * TCP_NODELAY set
09:33:04.345722 * Connected to code.jquery.com (2001:4de0:ac18::1:a:1a) port 443 (#0)
09:33:04.345866 * ALPN, offering h2
09:33:04.345901 * ALPN, offering http/1.1
09:33:04.345975 * Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
09:33:04.350264 * successfully set certificate verify locations:
09:33:04.350288 *   CAfile: /etc/ssl/cert.pem
  CApath: none
09:33:04.350371 * TLSv1.2 (OUT), TLS handshake, Client hello (1):
09:33:04.378452 * TLSv1.2 (IN), TLS handshake, Server hello (2):
09:33:04.380605 * TLSv1.2 (IN), TLS handshake, Certificate (11):
09:33:04.381982 * TLSv1.2 (IN), TLS handshake, Server key exchange (12):
09:33:04.382153 * TLSv1.2 (IN), TLS handshake, Server finished (14):
09:33:04.382961 * TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
09:33:04.383004 * TLSv1.2 (OUT), TLS change cipher, Client hello (1):
09:33:04.383071 * TLSv1.2 (OUT), TLS handshake, Finished (20):
09:33:04.410728 * TLSv1.2 (IN), TLS change cipher, Client hello (1):
09:33:04.410860 * TLSv1.2 (IN), TLS handshake, Finished (20):
09:33:04.411066 * SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
09:33:04.411104 * ALPN, server did not agree to a protocol
09:33:04.411140 * Server certificate:
09:33:04.411188 *  subject: OU=Domain Control Validated; OU=PositiveSSL Multi-Domain; CN=jquery.org
09:33:04.411251 *  start date: Oct 17 00:00:00 2018 GMT
09:33:04.411296 *  expire date: Oct 16 23:59:59 2020 GMT
09:33:04.411487 *  subjectAltName: host "code.jquery.com" matched cert's "code.jquery.com"
09:33:04.411661 *  issuer: C=GB; ST=Greater Manchester; L=Salford; O=COMODO CA Limited; CN=COMODO RSA Domain Validation Secure Server CA
09:33:04.411726 *  SSL certificate verify ok.
09:33:04.412120 > GET / HTTP/1.1
09:33:04.412120 > Host: code.jquery.com
09:33:04.412120 > User-Agent: curl/7.54.0
09:33:04.412120 > Accept: */*
09:33:04.412120 >
09:33:04.438844 < HTTP/1.1 403 Forbidden
09:33:04.438908 < Date: Wed, 11 Sep 2019 12:33:04 GMT
09:33:04.438950 < Connection: close
09:33:04.438990 < Accept-Ranges: bytes
09:33:04.439071 < Cache-Control: max-age=10
09:33:04.439135 < Content-Length: 0
09:33:04.439193 < X-HW: 1568205184.dop054.sp3.t,1568205184.cds038.sp3.shn,1568205184.cds038.sp3.c
09:33:04.439234 <
09:33:04.439498 * Closing connection 0
09:33:04.440027 * TLSv1.2 (OUT), TLS alert, Client hello (1):

lrcarvalho@kalabria-2:~$ traceroute6 code.jquery.com
traceroute6: Warning: cds.s5x3j6q5.hwcdn.net has multiple addresses; using 2001:4de0:ac18::1:a:1a
traceroute6 to cds.s5x3j6q5.hwcdn.net (2001:4de0:ac18::1:a:1a) from 2804:d51:4b01:5d00:d0c5:73b7:8707:5fae, 64 hops max, 12 byte packets
 1  2804:d51:222:15c::1  3.549 ms  1.285 ms  1.015 ms
 2  * * *
 3  * * *
 4  * * *
...

[mgol]

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?

[lrcarvalho]

I'm accessing it from south Brazil (Porto Alegre city), but I have a client having the same issue from EUA (NY).

[mgol]

For posterity, I'm accessing from Warsaw, Poland.

[lrcarvalho]

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.

[marcosnils]

👋 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.

[Krinkle]

@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 #51 (comment) for example).

[marcosnils]

*   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

[Krinkle]

@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 #67 for the latest updates on that issue.