I am getting a HTTP 522 error response for http://www.springframework.org/dtd/spring-beans.dtd. Since this is referenced in my application xml config, it is preventing the server from starting with the following error:
org.springframework.beans.factory.BeanDefinitionStoreException: IOException parsing XML document from ServletContext resource [/WEB-INF/spring/application-daos.xml]; nested exception is java.io.IOException: Server returned HTTP response code: 522 for URL: http://www.springframework.org/dtd/spring-beans.dtd
The strange thing is it works in other locations (AWS EC2 server) and for devs in other locations. I am located in Los Angeles, CA.
curl -v http://www.springframework.org/dtd/spring-beans.dtd
* Host www.springframework.org:80 was resolved.
* IPv6: (none)
* IPv4: 104.18.36.96, 172.64.151.160
* Trying 104.18.36.96:80...
* Connected to www.springframework.org (104.18.36.96) port 80
> GET /dtd/spring-beans.dtd HTTP/1.1
> Host: www.springframework.org
> User-Agent: curl/8.7.1
> Accept: */*
>
* Request completely sent off
< HTTP/1.1 522
< Date: Tue, 08 Jul 2025 22:20:26 GMT
< Content-Type: text/plain; charset=UTF-8
< Content-Length: 15
< Connection: keep-alive
< X-Frame-Options: SAMEORIGIN
< Referrer-Policy: same-origin
< Cache-Control: private, max-age=0, no-store, no-cache, must-revalidate, post-check=0, pre-check=0
< Expires: Thu, 01 Jan 1970 00:00:01 GMT
< Server: cloudflare
< CF-RAY: 95c2f78d78de341c-LAX
<
* Connection #0 to host www.springframework.org left intact
error code: 522%
another failed request from a different network in Los Angeles
curl -v http://www.springframework.org/dtd/spring-beans.dtd
* Host www.springframework.org:80 was resolved.
* IPv6: 2606:4700:4400::6812:2460, 2606:4700:4400::ac40:97a0
* IPv4: 104.18.36.96, 172.64.151.160
* Trying [2606:4700:4400::6812:2460]:80...
* Connected to www.springframework.org (2606:4700:4400::6812:2460) port 80
> GET /dtd/spring-beans.dtd HTTP/1.1
> Host: www.springframework.org
> User-Agent: curl/8.7.1
> Accept: */*
>
* Request completely sent off
< HTTP/1.1 522
< Date: Wed, 09 Jul 2025 00:32:12 GMT
< Content-Type: text/plain; charset=UTF-8
< Content-Length: 15
< Connection: keep-alive
< X-Frame-Options: SAMEORIGIN
< Referrer-Policy: same-origin
< Cache-Control: private, max-age=0, no-store, no-cache, must-revalidate, post-check=0, pre-check=0
< Expires: Thu, 01 Jan 1970 00:00:01 GMT
< Server: cloudflare
< CF-RAY: 95c3b8929956103d-LAX
<
* Connection #0 to host www.springframework.org left intact
error code: 522%
Comment From: qwerty4030
Now even EC2 is having issues fetching this file, it sometimes does get a response after about 10 seconds other times its 522:
curl -v http://www.springframework.org/dtd/spring-beans.dtd
* Trying 104.18.36.96:80...
* Connected to www.springframework.org (104.18.36.96) port 80
> GET /dtd/spring-beans.dtd HTTP/1.1
> Host: www.springframework.org
> User-Agent: curl/8.3.0
> Accept: */*
>
< HTTP/1.1 522
< Date: Wed, 09 Jul 2025 17:25:10 GMT
< Content-Type: text/plain; charset=UTF-8
< Content-Length: 15
< Connection: keep-alive
< X-Frame-Options: SAMEORIGIN
< Referrer-Policy: same-origin
< Cache-Control: private, max-age=0, no-store, no-cache, must-revalidate, post-check=0, pre-check=0
< Expires: Thu, 01 Jan 1970 00:00:01 GMT
< Server: cloudflare
< CF-RAY: 95c98466cf36c78f-CMH
<
* Connection #0 to host www.springframework.org left intact
error code: 522
Comment From: qwerty4030
@snicoll @bclozel @sbrannen This is starting to affect our production systems now, the servers fail to start or take many attempts to start successfully.
We do have a potential workaround to change this URL to https://www.springframework.org/dtd/spring-beans.dtd but prefer not to do a production patch unless absolutely necessary.
Comment From: bclozel
We will look into it. I am not seeing the requests you have shared as blocked by the CDN firewall. I will look into possible recent http/https configuration changes.
In the meantime, I don't understand why your entire production depends on this file being available. If I am not mistaken such schema files should be embedded with the JAR itself to allow for local validations. Probably a better long term fix than switching to https.
I will update this issue when I know more. Thanks.
Comment From: qwerty4030
Thanks! I am not exactly sure why that file is fetched remotely either, it is from a legacy application that was built using spring before maven was released. I see we have a spring-beans-4.0.9.RELEASE.jar that contains spring-beans-2.0.dtd but our XML file has this
<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http://www.springframework.org/dtd/spring-beans.dtd">
Comment From: bclozel
@qwerty4030 by any chance do you have a Tanzu Spring subscription? I am just getting back from PTO and realize that my colleagues are working on a very similar issue.
Comment From: qwerty4030
Nope, I don't believe we have that subscription. I wouldn't be surprised if others are having similar issues now.
My best guess is something with the cloudflare http/https config is preventing the file from being cached so every request is reaching the origin server which is overloaded/slow (522 response). The issue seems to have happened in different locations at different times as the cloudflare caches expired?
Comment From: jhoeller
IIRC there was a period where that old unversioned DTD declaration was not resolvable locally after its initial removal: #17433 - fixed in 4.1.6, and you seem to be using 4.0.9? (Obviously, both are long outdated in the meantime, but 4.1.6 less so than 4.0.9.)
There was a follow-up fix in 4.2.2, backported to 4.1.8: #18125
Technically, as of 4.0.x, http://www.springframework.org/dtd/spring-beans.dtd was not supported anymore. Only http://www.springframework.org/dtd/spring-beans-2.0.dtd was, and the fix in 4.1.6/4.1.8 just leniently redirected to that file.
Comment From: trevormarshall
Cloud team here identified and fixed a firewall rule for port 80/TCP. Feel free to try again.
Comment From: qwerty4030
Awesome! Thanks for the quick fix. Seems to be working now from my local machine and the EC2 instance.