-
-
Notifications
You must be signed in to change notification settings - Fork 6.5k
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
prereq: a new callback triggered before a request is made #7477
Conversation
04f6eca
to
e7b26eb
Compare
lib/multi.c
Outdated
data->info.conn_scheme, | ||
data->info.conn_protocol, | ||
data->info.conn_primary_port, | ||
data->info.conn_local_port); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we consider allowing curl_easy_getinfo()
calls from within this callback to retrieve all that information instead of passing these six specific arguments?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interesting. Maybe? That's a departure from all existing callbacks AFAIK and I don't know if accessing curl_easy_getinfo()
is supported during callbacks during a transfer - I thought it was only a post-transfer thing. This is going off vague memories from IRC though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bagder is there anything else in the code that uses curl_easy_getinfo
in flight? I'd have thought there was a danger of some variables having not been populated.
@@ -36,7 +36,7 @@ SUPPORTFILES = first.c test.h | |||
|
|||
# These are all libcurl test programs | |||
noinst_PROGRAMS = chkhostname libauthretry libntlmconnect \ | |||
chkdecimalpoint \ | |||
chkdecimalpoint libprereq \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why doesn't this follow the pattern of being named lib[num]
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because it's generic over a number of different tests. AFAICT this is the pattern for that (see libntlmconnect).
Hitting a weird problem in some tests where CR/LFs are being introduced. The protocol especially doesn't make sense because it's just a number...
The function is literally only doing
and the test file isn't in Windows mode. @bagder have you ever seen this before? |
Looks like the
and because the scheme lines and protocol lines aren't being modified by later functions, they're the only two to look weird. |
4100f7c
to
411b7e3
Compare
AFAICT the remaining build failures are not my fault. |
Yes, but as long as you can just make other output to not look like HTTP headers it is very easily avoided. The "hyper mode" thing is a bit annoying but I haven't been able to come up with a better take on it. |
411b7e3
to
045959c
Compare
Rebasing as recommended on IRC 😄 |
@bagder looks like all but one test succeeds now (yay) but I don't understand the AppVeyor error (1502 failing), given that it succeeds on all the other AppVeyor builds. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks fine, I'm mostly having some final thoughts the specific arguments passed to the callback...
6686acb
to
569f1d0
Compare
lib/multi.c
Outdated
if(prereq_rc != CURL_PREREQFUNC_OK) { | ||
failf(data, "operation aborted by pre-request callback"); | ||
callback_failure = TRUE; | ||
} | ||
} | ||
|
||
if(callback_failure) { | ||
/* failure in pre-request callback - don't do any other processing */ | ||
result = CURLE_ABORTED_BY_CALLBACK; | ||
Curl_posttransfer(data); | ||
multi_done(data, result, FALSE); | ||
stream_error = TRUE; | ||
} | ||
else if(data->set.connect_only) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As you want to stop the execution if the pre-request callback fails we could break early and avoid modifying the control flow? (maybe a bit nitpicking :))
case MSTATE_DO:
if(data->set.fprereq) {
...
if (failure){
break;
}
}
if(data->set.connect_only) {
...
}
else {
...
}
if(prereq_rc != CURL_PREREQFUNC_OK) { | |
failf(data, "operation aborted by pre-request callback"); | |
callback_failure = TRUE; | |
} | |
} | |
if(callback_failure) { | |
/* failure in pre-request callback - don't do any other processing */ | |
result = CURLE_ABORTED_BY_CALLBACK; | |
Curl_posttransfer(data); | |
multi_done(data, result, FALSE); | |
stream_error = TRUE; | |
} | |
else if(data->set.connect_only) { | |
if(prereq_rc != CURL_PREREQFUNC_OK) { | |
failf(data, "operation aborted by pre-request callback"); | |
/* failure in pre-request callback - don't do any other processing */ | |
result = CURLE_ABORTED_BY_CALLBACK; | |
Curl_posttransfer(data); | |
multi_done(data, result, FALSE); | |
stream_error = TRUE; | |
break; | |
} | |
} | |
if(data->set.connect_only) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like a reasonable thing to do. I was trying hard not to mess up any of the existing call flow but yeah, an early break makes sense.
@bagder if this isn't getting into the next release due to the feature freeze can you please let me know so I can update the versions in the documentation. |
Sorry about that but yes we (I) didn't manage to clear out everything for merge before the freeze so now we have a few more weeks to iron out any remaining wrinkles... |
Ugh, frustrating. Is it even worth me rebasing now, or should I wait until the next release is cut and rebase onto there? |
Having done some more testing on this in my end product, it looks like
Will try and get to the bottom of this. (EDIT: This was a bug in curl! Has been fixed) |
e7ebf95
to
c20d7aa
Compare
Now rebased onto 7.79.0. |
c20d7aa
to
29d5c91
Compare
It seems this now conflicts with other merged new options, can you please fix that and force-push and I think we'll be ready to land this baby! |
…after a connection is set up Commits: - callback: Update docs and callback for pre-request callback - Add some documentation for CURLOPT_PREREQDATA and CURLOPT_PREREQFUNCTION, as well as adding the option to stop a transfer from happening by returning a specific callback code. - Add redirect test and callback failure test - Note that the function may be called multiple times on a redirection - Disable new 2086 test due to Windows weirdness
29d5c91
to
6b95987
Compare
@bagder should be sorted now 🤞 |
Thanks! |
…after a connection is set up
This is an implementation of the code and tests described in #7471 to add a new callback at the start of MSTATE_DO.