Issue Summary

When Bitbucket Data Center is deployed behind a reverse proxy that communicates with Bitbucket using the AJP connector, users are unable to delete access tokens, SSH keys, GPG keys, etc. from the Bitbucket user interface. Although the deletion action appears to succeed in the UI, the credentials are not actually removed—refreshing the page shows that the tokens or keys are still present.

This problem occurs because Bitbucket does not receive the intended HTTP DELETE requests from the proxy. Instead, Bitbucket only receives HTTP OPTIONS requests for these operations, which don't trigger the deletion of credentials. As a result, users and administrators can't reliably revoke access tokens or keys.

The issue is caused by a known bug in Tomcat 9.0.110 and 10.1.47, where DELETE requests sent through an AJP connector are incorrectly converted to OPTIONS requests before reaching the application.

Steps to Reproduce

1. Deploy Bitbucket Data Center 9.4.14 or 9.4.15 behind a reverse proxy that supports AJP.
2. Configure the proxy to forward requests to Bitbucket using the AJP connector (e.g., ProxyPass ajp://<bitbucket-host>:<ajp-port>).
3. Log in to Bitbucket via the proxied URL.
4. Attempt to delete an HTTP access token, SSH key, or GPG key from the Bitbucket UI.
5. Refresh the page.

Expected Results

The selected access token or key is deleted and no longer appears after a page refresh. Also, the Bitbucket logs show a DELETE request for the relevant REST endpoint.

Actual Results

• The UI may indicate the token/key was deleted, but after refreshing, it reappears.
• Bitbucket logs don't show a DELETE request for the endpoint; instead, only OPTIONS requests are logged in the access logs.
• The proxy logs show DELETE requests being sent, but Bitbucket never receives them as DELETE.

Workaround

Reconfigure the proxy to forward requests to Bitbucket using the HTTP connector instead of the AJP connector.