Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Continuing from paused state for multiplex stream, HTTP/2 connection will deliver body data to wrong connection handle. #2217

basuke opened this issue Jan 5, 2018 · 1 comment


Copy link

basuke commented Jan 5, 2018

I did this

Here we have four connections to the same HTTP/2 server with multiplex enabled. We need to pause them before handling its body, so I paused the connection. After a while

Here is the extracted issue:

File 1-ng-unpause-from-main.cpp

  1. open four connections to same HTTP/2 server.
  2. for each connection, we pause the connection just after the first write function call by returning CURL_WRITEFUNC_PAUSE.
  3. wait for a while.
  4. unpause the connections from main function (outside curl_multi_perform())
  5. all body data is delivered to the last unpaued connection as a one big chunk.

I expected the following

File 2-good-unpause-from-main.cpp is basically same except it unpause from progress function. It works as expected. Also if the server is HTTP/1.1, then both file works fine.

curl/libcurl version

curl 7.57.0 (x86_64-apple-darwin16.7.0) libcurl/7.57.0 OpenSSL/1.0.2n zlib/1.2.8 nghttp2/1.29.0
Release-Date: 2017-11-29
Protocols: dict file ftp ftps gopher http https imap imaps pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: AsynchDNS Debug TrackMemory IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP HTTP2 UnixSockets HTTPS-proxy

operating system

Mac OS X Sierra 10.12.6
Windows 10 Fall Creators Update

Copy link
Contributor Author

basuke commented Jan 5, 2018

It seems it fails to check the paused status because the owner of connection is wrong.

basuke added a commit to basuke/curl that referenced this issue Jan 5, 2018
Before calling Curl_client_chop_write(), change the owner of connection
to the current Curl_easy handle. This will fix the issue curl#2217.
@bagder bagder added the HTTP/2 label Jan 7, 2018
@jay jay closed this as completed in 2a6dbb8 Jan 9, 2018
@lock lock bot locked as resolved and limited conversation to collaborators May 6, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

No branches or pull requests

2 participants