Server returned HTTP response code: 403 for dbchangelog-4.5.xsd

General Discussion
1

Hello everyone,

I’m facing a strange issue and would like to know if anyone has experienced something similar.

Environment

  • Spring Boot 1.5.22.RELEASE
  • Liquibase 3.5.5
  • Java 8 (OpenJDK 1.8.0_492)
  • Docker container deployed in Rancher/Kubernetes

Problem

We have a changelog with the following header:

Hello everyone,

I’m facing a strange issue and would like to know if anyone has experienced something similar.

Environment

  • Spring Boot 1.5.22.RELEASE
  • Liquibase 3.5.5
  • Java 8 (OpenJDK 1.8.0_492)
  • Docker container deployed in Rancher/Kubernetes

Problem

We have a changelog with the following header:


<databaseChangeLog
    xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="
        http://www.liquibase.org/xml/ns/dbchangelog
        http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-4.5.xsd">

The application was working correctly until July 17th. Since then, startup fails with:

liquibase.exception.ChangeLogParseException: liquibase.exception.SetupException: Error parsing … schema_reference.4: Failed to read schema document https://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-4.5.xsd’

What we investigated

  • The same application works locally.
  • The Docker image has not changed.
  • We tested rolling back to previous images and the same error occurs.
  • The pod has Internet connectivity.
  • From inside the pod we can successfully access the XSD:

curl “…dbchangelog-4.5.xsd”

and it returns a valid XML schema (<xsd:schema>).

  • The application is running with Java 8.
  • The runtime Liquibase version is 3.5.5.

Interesting finding

If we change:…dbchangelog-4.5.xsd

to: …/dbchangelog-3.5.xsd

the application starts successfully and Liquibase runs without errors.

Questions

  1. Is there any known issue with Liquibase 3.5.5 resolving 4.x XSD files?
  2. Has anything changed recently regarding XSD validation or schema resolution that could explain why this worked before and now fails?
  3. Is it expected that Liquibase 3.5.5 should only use dbchangelog-3.5.xsd?
  4. Has anyone seen different behavior between local execution and Kubernetes/containerized environments when resolving XSDs?

Any insight would be greatly appreciated.

Thanks!

2

Thank You for reporting this issue. This is now fixed on our side, and you don’t need to change anything to get working again.

What happened:

We recently moved liquibase.org behind a new CDN/security provider. One of its default protections blocks non-standard user agents, including the default agent that Java 8 sends.

What we did:

We’ve specifically allowed Java user agents to pass through. We’ve verified this in production against the XSD and JSON schema URLs. No action is required on your side.

A friendly heads-up for the future:

Older Java 8 clients are increasingly likely to be flagged by security tooling generally, not just ours. We’ll do our best to avoid regressions like this, but there may be a time in the future where we can no longer support Java 8 user agents.

Our recommendations:

  • Upgrade to a current Liquibase release when you can. Modern versions ship the schema definitions inside the distribution and resolve them locally, so they no longer depend on downloading schemas over the network at all.

  • Upgrading Java to a current LTS JRE (17 or 21) is also worth doing when your environment allows.

  • For business-critical database pipelines, consider Liquibase Secure. It adds the hardening, policy controls, and vendor support that teams running Liquibase in production for critical workloads increasingly need, including a direct support path so issues like this get triaged for you rather than surfacing as a broken build. If that’s a fit for your environment, please visit Liquibase Secure.

3

Thank you for the prompt investigation and resolution.

We appreciate the detailed root cause analysis and the corrective actions taken to allow Java 8 user agents through the new security layer. We have confirmed that the issue is now resolved in our environment.

Thank you also for the recommendations regarding Liquibase and Java upgrades. We appreciate your support and the transparency provided throughout this incident.

Best regards,
Diego Galeano