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

CURLINFO_STARTTRANSFERTIME(_T) returns 0 for POST requests on libcurl versions newer than 7.64.0 #4136

Closed
JCMais opened this issue Jul 21, 2019 · 2 comments

Comments

@JCMais
Copy link
Contributor

JCMais commented Jul 21, 2019

I did this

Made a POST request and tried to retrieve the value of CURLINFO_STARTTRANSFERTIME(_T).

I expected the following

The value returned should be greater than 0, CURLINFO_PRETRANSFER_TIME itself is greater than 0, so CURLINFO_STARTTRANSFERTIME must be too.

It is reproducible with the curl binary:

libcurl 7.65.3

curl -d "data data data" -w "lookup: %{time_namelookup}\nconnect: %{time_connect}\nappconnect: %{time_appconnect}\npretransfer: %{time_pretransfer}\nredirect: %{time_redirect}\nstarttransfer: %{time_starttransfer}\ntotal: %{time_total}\n" "http://requestbin.fullcontact.com/16dxjre1"

ok
lookup:        0,009254
connect:       0,035072
appconnect:    0,000000
pretransfer:   0,035231
redirect:      0,000000
starttransfer: 0,000000
total:         0,582735

It seems to work with a GET:

curl -w "lookup: %{time_namelookup}\nconnect: %{time_connect}\nappconnect: %{time_appconnect}\npretransfer: %{time_pretransfer}\nredirect: %{time_redirect}\nstarttransfer: %{time_starttransfer}\ntotal: %{time_total}\n" "http://requestbin.fullcontact.com/16dxjre1"

ok
lookup:        0,009284
connect:       0,032880
appconnect:    0,000000
pretransfer:   0,033062
redirect:      0,000000
starttransfer: 0,582286
total:         0,582642

The first version that this problem starts happening is 7.64.1, old libcurl version seems to work:

libcurl 7.64.1

ok
lookup:        0,034794
connect:       0,056868
appconnect:    0,000000
pretransfer:   0,057023
redirect:      0,000000
starttransfer: 0,000000
total:         0,874881

libcurl 7.64.0

ok
lookup:        0,008550
connect:       0,037006
appconnect:    0,000000
pretransfer:   0,037191
redirect:      0,000000
starttransfer: 0,574312
total:         0,574859

curl/libcurl version

curl 7.65.3 (x86_64-pc-win32) libcurl/7.65.3 OpenSSL/1.1.1c (Schannel) zlib/1.2.11 brotli/1.0.7 WinIDN libssh2/1.9.0 nghttp2/1.39.1
Release-Date: 2019-07-19
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: AsynchDNS HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile MultiSSL NTLM SPNEGO SSL SSPI TLS-SRP brotli libz

operating system

Windows 10 x64

This was initially reported here JCMais/node-libcurl#183, so I suspect it's not platform-specific.

@JCMais JCMais changed the title CURLINFO_STARTTRANSFERTIME(_T) returns 0 on newer versions for POST request CURLINFO_STARTTRANSFERTIME(_T) returns 0 for POST requests on libcurl versions newer than 7.64.0 Jul 21, 2019
@jay
Copy link
Member

jay commented Jul 22, 2019

bisected to 65eb65f urldata: simplify bytecounters @bagder

curl/lib/transfer.c

Lines 638 to 643 in 521bbbe

if((k->bytecount == 0) && (k->writebytecount == 0)) {
Curl_pgrsTime(data, TIMER_STARTTRANSFER);
if(k->exp100 > EXP100_SEND_DATA)
/* set time stamp to compare with when waiting for the 100 */
k->start100 = Curl_now();
}

now that writebytecount is part of the request it's no longer 0 here so progress.t_starttransfer is never set

bagder added a commit that referenced this issue Jul 29, 2019
Regression, broken in commit 65eb65f (curl 7.64.1)

Reported-by: Jonathan Cardoso Machado
Assisted-by: Jay Satiro

Fixes #4136
bagder added a commit that referenced this issue Jul 30, 2019
Regression, broken in commit 65eb65f (curl 7.64.1)

Reported-by: Jonathan Cardoso Machado
Assisted-by: Jay Satiro

Fixes #4136
Closes #4162
@bagder bagder closed this as completed in cb542ac Jul 30, 2019
@JCMais
Copy link
Contributor Author

JCMais commented Jul 30, 2019

Thanks @jay and @bagder!

@lock lock bot locked as resolved and limited conversation to collaborators Oct 28, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Development

Successfully merging a pull request may close this issue.

3 participants