[Bug] Google Cloud Storage: unquoted Content-Disposition filenames break image loading in Chrome #42091

Description

Some images stored in Google Cloud Storage fail to load in Rocket.Chat when using Chrome. The chat shows Retry, but clicking it does not load the image. A small preview can still be visible.

I can reproduce this with the official image:

registry.rocket.chat/rocketchat/rocket.chat:8.5.3

The affected GCS object has a Content-Disposition value containing an unquoted filename with a comma. Chrome rejects the response with:

net::ERR_RESPONSE_HEADERS_MULTIPLE_CONTENT_DISPOSITION

Manually adding double quotes around the filename in the object's GCS metadata fixes the same image in the same Chrome browser. No re-upload or image-content change was needed.

This also occurred before the upgrade to 8.5.3. I have not identified the first affected Rocket.Chat release or the first affected Chrome version.

Steps to reproduce

1. Configure Google Cloud Storage as the file-upload backend, with files served directly through signed GCS URLs rather than proxied through Rocket.Chat.

2. Upload or locate an image whose filename contains a comma. The observed case was a clipboard image named Clipboard - August 21, 2026 11:47 AM.png.

3. Inspect the corresponding GCS object's metadata. In the observed case, the affected thumbnail had this value:

   Content-Disposition: inline; filename=thumb-Clipboard - August 21, 2026 11:47 AM.png

4. Open the message in Chrome and try to load the image, including clicking Retry.

5. Inspect the failed request in DevTools.

The observed failure and metadata-only repair below were verified on an existing chat upload.

Expected behavior

The image should load normally. Filenames containing commas and spaces should be preserved and represented using a valid Content-Disposition header, for example:

Content-Disposition: inline; filename="thumb-Clipboard - August 21, 2026 11:47 AM.png"

The filename parameter must be encoded/escaped appropriately, consistent with RFC 6266, rather than interpolated as an unquoted string.

Actual behavior and network evidence

In the affected Chrome browser, the signed GCS GET request fails with:

net::ERR_RESPONSE_HEADERS_MULTIPLE_CONTENT_DISPOSITION

An older browser loads the same object successfully and shows these relevant response details:

Status: 200 OK
Content-Type: image/png
Content-Length: 43852
Content-Disposition: inline; filename=thumb-Clipboard - August 21, 2026 11:47 AM.png
Cache-Control: private, max-age=0

The signed URL already included response-content-disposition=inline, but the response still contained the malformed filename parameter.

The evidence above shows one malformed header value; it does not establish that GCS sent two separate Content-Disposition header fields. Signed URLs, signatures, bucket paths, and service-account identifiers are omitted from this report.

Server and client setup

Confirmed workaround

In Google Cloud Console, I opened the affected object and changed only its Content-Disposition metadata.

Before:

inline; filename=thumb-Clipboard - August 21, 2026 11:47 AM.png

After:

inline; filename="thumb-Clipboard - August 21, 2026 11:47 AM.png"

After saving the metadata, the image displayed correctly in the previously affected Chrome browser.

This has been confirmed for the tested object only. It is not a bucket-wide repair or a fix to Rocket.Chat's upload implementation.

Relevant source code

The GoogleStorage implementation in the 8.5.3 tag, in getWriteStream(), constructs metadata as follows:

metadata: {
    contentType: file.type,
    contentDisposition: `inline; filename=${file.name}`,
}

The unquoted interpolation matches the malformed metadata observed in GCS and appears to explain this failure.

Related issue and previous fix

The same class of problem was previously reported for the Amazon S3 backend in #8584 and fixed by PR #8593, merged on October 28, 2017.

That PR's diff changed only the Amazon S3 implementation. The Google Storage implementation in 8.5.3 still uses an unquoted filename. This report concerns the GCS backend, not a claim that the old S3 fix regressed.

Requested fix

Please generate a valid Content-Disposition value in the Google Storage upload backend using appropriate filename quoting, escaping, and Unicode handling. Preserve the original filename rather than stripping punctuation.

Suggested regression coverage includes commas, spaces, embedded quotes, Unicode filenames, and generated thumbnail names.

Please also document how administrators can repair affected existing objects: correcting metadata generation for future uploads will not by itself update the malformed metadata already stored in GCS.