On Thu, 2016-07-21 at 14:25 +0200, Jacek Caban wrote:
dlls/wininet/http.c | 7 +++++++ 1 file changed, 7 insertions(+)
diff --git a/dlls/wininet/http.c b/dlls/wininet/http.c index 2c62d97..c4cf66b 100644 --- a/dlls/wininet/http.c +++ b/dlls/wininet/http.c @@ -2921,6 +2921,7 @@ static DWORD set_content_length(http_request_t *request) !strcmpiW(encoding, szChunked)) { chunked_stream_t *chunked_stream;
DWORD res; chunked_stream = heap_alloc(sizeof(*chunked_stream)); if(!chunked_stream)@@ -2935,6 +2936,12 @@ static DWORD set_content_length(http_request_t *request) memcpy(chunked_stream->buf, request->read_buf+request->read_pos, request->read_size); chunked_stream->buf_size = request->read_size; request->read_size = request->read_pos = 0;
res = start_next_chunk(chunked_stream, request);if (res != ERROR_SUCCESS) {heap_free(chunked_stream);return res;}It seems to me that you're fixing a problem is a wrong place. start_next_chunk should be called by HTTP_ReceiveRequestData via refill_read_buffer anyway. I'd suggest to investigate why it doesn't work in your case.
This is required to make get_avail_data return the correct number of bytes. Note that the line above sets the read size to 0, so (before my second patch) the next call to get_avail_data would return 0. This may trigger a read beyond available data. It is what happens with Outlook.
Also, see the attached test. We shouldn't need any chunk to complete requests. It's an existing problem in current Wine, which may be unrelated to your problem, but having such blocking calls here is not a step in the right direction.
Your test hangs with and without this patch. Why is having a blocking call here a problem? It would happen right after reading the headers, also blocking calls. Reading the header of the first chunk at this point may actually be the right thing to do. This way we can answer a query for available data without potentially blocking.