Bugs item #2153446, was opened at 2008-10-08 18:14
Message generated for change (Comment added) made by bagder
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=2153446&group_id=976

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: libcurl
Group: new feature request
Status: Open
Resolution: Rejected
Priority: 5
Private: No
Submitted By: vmpdemo (vmpdemo)
Assigned to: Daniel Stenberg (bagder)
Summary: Make CURLINFO_LASTSOCKET accessible during perform

Initial Comment:
Make CURLINFO_LASTSOCKET accessible during curl_easy_perform.

The difference is that without this change, CURLINFO_LASTSOCKET is confusingly not set from the perspective of any CURLOPT_PROGRESSFUNCTION callback.

Note I'm not certain what the implication might be of removing the data->state.lastconnect setting line from the Curl_done function. Seemingly that choice was arbitrary, but I've left out changing that from my patch.

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2008-11-09 13:18

Message:
when the apps decides "to abort" won't that ask libcurl to cancel its
operation? And when done, can't you then extract the socket afterwards?

----------------------------------------------------------------------

Comment By: vmpdemo (vmpdemo)
Date: 2008-11-07 19:40

Message:
No, by client, I mean the http client code that uses the library libcurl
and connects to the server. The client decides it's done waiting and wants
to cancel its request...

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2008-11-06 09:01

Message:
You say "the client may decide to abort" - are you then referring to
libcurl itself? Why would it abort unless you told it to or there was a
true problem?

And if it is a problem, how can you then properly use the socket
afterwards?

----------------------------------------------------------------------

Comment By: vmpdemo (vmpdemo)
Date: 2008-11-05 22:52

Message:
Well in my particular use case, the normal transfer is conducted over HTTP
as normal. The HTTP response frequently takes several minutes.
Occasionally, while it's taking several minutes, the client may decide to
abort, and rather than just disconnecting, I want to send an additional
request message over that socket.

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2008-10-30 00:07

Message:
I'd rather not do this change as it would then have us document this and
then it would put us in a position where we need to make it work - and this
suggested fix only solves it for 98% something of the time and cases.

Why would you need to "see" the socket really? For the easy interface you
can use the progress callback to get progress info and for the multi
interface you get to know about the socket(s) in use already?

----------------------------------------------------------------------

Comment By: vmpdemo (vmpdemo)
Date: 2008-10-09 20:14

Message:
This is mainly useful if you're NOT using CURLOPT_CONNECT_ONLY. With
CURLOPT_CONNECT_ONLY this is fairly irrelevant.

But without CURLOPT_CONNECT_ONLY, this change allows you to see the socket
in progress. In particular a HTTP request may be slow in getting a
response back, and you can now see the socket in use during that time.

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2008-10-08 23:00

Message:
It wasn't exactly arbitrary but the whole point of CURLINFO_LASTSOCKET has
been to extract the socket _after_ a compelted request, not getting it
during operations. In fact, libcurl may use more than one socket while in
progress an in this case you may also get a period in the beginning of the
request where there is no lastsocket assigned.

What's your use-case for wanting this info this early in the process? I'm
not shooting down the suggestion, just trying to get a better picture.

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=2153446&group_id=976
Received on 2008-11-09