Download a big enough data using the http protocol.
curl_multi_add_handle() -> curl_multi_perform() in a loop -> write_callback() is being raised as expected.
curl_easy is not yet done (no CURLMSG_DONE message), curl_multi_remove_handle() is called. According to the manual:
You can remove handles at any point in time during transfers.
a) curl_multi_add_handle() -> curl_multi_perform() in a loop -> got CURLMSG_DONE message with the error CURLE_UNSUPPORTED_PROTOCOL.
b) Or curl_easy_perform() returns the error CURLE_UNSUPPORTED_PROTOCOL.
I expected the following
Once removed from the multi handle, you can again use other easy interface functions like curl_easy_perform on the handle or whatever you think is necessary.
Curl_dyn_reset(&data->state.headerb); is not called after curl_multi_add_handle() and data->state.headerb points to the end header mark "\r\n" left after the first request. Thus, curl tries to parse "\r\nHTTP/1.1 200 OK\r\n" when the response on the second request is being processed.
The text was updated successfully, but these errors were encountered:
Yes, that pull request fixes the issue.
I am not sure if this is a complete fix. I am afraid the issue can persist in case of using a proxy. It seems garbage "\r\nHTTP/1.1 200 Connection Established\r\n" is still possible. I can not test the fix with using a proxy right now.
I am afraid the issue can persist in case of using a proxy
Why do you think that? A proxy won't change how the code gets headers and this patch resets the header buffer before the first one can arrive so no, I can't see how this won't fix the proxy case as well!
I looked at multi.c and supposed the issue might be in a proxy stuff also: protocol_connect() -> conn->handler->connect_it() -> Curl_proxy_connect() is called before multi_do() -> conn->handler->do_it() -> Curl_http() -> Curl_dyn_reset(&data->state.headerb);.
You are right, Curl_proxy_connect() does not use data->state.headerb, it uses s->rcvbuf with proxy headers.