prereq: a new callback triggered before a request is made#7477
prereq: a new callback triggered before a request is made#7477maxdymond wants to merge 1 commit into
Conversation
04f6eca to
e7b26eb
Compare
There was a problem hiding this comment.
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.
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.
@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.
There was a problem hiding this comment.
Why doesn't this follow the pattern of being named lib[num] ?
There was a problem hiding this comment.
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. |
bagder
left a comment
There was a problem hiding this comment.
It looks fine, I'm mostly having some final thoughts the specific arguments passed to the callback...
6686acb to
569f1d0
Compare
There was a problem hiding this comment.
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.
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.