http://bugs.winehq.org/show_bug.cgi?id=59672 --- Comment #11 from Hans Leidekker <hans@meelstraat.net> --- (In reply to axis6404 from comment #10)
I noticed a recurring discrepancy in the logs, such as around line 1414 of doaxvv9003-20260418.txt.
Both winhttp:read_data and the "dwStatusInformationLength" in WINHTTP_CALLBACK_STATUS_READ_COMPLETE(0x80000) are occasionally 8193, even though only 8192 bytes were reported as available.
06e8:trace:winhttp:WinHttpQueryDataAvailable ... ... 06e8:trace:winhttp:query_data_available 8192 bytes available ... 06e8:trace:winhttp:WinHttpReadData ..., ..., 8193 (sample code: https://learn.microsoft.com/windows/win32/api/winhttp/nf-winhttp- winhttpquerydataavailable), ... ... 06e8:trace:winhttp:read_data 8193 bytes read <--- here!!!!!!!!!!!! 06e8:trace:winhttp:send_callback ..., 0x80000, ..., 8193, ... <--- here!!!!!!!!!!!!
I suspect 8192 is the correct value. Could you check if this 1-byte overflow is causing the issue?
I had checked that in a standalone test which showed that Windows behaves the same. Note that this app consistently asks to read the number of bytes available + 1. It gets that as long as there is more data to read. So only the last read call returns 1 byte less than asked for. The patch that caused this regression is a fix for a different regression. There the app checks the Content-Length header and expects to be able to read that many bytes; it divides that number by its buffer size and expects to need that many read calls to read all data. This broke when we only read up to the amount of data that was buffered. The loop I added restores the old behavior and reads as much data as possible in each read call. There's a difference between these apps: this one uses a chunked transfer and the other one (Warframe) uses a regular transfer. My tests also showed that Windows satisfies read calls up to the chunk size (so different from regular transfers) and that's what the patch attached here does. Unfortunately that doesn't fix this app so there must be more to it. -- 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.