#769 Make CURLINFO_LASTSOCKET accessible during perform

closed-rejected
libcurl (354)
5
2013-06-21
2008-10-08
vmpdemo
No

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.

Discussion

1 2 > >> (Page 1 of 2)
  • 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.

     
  • vmpdemo
    vmpdemo
    2008-10-09

    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.

     
  • 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?

     
    • status: open --> pending-rejected
     
  • vmpdemo
    vmpdemo
    2008-11-05

    • status: pending-rejected --> open-rejected
     
  • vmpdemo
    vmpdemo
    2008-11-05

    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.

     
  • 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?

     
  • vmpdemo
    vmpdemo
    2008-11-07

    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...

     
  • 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?

     
1 2 > >> (Page 1 of 2)