[Bug 60562] New: winhttp silently truncates response header lines longer than 1459 bytes (breaks pre-signed S3 redirects)

[WineHQ Bugzilla]

http://bugs.winehq.org/show_bug.cgi?id=60562

            Bug ID: 60562
           Summary: winhttp silently truncates response header lines
                    longer than 1459 bytes (breaks pre-signed S3
                    redirects)
           Product: Wine
           Version: 11.20
          Hardware: x86-64
                OS: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: winhttp
          Assignee: [e-mail]
          Reporter: [e-mail]
  Target Milestone: ---
      Distribution: ---

read_reply() in dlls/winhttp/request.c reads the status line and each response
header line into a fixed stack buffer of MAX_REPLY_LEN (1460) bytes.
read_line()
copies at most that many bytes and discards the rest of the line, so a response
header line longer than 1459 bytes is silently truncated. No error is returned
to the caller. This is still the case in master as of 840a939ee5.

Native WinHTTP accepts much longer header lines. The documented default for
WINHTTP_OPTION_MAX_RESPONSE_HEADER_SIZE is 64 KB for all headers combined, and
WinHTTP defines ERROR_WINHTTP_HEADER_SIZE_OVERFLOW for responses that exceed
it.

Real-world impact: services that redirect to pre-signed AWS S3 / CloudFront
URLs. When the signing credentials are temporary, the URL carries an
X-Amz-Security-Token of about 1 KB, so the Location header goes over 1460
bytes.
Signature parameters come last in these URLs, so the truncated Location loses
X-Amz-SignedHeaders and X-Amz-Signature. After the redirect, S3 answers
"400 Bad Request" with error code AuthorizationQueryParametersError ("Query-
string authentication version 4 requires the X-Amz-Algorithm, X-Amz-Credential,
X-Amz-Signature, X-Amz-Date, X-Amz-SignedHeaders, and X-Amz-Expires
parameters").

Affected application: Adobe Lightroom Classic 15.6. Its Camera Raw engine
downloads AI models from photos.adobe.io, which 302-redirects to such URLs. The
People / Object / Reflection masking models fail with "some AI models failed to
download", while the same version downloads them fine on Windows. Because the
cut-off depends on the token length, some downloads in a session succeed and
others fail.

Steps to reproduce (no Adobe software needed):
1. Start a local HTTP server that answers GET / with status 200 and a Location
   header whose value is 2999 characters long.
2. From a Windows program running under wine, use WinHTTP to GET that URL
   (WinHttpOpen / WinHttpConnect / WinHttpOpenRequest / WinHttpSendRequest /
   WinHttpReceiveResponse), then read the header with
   WinHttpQueryHeaders(WINHTTP_QUERY_LOCATION) and print the returned length.

Expected: 2999 characters
Actual:   1449 characters. The 10-byte "Location: " prefix plus the 1449-byte
          value fill the 1460-byte buffer, including its terminating NUL.

Raising the line limit in read_reply() to the native 64 KB makes the
reproduction return the full value. With that change, Lightroom's model
downloads succeed and the files are byte-identical to the same files downloaded
on Windows.

Disclosure: the root-cause analysis and the local test were done with the help
of an AI assistant. Per the Clean Room Guidelines, no AI-written code is
attached; the description above is meant to let a developer write the fix and
the test independently.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.