Bitbucket since 9.3 support a plugin framework for building custom "file stores" such that Git LFS objects can be stored elsewhere, and accessed directly by clients. This offloads storage and connection/transfer load from Bitbucket to the store. An implementation that used AWS S3 was also shipped in the same release.

The File Store SPI lets a plugin return headers that must accompany a Git LFS download URL, but those headers can currently only be honoured on the Git LFS Batch API path, where Bitbucket passes them to the git-lfs client.

Web UI downloads work differently: Bitbucket redirects the browser straight to the store URL, and an HTTP redirect has no mechanism for specifying request headers for the subsequent call, so any required headers are dropped and the store rejects the request. Stores that authenticate using self-contained signed URLs are unaffected, but a store that requires an Authorization header cannot support UI-initiated downloads at all, including file previews, attachment rendering and raw file downloads.

This request is to make such stores viable by having Bitbucket proxy UI downloads through PluginFileStore.readFile() rather than redirecting to the store. The proposal is to add a flag to GenerateGetUrlResponse, for example isBrowserExecutable(), that the store implementation sets to declare whether the returned URL can be handed directly to a browser; when it cannot, Bitbucket streams the object itself.

Batch API downloads for the git-lfs client would continue to be served with direct store URLs, so the large majority of LFS traffic remains offloaded to the object store and only the comparatively small volume of Web UI traffic is proxied.