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

Closed
basuke opened this Issue Jan 5, 2018 · 1 comment

Comments

Projects
None yet
2 participants
@basuke
Contributor

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:

https://gist.github.com/basuke/59b0b92183846f0424a66f1b3d53cdc6

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

@basuke

This comment has been minimized.

Contributor

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

Fix connection ownership issue curl#2217
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 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.