[BUG] Openapi-generator generates code with urrlib3 `getheaders()` that has been removed in 2.6.0

[potiuk]

Bug Report Checklist

• Have you provided a full/minimal spec to reproduce the issue?
• Have you validated the input using an OpenAPI validator?
• Have you tested with the latest master to confirm the issue still exists?
• Have you searched for related issues/PRs?
• What's the actual output vs expected output?
• [Optional] Sponsorship to speed up the bug fix or feature request (example)

Description

The code generated by Open API generator for Python uses urllib3 functionality removed in urllib3 2.6.0 - namely getHeaders() method has been replaced with headers property.

This is described in https://github.com/urllib3/urllib3/blob/main/CHANGES.rst#removals and has been deprecated in 2.0.0 more than 2.5 years ago.

https://github.com/urllib3/urllib3/blob/main/CHANGES.rst#deprecated

The code generated is in exception handling (ApiException):

self.headers = http_resp.getheaders()

The issue with not supporting 2.6.0 of urllib3 is that it also fixes some security vulnerabilities:

assessed as "high" severity - 8.9/10 both:

https://nvd.nist.gov/vuln/detail/CVE-2025-66471
https://nvd.nist.gov/vuln/detail/CVE-2025-66418

It's being discussed in urrlib related issue (see the end) whether a good idea might be to bring getheaders back for a while, bit fixing it here should be done regardless IMHO.

openapi-generator version

7.13.0 - but I also re-run it wuth 7.17.0 and the same code is generated. Also Dependabot to upgrade urllib3 - indicates that main is not compatible https://github.com/OpenAPITools/openapi-generator/actions/runs/19983322742/job/57313782885?pr=22497

Generation Details

We use docker client of openapi-generaor-cli from https://github.com/apache/airflow/blob/main/airflow-core/src/airflow/api_fastapi/core_api/openapi/v2-rest-api-generated.yaml

We also patch a few things after code is generated, but this is irrelevant (we also plan to patch getheaders if there is no quick fix): https://github.com/apache/airflow/blob/main/dev/breeze/src/airflow_breeze/commands/release_management_commands.py#L3535

     [
            "docker",
            "run",
            "--rm",
            "-u",
            f"{os.getuid()}:{os.getgid()}",
            "-v",
            f"{TARGET_API_YAML_PATH}:/spec.yaml",
            "-v",
            f"{PYTHON_CLIENT_TMP_DIR}:/output",
            f"openapitools/openapi-generator-cli:v{OPENAPI_GENERATOR_CLI_VER}",
            "generate",
            "--input-spec",
            "/spec.yaml",
            "--generator-name",
            "python",
            "--git-user-id",
            f"{os.environ.get('GIT_USER')}",
            "--output",
            "/output",
            "--package-name",
            "airflow_client.client",
            "--git-repo-id",
            "airflow-client-python",
            "--additional-properties",
            f"packageVersion={python_client_version}",
        ],

Steps to reproduce

git co git@github.com:apache/airflow.git
cd airflow
uv tool install --python 3.10 -e ./dev/breeze --force
breeze release-management prepare-python-client

This generates python client package in "dist" folder - when you unpack it, you will find .getheaders method on urllib3 response

./airflow_client/client/exceptions.py:            self.headers = http_resp.getheaders()

Code:

class ApiException(OpenApiException):

    def __init__(
        self,
        status=None,
        reason=None,
        http_resp=None,
        *,
        body: Optional[str] = None,
        data: Optional[Any] = None,
    ) -> None:
        self.status = status
        self.reason = reason
        self.body = body
        self.data = data
        self.headers = None

        if http_resp:
            if self.status is None:
                self.status = http_resp.status
            if self.reason is None:
                self.reason = http_resp.reason
            if self.body is None:
                try:
                    self.body = http_resp.data.decode('utf-8')
                except Exception:
                    pass
            self.headers = http_resp.getheaders()

Related issues/PRs

Related issue in uyrllib3 - describing more context urllib3/urllib3#3731

Suggest a fix

Use headers when urrlib3 is used.

[wing328]

Use headers when urrlib3 is used.

can you please file a PR with the suggested fix?

[potiuk]

Use headers when urrlib3 is used.

can you please file a PR with the suggested fix?

I do not know much about internals of openapi-generator and I have plenty of work in Apache Airflow as maintainer, I might not have time to do it - but if you cannot do it as maintainers, I suggest you can mark it with "good first issue" label and maybe someone will fix it.

FYI. Urllib3 maintainers released 2.6.1 and restored the methods for now so this is not an urgent thing (it was not urgent for the last 2.5 years apparently) - but this problem will come back in the future, so maybe attracting someone to solve it for you is a good idea.

[potiuk]

Not mentioning that I do not program in java and have no idea what "mustache" is. But for anyone who wants to fix this I guess this needs fixing here:

https://github.com/OpenAPITools/openapi-generator/blob/master/modules/openapi-generator/src/main/resources/python/exceptions.mustache#L122

I guess replacing getheaders() with headers (no () ) is what is needed, however I have no idea how it impacts other code - I know there are at least few variants of the generated code and not sure how much those are impacted:

Also - as mentioned above the dependabot upgrading urllib3 to 2.6.0 failed https://github.com/OpenAPITools/openapi-generator/actions/runs/19983322742/job/57313782885?pr=22497 with some sample generation issue, maybe related or not - and unfortunately - my java tooling and knowledg are about 10 years rusty, so it would take for me a lot of time to be able to run and test it.

Unfortunately - we are mostly Python focused, and we are just a "user" of openapi-generator (in the form of docker containers) - so as much as I would like to help (I hope the above will give someone enough who is more experienced more leads) - this would be terribly inefficient for me to learn Java, and the effort needed to go through the initial hoops is far too big for me to inves my time - probably that time is better spent on contributing to Python projects like Airflow.

But -> this is not a diffivcult issue to fix, so If you do mark it as "good first issue" - the chance is that somene will actually pick it up - in Airflow those issues are usually picked in hours and we have many new contributors who were willing to contribute them and stay longer in the project - unfortunately, again, I am just a user and contributing to java project is a bit outside of my interest now.

[jeremy-audet]

I think I can get a PR up for this tonight.